Subject: [Roll] FW: PIO, CO and MTU options in DIOs

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Jun 2010 21:49:06 +0200

Hi Dave:

In the light of this thread, I'd wish to ask you to reconsider your
decision to refuse to transport the MTU option in DIOs.

An inconsistent MTU across the RPL subnet will have a number of
consequences:

- It will impose the expensive and not fully functional support of PMTUD
in the nodes, which means also states per final destinations.

- 6LoWPAN imposes 1280 but we need to make it more for RH4:

"   To help avoid IP-layer fragmentation, the RH4 header has a maximum
   size of RH4_MAX_SIZE octets and links within a RPL domain SHOULD have
   a MTU of at least 1280 + 40 (outer IP header) + RH4_MAX_SIZE (+
   additional extension headers or options needed within RPL domain)
   octets."

We can make the node implementation smaller and safer if we impose the
MTU from the root.

More in http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-02 

Pascal

-----Original Message-----
From: Daniel Gavelle [mailto:[email-masked]] 
Sent: Monday, June 14, 2010 10:43 AM
To: Dario Tedeschi
Cc: Pascal Thubert (pthubert); ROLL WG
Subject: PIO, CO and MTU options in DIOs

Dario / Pascal,

I can see that sending PIO / CO / MTU in DIO messages has some
advantages.  Since there is already a mechanism in 6LowPAN-ND for this,
I am concerned that allowing these messages to be carried in RPL will
result in interoperability issues.

I suppose the best way forward for the RPL specification is to allow
these options as a MAY.  Alliances like Zigbee and IPSO would then
ensure interoperability by requiring one method in their stack profile
specifications.

Regarding the MTU, I can see how this is needed for networks using a
mixed Ethernet / 6LowPAN MAC, bridged at layer 2.  However, within the
6LowPAN, where the MTU is fixed, routers should be allowed to ignore the
option.  Also stack profiles that are aimed at 6LowPAN only MACs should
be allowed to exclude the MTU option in their specification.

Daniel.

Dario Tedeschi wrote:
> Hi Daniel
> 
> Daniel Gavelle wrote:
>> Dario,
>>
>> In a 6LowPAN network, the routers will need to do 6LowPAN-ND RS/RA in

>> order to distribute the compression contexts.  I suppose the context
>> (CO) option from 6LowPAN-ND could also be added to ROLL.  However, I 
>> prefer using 6LowPAN-ND for context and prefix dissemination and ROLL

>> for routing.
> A CO is link-layer information so some might argue that it does not 
> below in a routing protocol. Fair enough, but lets be practical here:
> RPL provides a robust way of distributing information amongst routers 
> in a LLN network. Why not use it.
>>
>> Also, if the prefix / context information is distributed in ROLL, 
>> either hosts need to support ROLL or routers need to support two 
>> methods for prefix distribution: RS/RA (for hosts) and prefix 
>> distribution in ROLL.
> I'm not advocating hosts use ROLL, so lets look at your second option 
> where routers need to support two methods for prefix distribution: 
> Even if a network only used 6LoWPAN ND for prefix distribution, 
> routers still need two methods: One-hop RS/RA for router-host prefix 
> distribution and
> RA+ARBO to deal with router-to-router prefix distribution. In fact if
> you look at an RA+ARBO message, it looks remarkably similar to a DIO 
> message (where the Version and Address fields in the ARBO can be 
> equated to the Version and DAGID fields in the DIO, respectively). 
> Seems to me, 6LoWPAN ND (with multi-hop) is trying to do the work of a

> routing protocol. I think "Neighbor Discovery" should be taken a bit 
> more literally in that it is a protocol for discovering your neighbors

> and not for distributing network configuration (the exception being 
> that one would like a host to auto-configure).
> 
> Hope you have good weekend
> Dario
>>
>> Daniel.
>>
>>
>> Dario Tedeschi wrote:
>>> Hi Daniel and Pascal
>>>
>>> I agree with Pascal here.
>>>
>>> In my view of a LLN network: Routers form the sub-net cloud while 
>>> hosts just "connect" to that cloud. How routers form and maintain 
>>> that cloud should not be handled by ND (in my opinion). I see 
>>> routers using the routing protocol to exchange sub-net information 
>>> amongst themselves, while hosts use RS/RA to request sub-net 
>>> information from nearby routers. Both routers and hosts may use 
>>> NS/NA to perform address-resolution and NUD one hop away only.
>>>
>>> Dario
>>>
>>> Pascal Thubert (pthubert) wrote:
>>>> Hi Daniel:
>>>>
>>>> What I read below is that for RPL over foo (foo != 6LoWPAN),  you'd

>>>> run ND RA as the dissemination protocol for the MTU information. I 
>>>> suggest that is a very bad idea. RPL DIO is very optimized as a 
>>>> dissemination protocol, in particular with the use of trickle. And 
>>>> we don't want 2 mechanisms in parallel doing the same thing.
>>>> So unless we merge (back) RA and DIO, I'd suggest that RPL routers 
>>>> use RPL when they disseminate information about the subnet and do 
>>>> not bother about RAs from other routers.
>>>>
>>>> Today, RPL operation does not depend on RAs at all. In fact, it is 
>>>> the other way around. RPL handles everything multihop, whereas RA 
>>>> is used for router to host communication.
>>>> In that model, we expect RPL to disseminate information that can 
>>>> then be incorporated by the routers in their RAs for local 
>>>> distribution to their attached hosts.
>>>> That is what we do with PIO and RIO. MTU would be the same.
>>>>
>>>> Pascal
>>>>
>>>>
>>>>  
>>>>> -----Original Message-----
>>>>> From: Daniel Gavelle [mailto:[email-masked]]
>>>>> Sent: Wednesday, June 09, 2010 2:10 PM
>>>>> To: Pascal Thubert (pthubert)
>>>>> Cc: JP Vasseur; ROLL WG
>>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09 to 
>>>>> be
>>>>>     
>>>> posted in
>>>>  
>>>>> 3 days!
>>>>>
>>>>> Pascal,
>>>>>
>>>>> If the link has a variable sized MTU, the MTU option can be sent 
>>>>> in an
>>>>>     
>>>> RA, as
>>>>  
>>>>> in RFC 4861.  ND RS/RA can be done before sending DIS and joining 
>>>>> a
>>>>>     
>>>> ROLL
>>>>  
>>>>> DAG.
>>>>>
>>>>> Daniel.
>>>>>
>>>>>
>>>>> Pascal Thubert (pthubert) wrote:
>>>>>  
>>>>>> Hi Daniel:
>>>>>>
>>>>>>    
>>>>>>> If the MTU option is required by other link layers, why can't 
>>>>>>> the
>>>>>>>         
>>>> MTU
>>>>  
>>>>>> option
>>>>>>    
>>>>>>> be sent in ND?
>>>>>>>         
>>>>>> I return the question. How would that work?
>>>>>>
>>>>>> Pascal
>>>>>>
>>>>>>
>>>>>>    
>>>>>>> -----Original Message-----
>>>>>>> From: Daniel Gavelle [mailto:[email-masked]]
>>>>>>> Sent: Wednesday, June 09, 2010 1:39 PM
>>>>>>> To: Pascal Thubert (pthubert)
>>>>>>> Cc: JP Vasseur; ROLL WG
>>>>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09 
>>>>>>> to
>>>>>>>         
>>>> be
>>>>  
>>>>>> posted in
>>>>>>    
>>>>>>> 3 days!
>>>>>>>
>>>>>>> Pascal,
>>>>>>>
>>>>>>> I am interested in 6LowPAN, where RFC4944 fixes the MTU at 1280 
>>>>>>> octets
>>>>>>>         
>>>>>> so
>>>>>>    
>>>>>>> the MTU option isn't required.
>>>>>>>
>>>>>>> If the MTU option is required by other link layers, why can't 
>>>>>>> the
>>>>>>>         
>>>> MTU
>>>>  
>>>>>> option
>>>>>>    
>>>>>>> be sent in ND?
>>>>>>>
>>>>>>> Daniel.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>>      
>>>>>>>> Hi Daniel
>>>>>>>>
>>>>>>>> Do you think that the MTU within the LLN should be the same?
>>>>>>>>
>>>>>>>> Pascal
>>>>>>>>
>>>>>>>>        
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>>             
>>>>>> Behalf
>>>>>>    
>>>>>>>> Of
>>>>>>>>        
>>>>>>>>> Daniel Gavelle
>>>>>>>>> Sent: Wednesday, June 09, 2010 11:52 AM
>>>>>>>>> To: JP Vasseur
>>>>>>>>> Cc: ROLL WG
>>>>>>>>> Subject: Re: [Roll] Feed-back appreciated for RPL Revision -09

>>>>>>>>> to
>>>>>>>>>             
>>>>>> be
>>>>>>    
>>>>>>>> posted in
>>>>>>>>        
>>>>>>>>> 3 days!
>>>>>>>>>
>>>>>>>>> I think the MTU and SLLA options should not be in ROLL but 
>>>>>>>>> only
>>>>>>>>>             
>>>>>> used
>>>>>>    
>>>>>>>> in ND.
>>>>>>>>        
>>>>>>>>> I haven't used the S bit in my implementation.
>>>>>>>>>
>>>>>>>>> Daniel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> JP Vasseur wrote:
>>>>>>>>>          
>>>>>>>>>> Dear WG,
>>>>>>>>>>
>>>>>>>>>> One more time, thanks for your energy and involvement to keep

>>>>>>>>>> us
>>>>>>>>>>               
>>>>>> on
>>>>>>    
>>>>>>>>>> track with our plan for RPL.
>>>>>>>>>>
>>>>>>>>>> The cut-off date for the Virtual WG meeting that will take 
>>>>>>>>>> place
>>>>>>>>>>               
>>>>>> on
>>>>>>    
>>>>>>>> June
>>>>>>>>        
>>>>>>>>>> 16 is this coming Friday and the RPL authors team has been
>>>>>>>>>>               
>>>> working
>>>>  
>>>>>>>> hard
>>>>>>>>        
>>>>>>>>>> on the revision -09, which should solve a number of the 
>>>>>>>>>> opened
>>>>>>>>>>               
>>>>>>>> tickets.
>>>>>>>>        
>>>>>>>>>> Still there are a few items that triggered some discussion 
>>>>>>>>>> but
>>>>>>>>>>               
>>>> we
>>>>  
>>>>>>>> would
>>>>>>>>        
>>>>>>>>>> need more feed-back from you to draw a consensus to move on.
>>>>>>>>>>
>>>>>>>>>> 1) Are we keeping the use of sibling (S Bit thread): see the
>>>>>>>>>>               
>>>>>>>> detailed
>>>>>>>>        
>>>>>>>>>> discussion on the ML.
>>>>>>>>>> https://svn.tools.ietf.org/wg/roll/trac/ticket/43
>>>>>>>>>>
>>>>>>>>>> 2) Use of MTU and SSLA option:
>>>>>>>>>> https://svn.tools.ietf.org/wg/roll/trac/ticket/42
>>>>>>>>>>
>>>>>>>>>> Any quick feed-back on the list would be appreciated, for
rev09.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> JP.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Roll mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>>>>>>
>>>>>>>>>>               
>>>>>>>>> --
>>>>>>>>> __________________________________________________
>>>>>>>>> Daniel Gavelle, Software Engineer
>>>>>>>>> Tel: +44 114 281 2655
>>>>>>>>> Fax: +44 114 281 2951
>>>>>>>>> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg
No:
>>>>>>>>> 3191371  Registered In England http://www.jennic.com 
>>>>>>>>> __________________________________________________
>>>>>>>>> _______________________________________________
>>>>>>>>> Roll mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>>>>>             
>>>>>>> --
>>>>>>> __________________________________________________
>>>>>>> Daniel Gavelle, Software Engineer
>>>>>>> Tel: +44 114 281 2655
>>>>>>> Fax: +44 114 281 2951
>>>>>>> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No:
>>>>>>> 3191371  Registered In England http://www.jennic.com 
>>>>>>> __________________________________________________
>>>>>>>         
>>>>> --
>>>>> __________________________________________________
>>>>> Daniel Gavelle, Software Engineer
>>>>> Tel: +44 114 281 2655
>>>>> Fax: +44 114 281 2951
>>>>> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 
>>>>> 3191371  Registered In England http://www.jennic.com 
>>>>> __________________________________________________
>>>>>     
>>>> _______________________________________________
>>>> Roll mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>   
>>>
>>>
>>
> 
> 

--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371
Registered In England http://www.jennic.com
__________________________________________________