Subject: [Roll] DODAGID

From: Philip Levis <[email-masked]>
Date: Thu, 1 Apr 2010 18:39:50 -0700

Can someone remind me why DODAGID is in the DIO? IIRC, someone told me that DODAGID is necessary due to application requirements that a node can avoid choosing a new preferred parent that goes to a different DODAG root. Can someone point me at this requirement? DODAGIDs add a lot of complexity and greatly increase message sizes.

If they're needed, all's good, but I can't seem to find the application requirement (in a requirements doc) that calls for this. I figure anything we can do to simplify things is desirable. In the case of DODAGIDs, the presence of RPL instances and the destination prefix suggests to me connectivity is already handled.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 2 Apr 2010 10:06:38 -0700

The DODAGID scopes the DODAG sequence.  Without the DODAGID, you'd  
have to coordinate sequence numbers between all roots within the same  
instance.

--
Jonathan Hui

On Apr 1, 2010, at 6:39 PM, Philip Levis wrote:

> Can someone remind me why DODAGID is in the DIO? IIRC, someone told  
> me that DODAGID is necessary due to application requirements that a  
> node can avoid choosing a new preferred parent that goes to a  
> different DODAG root. Can someone point me at this requirement?  
> DODAGIDs add a lot of complexity and greatly increase message sizes.
>
> If they're needed, all's good, but I can't seem to find the  
> application requirement (in a requirements doc) that calls for this.  
> I figure anything we can do to simplify things is desirable. In the  
> case of DODAGIDs, the presence of RPL instances and the destination  
> prefix suggests to me connectivity is already handled.
>
> Phil
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 2 Apr 2010 10:08:14 -0700

Correct me if I am wrong but I read that the prefix container was for 'additional' prefixes and therefore, I assumed that the default prefix that the DODAG root was supporting was in the DODOAGID. The specs said that the DODAGID was derived from the IP address of the DODAG root so I was assuming this would be okay. One less message container to carry by default.

- John

> If they're needed, all's good, but I can't seem to find the application requirement (in a requirements doc) that calls for this. I figure anything we can do to simplify things is desirable. In the…

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Philip Levis <[email-masked]>
Date: Fri, 2 Apr 2010 17:31:24 -0700

On Apr 2, 2010, at 10:06 AM, Jonathan Hui wrote:

> 
> The DODAGID scopes the DODAG sequence.  Without the DODAGID, you'd have to coordinate sequence numbers between all roots within the same instance.

Makes sense, but 16 bytes seems like a lot of state for such as simple problem...

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 4 Apr 2010 21:02:44 +0200

Hi John:

The DODAGID is expected to be an IPv6 address of the root. The prefix
option normally indicates a prefix that can be reached via the DODAGID.

Interestingly, there is a strong need to also indicateand maintain
availability of a prefix that would be deployed over the DODAG, when the
subnet spans the DAG (6LoWPAN & Autoconf).
A simple bit in the option could indicate that. In either case, the
prefix ends up in the RAs, either for not-onlink SLAAC, or for the
purpose of RFC 4191. 

Advice?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> JeongGil Ko (John)
> Sent: Friday, April 02, 2010 7:08 PM
> To: Philip Levis
> Cc: ROLL WG
> Subject: Re: [Roll] DODAGID
> 
> Correct me if I am wrong but I read that the prefix container was for
> 'additional' prefixes and therefore, I assumed that the default prefix
that the
> DODAG root was supporting was in the DODOAGID. The specs said that the
> DODAGID was derived from the IP address of the DODAG root so I was
> assuming this would be okay. One less message container to carry by
default.
> me that DODAGID is necessary due to application requirements that a
node
> can avoid choosing a new preferred parent that goes to a different
DODAG
> root. Can someone point me at this requirement? DODAGIDs add a lot of
> complexity and greatly increase message sizes.
> >
application
> requirement (in a requirements doc) that calls for this. I figure
anything we
> can do to simplify things is desirable. In the case of DODAGIDs, the
presence
> of RPL instances and the destination prefix suggests to me
connectivity is
> already handled.

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 05 Apr 2010 08:13:53 -0400

> From: Philip Levis <[email-masked]>
> Date: Fri, 2 Apr 2010 17:31:24 -0700
> 
> > have to coordinate sequence numbers between all roots within the
> > same instance.
> 

On the other hand, the one-byte RPLInstanceID seems like
very little state for a harder problem.

It is likely that the current P2P effort is going to force
us to revisit how RPLInstanceID and DODAGID are used.  If a
switch needs to create a new DODAG in order to find a route
to a lamp, where does it get an unused RPLInstanceID from?
If P2P does turn out to need RPLInstanceIDs on the fly, we
will need to figure out how they are obtained.  I have some
ideas about this, and I know that Pascal has thought about
it as well.

                               -Richard Kelsey

---

From: [email-masked]
Date: Mon, 5 Apr 2010 07:36:19 -0500

With all of the discussions for P2P,
and the need for the creation of new DODAG IDs to support this - are we
considering

adding additional management roles to
the  DHCP like server or designating a new device type? This new role
will manage the DODAG IDs - such

as assignments - duplicate ID detection
and deletion or renewal?

Ted

From:

Richard Kelsey <[email-masked]>

To:

Philip Levis <[email-masked]>

Cc:

[email-masked]

Date:

04/05/2010 07:18 AM

Subject:

Re: [Roll] DODAGID

> Makes sense, but 16 bytes seems like a lot of state for such as simple

> problem...

it as well.

-Richard Kelsey

Roll mailing list

[email-masked]

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 5 Apr 2010 07:43:18 -0700

Hi Pascal,

> prefix ends up in the RAs, either for not-onlink SLAAC, or for the

I agree it would be nice to re-use bits wherever possible.  Adding a  
single bit would work fine for SLAAC as long as we don't need to worry  
about graceful renumbering.  If we do, then we need to start worrying  
about valid and preferred lifetimes, multiple prefixes, etc.  In many  
applications, I think having a single prefix is enough and graceful  
renumbering is not an issue.  But I can see other cases where this may  
be an issue.  The usual tradeoffs apply :)

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 5 Apr 2010 07:50:29 -0700

Hi Richard,

> ideas about this, and I know that Pascal has thought about

Yes, this was going to be my reply to Phil as well.  Every new  
namespace is something that needs to have some additional mechanisms  
to handle.  The original intention with the DODAG ID being the IP  
address of the root is that it avoids creating a new namespace.   
Though in some cases, there are ways to automatically manage the  
namespace without explicit user management or a stateful central  
server, but requires ways to avoid selecting duplicates when possible,  
detect duplicates when they occur, and recover when duplicates are  
detected.

In the case of DODAGID/InstanceID, one way for the root to detect  
duplicates is by processing received DIO messages and seeing if the  
Sequence values makes sense.  As you suggest, I'm sure there are other  
things you could do.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Apr 2010 20:21:57 +0200

Hi Richard and all:

One thing that was discussed in the corridor was the need to be able to
autoconf an instance ID for P2P.

The way to do that would be that the namespace would be local to the
node that autoconfigures the instanceID.

For those local instanceID, what would then uniquely identify the
instance would be the tuple (DODAGID, instanceID). A diect consequence
is that there can be only one root to the DAG, but that's OK for P2P.

One will note that the instance ID must also be present in the packets
for loop detection. This is not really a problem for P2P if the DODAGID
is the address of one of the endpoints anyway.

Please find some proposed text:

"

3.1.1.  Topology Identifiers
 
   RPL uses four identifiers to track and control the topology:
 
   o  The first is a RPLInstanceID that is used to identify instances.
      A RPLInstanceID can be either local or global.
 
      *  A global RPLInstanceID is a network wide unique identifier that
         enables to group a number of DODAGs with a common Goal and
         Objective Function into a same instance.
 
      *  A local RPLInstanceID is associated to a DODAGID to identify a
         DODAG for use in P2P communication where the DODAGID is one of
         the endpoints of the communication.
 
      A network may have multiple RPLInstanceIDs, each of which defines
      an independent set of DODAGs, which may be optimized for different
      OFs and/or applications.  The set of DODAGs identified by a
      RPLInstanceID is called a RPL Instance
 
...

"

Then a section on the instance ID

"

RPL Instance ID

   A global RPLInstanceID MUST be unique to the whole LLN.  Mechanisms

   for allocating and provisioning global RPLInstanceID are out of

   scope for this document.  There can be up to 128 global instance in

  the whole network, and up 64 local instances per DODAGID.

   A global RPLinstanceID is encoded in a RPLinstanceID field as

   follows:

        0 1 2 3 4 5 6 7

       +-+-+-+-+-+-+-+-+

       |0|     ID      |  Global RPLinstanceID in 0..127

       +-+-+-+-+-+-+-+-+

                                     |

        Figure 3: RPL Instance ID field format for global instances

   A local RPLInstanceID is autoconfigured by the node that owns the

   DODAGID and it must be unique for that DODAGID.  In that case, the

   DODAGID MUST be a valid address of the root that is used as an

   endpoint of all communications within that instance.

   A local RPLinstanceID is encoded in a RPLinstanceID field as follows:

        0 1 2 3 4 5 6 7

       +-+-+-+-+-+-+-+-+

       |1|D|   ID      |  Local RPLInstanceID in 0..63

       +-+-+-+-+-+-+-+-+                                            |

        Figure 4: RPL Instance ID field format for local instances

   The D flag in a Local RPLInstanceID is always set to 0 in RPL control

   messages.  It is used in data packets to indicate whether the DODAGID

   is the source or the destination of the packet.  If the D flag is set

   to 1 then the DODAGID MUST be the destination of the IPv6 packet.If

   the D flag is reset then the DODAGID MUST be the source of the IPv6

   packet.

"

Advice?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 05, 2010 2:36 PM
To: Richard Kelsey
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] DODAGID

With all of the discussions for P2P, and the need for the creation of
new DODAG IDs to support this - are we considering 
adding additional management roles to the  DHCP like server or
designating a new device type? This new role will manage the DODAG IDs -
such 
as assignments - duplicate ID detection and deletion or renewal? 

Ted 

From: 

To: 

Cc: 

[email-masked] 

Date: 

04/05/2010 07:18 AM 

Subject: 

Re: [Roll] DODAGID

________________________________

                              -Richard Kelsey
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Apr 2010 20:30:16 +0200

Hi Jonathan:

Good point. Please note that the DAG Destination Prefix option is
inspired from ND, and in particular it has a lifetime. 

Also that there can be multiple such options in a DIO. So I think that
it is possible to make a renumbering though the whole process is largely
out of scope for RPL.

Do I understand that you support the idea? Please find some proposed
text that goes with it:

" xxx Destination Prefix

   The Destination Prefix option format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 3    |      option Length            |R|rsv|Prf| rsv |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Sequence    | Prefix Length |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 13: DAG Destination Prefix

   The Destination Prefix option is used in DIO to indicate that
   connectivity to the specified destination prefix is available from
   the DODAG root.  A RA (R) flag indicates whether the DODAG is part of
   the subnet where the prefix is deployed and influences the way the
   prefix may be presented to the hosts by RPL routers in RA messages.
   This may be useful in cases where more than one LBR is operating
   within the LLN and offering connectivity to different administrative
   domains, e.g. a home network and a utility network.  In such cases,
   upon observing the Destination Prefixes offered by a particular
   DODAG, a node MAY decide to join multiple DODAGs in support of a
   particular application.

   The option Length is coded as the length of the option in octets,
   excluding the Type and Length fields.

   Prf is the Route Preference as in [RFC4191].  The reserved fields
   MUST be set to zero on transmission and MUST be ignored on receipt.

   If the R flag is set, then the DODAG is part of the subnet where the
   prefix is deployed.  The prefix may be advertised as not onlink in RA
   messages for the purpose address autoconfiguration.  If the R flag is
   reset, then the prefix is exterior to the DODAG yet may be reached
   via the root.  The prefix may be advertised in RA messages for
   communicating default router preferences and more-specific routes
   from routers to hosts as prescribed in [RFC4191] with the preference
   in the Prf field.

   The Prefix Lifetime is a 32-bit unsigned integer representing the
   length of time in seconds (relative to the time the packet is sent)
   that the Destination Prefix is valid for route determination.  The
   lifetime is initially set by the node that owns the prefix and
   denotes the valid lifetime for that prefix (similar to
   AdvValidLifetime [RFC4861]).  The value might be reduced by the
   originator and/or en-route nodes that will not provide connectivity
   for the whole valid lifetime.  A value of all one bits (0xFFFFFFFF)
   represents infinity.  A value of all zero bits (0x00000000) indicates
   a loss of reachability.

   The Prefix Length is an 8-bit unsigned integer that indicates the
   number of leading bits in the destination prefix.

   The Destination Prefix contains Prefix Length significant bits of the
   destination prefix.  The remaining bits of the Destination Prefix, as
   required to complete the trailing octet, are set to 0.

   In the event that a DIO message may need to specify connectivity to
   more than one destination, the Destination Prefix option may be
   repeated.

"

What do you think?

Pascal

> From: Jonathan Hui [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 4:43 PM
> To: Pascal Thubert (pthubert)
> Cc: JeongGil Ko (John); Philip Levis; ROLL WG
> > availability of a prefix that would be deployed over the DODAG, when
> > the subnet spans the DAG (6LoWPAN & Autoconf).
single bit
> would work fine for SLAAC as long as we don't need to worry about
graceful
> renumbering.  If we do, then we need to start worrying about valid and
> preferred lifetimes, multiple prefixes, etc.  In many applications, I
think
> having a single prefix is enough and graceful renumbering is not an
issue.  But
> I can see other cases where this may be an issue.  The usual tradeoffs
apply :)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Apr 2010 14:37:17 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    >> The DODAGID scopes the DODAG sequence.  Without the DODAGID,
    >> you'd have to coordinate sequence numbers between all roots
    >> within the same instance.

    Philip> Makes sense, but 16 bytes seems like a lot of state for such
    Philip> as simple problem...

In my implementation, it's treated as a null-padded string. It may be
descriptive.  (Obviously, my implementation is happy to just see random
unprintable characters).

The DODAGID is the major thing I see one would provision into
nodes/applications.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Apr 2010 14:40:52 -0400

>>>>> "Ted" == Ted Humpal <[email-masked]> writes:
    Ted>    With all of the discussions for P2P, and the need for the
    Ted> creation of new DODAG IDs to support this - are we considering
    Ted> adding additional management roles to the DHCP like server or
    Ted> designating a new device type? This new role will manage the
    Ted> DODAG IDs - such as assignments - duplicate ID detection and
    Ted> deletion or renewal?  

Uhm... does (stateless, IPv6) DHCP happen first, or does RPL?

I'd have thought that the bootstrap order was:
    0) do layer-2 stuff, if any.
    1) hear RA from nearby nodes, configure address, send ND.  (*)
    2) listen for DIO.
    3) pick parent, send DAG
    4) do DHCP to get additional information

(*) maybe I'm wrong about the nodes doing RA.