Subject: Re: [Roll] draft-rpl-08: Target and OCP sub-options share code 5

From: Tim Winter <[email-masked]>
Date: Wed, 02 Jun 2010 07:42:31 -0400

Hi Dario,

On 05/31/2010 07:04 PM, Dario Tedeschi wrote:
>
> Seems that the new "RPL Target" sub-option uses the same type-value (5)
> as the OCP sub-option that is defined in
> "draft-ietf-roll-routing-metrics-06" (section 6).
>
> Dario

This is a mistake.  We can correct the option numbering for -09 by leaving OCP Option 
value 5 to the metrics draft, and incrementing the RPL Target through Prefix 
Information as follows:

      Option   Name                      Draft
      ------   -----------------------   -------------------------------
         0     Pad1                      [I-D.ietf-roll-rpl]
         1     PadN                      [I-D.ietf-roll-rpl]
         2     DAG Metric Container      [I-D.ietf-roll-rpl]
         3     Routing Information       [I-D.ietf-roll-rpl]
         4     DAG Timer Configuration   [I-D.ietf-roll-rpl]
         5     OCP Object                [I-D.ietf-roll-routing-metrics]
         6     RPL Target                [I-D.ietf-roll-rpl]
         7     Transit Information       [I-D.ietf-roll-rpl]
         8     Solicited Information     [I-D.ietf-roll-rpl]
         9     Prefix Information        [I-D.ietf-roll-rpl]

Regards,

-Tim

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 02 Jun 2010 11:39:10 -0700

Thanks Tim

All,
Is there any reason why the OCP can't be placed in the DIO base header, 
since there is now a 16bit reserved word available? Why is the OCP 
currently contained in a sub-option, when a joining node requires it to 
determine what OF to use or to filter on.

Dario

Tim Winter wrote:
> This is a mistake.  We can correct the option numbering for -09 by 
> leaving OCP Option value 5 to the metrics draft, and incrementing the 
> RPL Target through Prefix Information as follows:
>
>
>      Option   Name                      Draft
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 02 Jun 2010 21:02:33 +0200

I think that the OCP is ok as an option since the DIOs are also sent
to keep the nodes already in the DODAG up-to-date on metrics and
ranks that might change over time. The more constant data we
add to the base option the less space we have for dynamic data.
(the OCP will typically be the same as long as the DODAG exist I
assume).

But the description of the option should be in the RPL specification,
then this confusion will not happen again.

Best regards,
-- Joakim Eriksson, SICS

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 02 Jun 2010 12:40:46 -0700

> then this confusion will not happen again.
That would help. Also, I think their should be some text saying that the 
OCP sub-option MUST be included in response to a unicast DIS. Similar to 
how the config sub-option works. Alternatively, just add OCP to the 
config sub-option, which would solve the "[redundant] constant data" 
issue and ensure OCP is always available through unicast DIOs

Dario

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 02 Jun 2010 21:52:27 +0200

> issue and ensure OCP is always available through unicast DIOs
Exactly, MUST on unicast DIS responses and MAY otherwise would
make sense!

Currently I am afraid it is an option that is a MUST in all cases (but
that might change ;-). From the Metrics document:

"There MUST be a single instance of the OCP object within the sub-
option field of the DIO Base option object."

I would make sense that the OCP has the same status as the DODAG
Configuration Option that sets some very important configurations
for the DODAG. This option is a MUST in DIOs that are responses
to unicast DIS.

Best regards,
-- Joakim Eriksson, SICS

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 03 Jun 2010 08:52:30 +0200

Another question related to the OCP is if it really needs
the 16 bits? Are we expecting 255 completely different
graph construction mechanisms? One perspective would be to
say that the ports of TCP/UDP have shown that we really need
lots of alternatives (16-bit) but given that most applications
will use some of the (few?) common objective functions that
we and others design I would say that we would be fine with
255 alternatives (8-bits).

Then it would fit well into the DIO since it would only take
half of the reserved 16-bits (and save 4 bytes from the non-
optional OCP option).

Best regards,
-- Joakim Eriksson, SICS

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 03 Jun 2010 05:28:01 -0400

> Date: Wed, 02 Jun 2010 12:40:46 -0700
> From: Dario Tedeschi <[email-masked]>
> 
> Joakim Eriksson wrote:
>

I strongly favor putting the OCP into the config sub-option.
It's simple and solves the problem.

                                  -Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Thu, 3 Jun 2010 06:26:55 -0700

> It's simple and solves the problem.

I agree. I also favor making it 8 bits.

Phil

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 03 Jun 2010 11:22:17 -0700

255 Objective Functions would probably be enough, but if allowance is to 
be made for proprietary OFs, perhaps we'd need 16bits. Then again, one 
could argue that there should not be any proprietary OFs, since we are 
all trying to be compatible (right?).

If the OCP ends up in the config sub-option, I'd vote to keep it as 
16bits since it would make a nice rectangular box in Figure 16, draft-08 
:-).

Dario

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jun 2010 13:13:32 +0200

Hi Dario and Joakim:

Then again, one could
> argue that there should not be any proprietary OFs, since we are all
trying to
> be compatible (right?).

I've seen arguments in both directions. Some people seem love it, some
seem hate it. If you look at it, UDP port and IP addresses both  have
sandboxes to play with. EUI has OID.

So we could say that the OCP, like an IPv6 address, starts with a number
of bits that indicate its type. And one type would be reserved for
private experimentations.
One type could be followed by an OID that could indicate an supplier or
an SDO. It makes sense to me to enable standard bodies like Zigbee or
ISA to define their own OCPs.

The core spec does not really care how the OCPs get attributed. It cares
for the decision on whether allow a DAG with OCP B to extend a DAG with
OCP A, which we chose to disallow. 
The rest could be done in an OCP architecture document that would
explain which values/subfield would belong to IANA, and what is
delegated to whom.

If you are interested in starting that draft, I, for one, will support
you.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Dario Tedeschi
> Sent: Thursday, June 03, 2010 8:22 PM
> To: Joakim Eriksson
> Cc: [email-masked]
> Subject: Re: [Roll] Target and OCP sub-options share code 5 / 8-bit
OCP in
> DIO?
> 
> 
> 255 Objective Functions would probably be enough, but if allowance is
to be
> made for proprietary OFs, perhaps we'd need 16bits. Then again, one
could
> argue that there should not be any proprietary OFs, since we are all
trying to
> be compatible (right?).
16bits since
> it would make a nice rectangular box in Figure 16, draft-08 :-).
> 
> Dario
> 
> Joakim Eriksson wrote:
> > Another question related to the OCP is if it really needs the 16
bits?
> > Are we expecting 255 completely different graph construction
> > mechanisms? One perspective would be to say that the ports of
TCP/UDP
> > have shown that we really need lots of alternatives (16-bit) but
given
> > that most applications will use some of the (few?) common objective
> > functions that we and others design I would say that we would be
fine
> > with
> > Then it would fit well into the DIO since it would only take half of
> > the reserved 16-bits (and save 4 bytes from the non- optional OCP
> > option).
> >
> >
> > Best regards,
> > -- Joakim Eriksson, SICS
> >
> >
> >>>> I think that the OCP is ok as an option since the DIOs are also
> >>>> sent to keep the nodes already in the DODAG up-to-date on metrics
> >>>> and ranks that might change over time. The more constant data we
> >>>> But the description of the option should be in the RPL
> >>>> specification, then this confusion will not happen again.
> >>> That would help. Also, I think their should be some text saying
that
> >>> the OCP sub-option MUST be included in response to a unicast DIS.
> >>> Similar to
> >> Exactly, MUST on unicast DIS responses and MAY otherwise would make
> >> sense!
> >>
> >> Currently I am afraid it is an option that is a MUST in all cases
> >> (but that might change ;-). From the Metrics document:
> >>
for
> >> the DODAG. This option is a MUST in DIOs that are responses to
> >> unicast DIS.
> >>
> >>
> >> Best regards,
> >> -- Joakim Eriksson, SICS
> >>
> >>
> >>
> >>> Dario
> >>>> Best regards,
> >>>> -- Joakim Eriksson, SICS
> >>>>
> >>>>> Is there any reason why the OCP can't be placed in the DIO base
> >>>>> header, since there is now a 16bit reserved word available? Why
is
> >>>>> the OCP currently contained in a sub-option, when a joining node
> >>>>> requires it to determine what OF to use or to filter on.
> >>>>>
> >>>>> Dario
> >>>>>
> >>>>> Tim Winter wrote:
> >>>>>> Hi Dario,
> >>>>>>
> >>>>>>> Seems that the new "RPL Target" sub-option uses the same
> >>>>>>> type-value
> >>>>>>> (5)
> >>>>>> leaving OCP Option value 5 to the metrics draft, and
incrementing
> >>>>>> the RPL Target through Prefix Information as follows:
> >>>>>>
> >>>>>>
> >>>>>> Option Name Draft

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 04 Jun 2010 10:42:19 -0700

Hi Pascal

I'm all for keeping OCP at 16bits for the same reasons you've mentioned.

Regards
Dario

Pascal Thubert (pthubert) wrote:
>>>>> how the config sub-option works. Alternatively, just add OCP to
>>>>>           
> the
>   
>>>>> config sub-option, which would solve the "[redundant] constant
>>>>>           
> data"
>   
>>>>>>>> This is a mistake. We can correct the option numbering for -09
>>>>>>>>                 
> by
>