Re: [Roll] [roll] #5: DODAG
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Roll] [roll] #5: DODAG



Hi Julien:

In classical terms, an instance really defines a DAG. So if you have
multiple roots then RPL partitions that DAG into a set of
Destination-Oriented DAGs, also called DAG Rooted at a Destination in
the art. All those terms exist with a specific load and the wisdom we
hear from Phil and Dave is not to overload / redefine / restrict those
terms. 

The most useful object is the DODAG iteration. A node moves within one
and jump between 2. This is the object for which we should find cool
name. DODAGI is certainly pronounceable by many of us, but it looks a
lot like a WG name in mobility. Any idea?

Cheers,

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Julien Abeille (jabeille)
>Sent: lundi 9 novembre 2009 11:12
>To: Tim Winter; ROLL WG
>Subject: Re: [Roll] [roll] #5: DODAG
>
>Hi Tim,
>
>My question is: are there DAGs that are not DODAGs in RPL? My feeling
is
>no. Hence I would suppress the DODAG instead of turning all "DAG" into
>"DODAG".
>Best,
>Julien
>
>> -----Original Message-----
>> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On
>> Behalf Of Tim Winter
>> Sent: samedi 7 novembre 2009 19:55
>> To: ROLL WG
>> Subject: [Roll] [roll] #5: DODAG
>>
>> Hi Julien, WG,
>>
>>
>> roll issue tracker wrote:
>> > #5: DODAG
>> >
>>
--------------------------------+-------------------------------------
>> > --------------------------------+------
>> >  Reporter:  jpv at ...               |       Owner:  wintert at ...
>> >      Type:  defect              |      Status:  new
>> >  Priority:  major               |   Milestone:
>> > Component:  rpl                 |     Version:
>> >  Severity:  Active WG Document  |    Keywords:
>> >
>>
--------------------------------+-------------------------------------
>> > --------------------------------+------
>> >  * This is currently being discussed by the RPL Author team *
>> >
>> >  Email from Julien
>> >
>> >  Is there a distinction between DAG and destination
>> oriented DAG. From
>> > what  I read I feel all DAGs are destination oriented. If this is
>> > correct I  propose to remove the destination oriented DAG concept.
>> >
>>
>>
>> The intent for -05 will be to make the unqualifed use of
>> `DAG' in the text consistent with `DODAG Iteration', as
>> outlined below.  So in this use, a `DAG' is a `DODAG'
>> snapshotted by a single sequence number -- a `DODAG
>> Iteration'.  There may be cases in -04 where the text reads
>> `DAG' and is in fact referring to `DODAG'- we will be sure to
>> clean these up.  Here below is some additional explanation
>> prepared by the author team-
>>
>> Does this help to clarify?
>>
>> Regards,
>>
>> -Tim
>>
>>
>>
>> Instance
>>
>>
>>
>> +----------------------------------------------------------------+
>>      |
>>         |
>>      |      (R1)                   (R2)
>> (Rn)        |
>>      |      /  \                   /| \                  / |
>> \       |
>>      |     /    \                 / |  \                /  |
>>  \      |
>>      |   (A)    (B)             (M) |  (N)     ...    (X) (Y)
>>  (Z)    |
>>      |   /|\     |\             /   |   |\             |   |
>>   |     |
>>      |  : : :    : :            :  (O)  : :            :   :
>>   :     |
>>      |                             / \
>>         |
>>      |                            :   :
>>         |
>>      |
>>         |
>>      |                          Instance ID
>>         |
>>      |
>>         |
>>
>> +----------------------------------------------------------------+
>>
>>                                  Instance
>>
>>
>>    An Instance is a routing topology over an LLN, optimized for a
>>    particular objective/application.  Discrete Instances may
>> also be set
>>    up to offer optimized connectivity to different destinations when
>>    appropriate, for example to differentiate a Home Network LLN from
a
>>    Utility Network LLN in a smart metering application where
>> a meter may
>>    be configured to join both Instances.
>>
>>    It consists of one or more Destination Oriented DAGs (DODAGs).
>>
>>    It is uniquely identified by an InstanceID.
>>
>>    Each instance is operated independently of other instances, and
RPL
>>    defines operation over only one instance.  Operation among
multiple
>>    instances is to be expanded upon in a future revision or companion
>>    specification.
>>
>>
>>
>> Destination Oriented DAG (DODAG)
>>
>>
>>      +----------------+
>>      |                |
>>      |      (R1)      |            (R2)                   (Rn)
>>      |      /  \      |            /| \                  / |  \
>>      |     /    \     |           / |  \                /  |   \
>>      |   (A)    (B)   |         (M) |  (N)     ...    (X) (Y)  (Z)
>>      |   /|\     |\   |         /   |   |\             |   |    |
>>      |  : : :    : :  |         :  (O)  : :            :   :    :
>>      |                |            / \
>>      |     DAGID      |           :   :
>>      |                |
>>      +----------------+
>>
>>                                    DODAG
>>
>>
>>    A Destination Oriented DAG is a DAG rooted at a single root node,
>>    which is a node with no outgoing edges.
>>
>>    In the case where multiple nodes in the LLN coordinate over a
>>    backbone and expose the same DAGID (to support the same
>> DODAG), it is
>>    conceptually as if there is a single virtual root over the
backbone
>>    (not illustrated).  In some applications/implementations
>> this may be
>>    a desired architecture; in other applications each DODAG
>> may operate
>>    with indpendent uncoordinated roots exposing different DAGIDs.
>>
>>    A DODAG is uniquely identified over the LLN by the tuple
>> (InstanceID,
>>    DAGID).
>>
>>    In RPL a node may belong to only one DODAG per Instance at a time.
>>
>>
>>
>> DODAG Iteration
>>
>>
>>            +----------------+                +-----------------+
>>            |                |                |                 |
>>            |      (R1)      |                |      (R1)       |
>>            |      /  \      |         \      |     / |  \      |
>>            |     /    \     |    ------\     |    /  |   \     |
>>            |   (A)    (B)   |           \    |  (A)  (C)  (B)  |
>>            |   /|\     |\   |           /    |  /|\        |\  |
>>            |  : : :    : :  |    ------/     | : : :       : : |
>>            |                |         /      |                 |
>>            |   Sequence N   |                |  Sequence N+1   |
>>            |                |                |                 |
>>            +----------------+                +-----------------+
>>
>>                               DODAG Iteration
>>
>>
>>    A DODAG Iteration is the DODAG that results from the iterative
>>    process that reshapes the DODAG as stimulated by the root.  It is
a
>>    DAG as constrained by operation of RPL over a fixed
>> Sequence Number.
>>
>>    As the root node increments the Sequence Number, different types
of
>>    node movement are allowed (e.g. moving `down') and a new DODAG
>>    Iteration is formed.
>>
>>    A DODAG Iteration is uniquely identified over the LLN by the tuple
>>    (InstanceID, DAGID, SequenceNumber).
>>
>>
>>
>> Scope
>>
>>    o  The scope of an InstanceID is the whole network and it
>> defines an
>>       instance
>>
>>    o  The scope of a DAGID is an instance and it defines a
>> DODAG within
>>       that instance
>>
>>    o  The scope of a Sequence Number is a DODAG and it defines an
>>       iteration of that DODAG (DODAG Iteration)
>>
>>    o  The scope of a rank is a DODAG Iteration and it defines
>> a position
>>       of a node within that iteration.
>> _______________________________________________
>> Roll mailing list
>> Roll at ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.