Subject: Re: [6lowpan] how many drafts

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 11 Oct 2005 12:02:27 -0700 (PDT)

Hi Gabe,

Thanks for your response.

I have a few questions regarding the routing solutions on Lowpan:

- Are we going to go ahead with lowpan-aodv draft?
    If so, I'd like to pass some modification requests that we have  
   discovered during an exercize of its implementation.
    
- Are we going to merge lowpan-aodv and LOAD draft?
    - If yes, then we need to review this draft seriously. It is RFC3561
      based. 
      
 IMHO, neigther AODV-bis nor RFC3561 are quite suitable for lowpan routing;
 It'd be much nicer if we come up with a lowpan routing protocol based on
 DYMO/AODV/AODVbis flavors.  It is unlikely that lowpan tiny devices will
 route packets for the regular internet, hence the modified standard version
 protocol makes more sense for the lowpan world.
 
 I am not quite sure how it is useful to have lowpan-aodv, lowpan-dymo and
 lowpan-aodvbis etc. as opposed to one draft that covers lowpan concerns
 and is based on  parts of AODV/AODVbis and DYMO features. That way we will 
 not be tying lowpan's fate on success of the corresponding protocols
 through the IETF process. But I may be too optimistic.
 
 -Samita

 
> --- Samita Chakrabarti <[email-masked]> wrote:
> > A presentation on the lowpan-aodv(or merged Load) would be  potential
> > interest to many, I suppose.
> 
> I'm suppose this will happen. Perhaps Prof. Kim of Ajou Univ. will provide the
> update.
> 
> Along these lines, you were asking about DyMO. I had started something with 
Ian
> Chakeres but never submitted it as an I-D (though I did send a pointer 
previous
> to Paris). I'm pleased to say the Prof. Kim of Ajou Univ. and Daniel will be
> helping out with this, so perhaps we'll see something about this as well in
> Vancouver.
> 
> You had asked about what was the future of AODVbis. This is a question to ask
> in MANET, I guess. 
> 
> Ian, do you know?
> 
> -gabriel

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 12 Oct 2005 00:07:36 -0700 (PDT)

>     - If yes, then we need to review this draft seriously. It is RFC3561

As Daniel mentioned, LOAD is what we're working on going forward. 

>  protocol makes more sense for the lowpan world.

I believe an adapted protocol is the idea, yes. I think inventing something
new won't happen (at least not in this WG, it might in MANET or something else
in the routing area). But I believe it should be ok for lowpan to adapt 
an existing protocol. Perhaps not all fields are needed. Perhaps not all
features are needed. The current drafts already started the adaptation because
I don't believe they include all the bells and whistles in aodv or dymo, right?
I guess we're in agreement.

>  through the IETF process. But I may be too optimistic.

Again, these protocols are already adaptations of any of the above, right?
So I'm not sure they'll create hard dependencies. In other words, within the
LOAD document, AODV should perhaps appear as an informational reference.
It is not a normative reference because implementing AODV per the RFC
is not a pre-requisite for this to work and be interoperable. Actually,
implementing it won't help lowpan meshing, cuz AODV per the RFC uses UDP
as transport, whereas LOAD (or any other mesh for lowpan protocol) uses
the lowpan adaptation layer as transport. So one could argue that the
AODV RFC (or AODV-bis draft) is not normative, so it wouldn't tie LOAD
in the publication process. But we're *very* far from that problem so 
I wouldn't worry about it yet.

-gabriel

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 12 Oct 2005 17:14:24 +0900

> I wouldn't worry about it yet.

Please make sure what implications are described in LOAD.

<snip>
3. Overview
This section describes the distinctive features of LOAD compared to
AODV.  LOAD is defined to be operating on top of the adaptation layer
instead of the transport layer.
<snip>

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.