Subject: [manet] Data Link Exchange Protocol

From: Stan Ratliff <[email-masked]>
Date: Tue, 20 Jul 2010 21:35:53 -0400

All,

My apologies for missing the submission deadline. Attached is the  
draft I'd like to discuss next week at the working group meeting.

Regards,
Stan

---

From: <[email-masked]>
Date: Thu, 22 Jul 2010 14:12:23 +0100

Stan,

your draft is interesting. Good to see attention on the area of getting smart adaptive modems and routers to interact better.

A question is whether MANET is the right home for this area; previous work in this area trying to provide a more generalised approach than leveraging PPPoE:

- http://tools.ietf.org/html/draft-floreani-ancp-wireless-00
- http://tools.ietf.org/html/draft-wood-dna-link-properties-advertisement-01

has struggled to find a home in the IETF and an appropriate interested workgroup. Is MANET the best fit? (and is MANET's suitability pretty much guaranteed for your draft by building on RFC5444?)

btw, there's some linefeed/pagination oddities in your draft; try looking at a2ps output (I see alternate blank pages) or cat the textfile and notice the multiple ctrl-L linefeeds where there should be one. Non-ascii characters (sections 9.2 and 12, message seq no description). And "Authors'" addresses.

cheers,

L.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 21 July 2010 02:36
To: MANET IETF
Subject: [manet] Data Link Exchange Protocol

All,

My apologies for missing the submission deadline. Attached is the draft I'd like to discuss next week at the working group meeting.

Regards,
Stan

---

From: Joe Macker <[email-masked]>
Date: Thu, 22 Jul 2010 10:44:03 -0400

IMHO, I think we need to at least talk about this in the manet WG. 
Since most of who build these things have done something in the past between LL-routers.
Most manet drafts allude to some crosslayering but do not specify how to do it.
Many of us have something that has worked in some form or another.

Its often a critical performance enhancer. 
Discussion of multiple open approaches/proposals is also a good thing.

In the past we had the idea of a separate "lower layer triggers" wg ,etc because some things are useful for more than just routing.
Perhaps something like that makes sense again if there is energy.

-Joe

On Jul 22, 2010, at 9:12 AM, <[email-masked]> <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 22 Jul 2010 15:08:53 -0400

I have read the draft and like the idea behind it.  I am not 100% sure that
MANET is the right wg for this work although I am 90% there.  As a developer
having this functionality integrated into modems would greatly increase the
potential of routing protocols built upon them.  That being said I have a
few comments with regard to the current submitted draft.

The draft lists potential TLV messages and their meaning but does not do a
good job distinguishing between packet TLVs, message TLVs and address block
TLVs (of which there are non but possibly should be).  Having an IANA
section which describes the allocations you are requesting would clear this
up as would always using packet/message/address before TLV.  Also defined in
this draft are a few message TLVs but they are not listed in the same way in
which the TLVs are listed, they should be.  

Some of the different messages are essentially the same and using up message
type space when an attached TLV would convey the same information seems
wasteful of message type space.  I would suggest merging Up/Down/Update
messages into one Update message type.  Furthermore I would suggest using
the provided address block structure to contain address information with
regards to link information.  These addresses could then easily be
associated with Up/Down/Update TLVS conveying the desired meaning.  This
restructuring buys a few things: address compression, ability to attach
multiple TLVs to the same address (Up and Update for example), using
multivalue update TLVs could assign distinct information for each "link"
efficiently or a single TLV would suffice if they share all properties.
Bandwidth requests are currently not well defined as depending on the medium
bandwidth to different "links" may differ.  Using the above address block
structure and changing Bandwidth requests to address block TLVs solves this.

"The authentication (packet) TLV MUST be the first TLV of the (packet TLV
block), and the authentication MUST start at the identification TLV..."
comment conflicts with the packet example given in section 8 where the
authentication (packet) TLV is listed after the Identification (packet) TLV.

Justin

> Sent: Tuesday, July 20, 2010 9:36 PM
> To: MANET IETF
> My apologies for missing the submission deadline. Attached is the draft
> I'd like to discuss next week at the working group meeting.
> 
> Regards,
> Stan

---

From: Teco Boot <[email-masked]>
Date: Fri, 23 Jul 2010 15:08:12 +0200

Hi Stan,

Thanks sharing this proposal. I think it is useful.

The document provides the details on message formats. There is some text on the larger picture, but I think some diagrams depicting the architecture would help. Something like RFC 5578 figure 1.

You suggest a protocol for inner communication in what we could call a MANET Node. Such a node is a MANET Router and a fixed connected L2 bridge (could be IP host). The proposal suggests that there could be IP connectivity between those objects. This has implications on the protocol. If multicast was used, should the bridge block those packets? If unicast is used, how are the peer IP addresses discovered? Are DLEP messages aggregated with other messages?

Another topic is the choice on which side of a link gets what information. Draft-dearlove-olsrv2-metrics proposes the routing protocol instance gets the L2 metrics for incoming side of links, OLSR/NHDP take care of metric transfer to TC originator. Other protocols work otherwise (e.g the OSPF-MANET family). There, in case of asymmetric metrics, it is assumed that the radios would run another (L2 or L3) protocol for metric transfer, if needed. Are asymmetric metrics supported, and if so, what model is proposed?

As others suggested, utility of the proposal exceeds MANET. Maybe we need another thought on the info container, as RFC5444 is meant for (although not limited to) MANET.

Regards, Teco

Op 21 jul 2010, om 03:35 heeft Stan Ratliff het volgende geschreven:

> <DLEP-draft.txt>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 27 Jul 2010 16:37:20 +0200

Hi Stan,
I think this draft is interesting and should be considered as candidate
future work in this WG ;)
Emmanuel

On Fri, Jul 23, 2010 at 3:08 PM, Teco Boot <[email-masked]> wrote:

> The document provides the details on message formats. There is some text on
> the larger picture, but I think some diagrams depicting the architecture
> would help. Something like RFC 5578 figure 1.
>
> You suggest a protocol for inner communication in what we could call a
> MANET Node. Such a node is a MANET Router and a fixed connected L2 bridge
> (could be IP host). The proposal suggests that there could be IP
> connectivity between those objects. This has implications on the protocol.
> If multicast was used, should the bridge block those packets? If unicast is
> used, how are the peer IP addresses discovered? Are DLEP messages aggregated
> with other messages?
>
> Another topic is the choice on which side of a link gets what information.
> Draft-dearlove-olsrv2-metrics proposes the routing protocol instance gets
> the L2 metrics for incoming side of links, OLSR/NHDP take care of metric
> transfer to TC originator. Other protocols work otherwise (e.g the
> OSPF-MANET family). There, in case of asymmetric metrics, it is assumed that
> the radios would run another (L2 or L3) protocol for metric transfer, if
> needed. Are asymmetric metrics supported, and if so, what model is proposed?
>
> As others suggested, utility of the proposal exceeds MANET. Maybe we need
> another thought on the info container, as RFC5444 is meant for (although not
> limited to) MANET.
>
> Regards, Teco
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 27 Jul 2010 16:47:19 +0200

As I stated in the meeting, I +1 to that this document is good and should be furthered.

Thomas

On Jul 27, 2010, at 16:37 , Emmanuel Baccelli wrote:

> Hi Stan,
> I think this draft is interesting and should be considered as candidate future work in this WG ;)
> Emmanuel
>