Subject: [manet] DLEP to a WG document

From: Joseph Macker <[email-masked]>
Date: Thu, 7 Oct 2010 12:49:59 -0400

All:

The initial DLEP draft was presented in Maastricht and there was discussion
of adopting it as a WG document.  The response at the time was positive and
we discussed giving the list time to comment.  I have received only positive
input so far that this is a valuable contribution and worth working within
the WG due to the unique needs of manet router/radio interfacing.

Assuming the authors are still willing we will proceed with adopting the
document.

-Joe

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 7 Oct 2010 14:04:57 -0400

Joe,

The authors are willing!  This is good news.

Regards,
Stan

On Oct 7, 2010, at 12:49 PM, Joseph Macker wrote:

> All:
>
> The initial DLEP draft was presented in Maastricht and there was  
> discussion of adopting it as a WG document.  The response at the  
> time was positive and we discussed giving the list time to comment.   
> I have received only positive input so far that this is a valuable  
> contribution and worth working within the WG due to the unique needs  
> of manet router/radio interfacing.
>
> Assuming the authors are still willing we will proceed with adopting  
> the document.
>
> -Joe

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Thu, 7 Oct 2010 14:23:14 -0400

Great to hear!

This is really a needed document to standardizing modem/radio-to-router interfaces. A few comments:

 1.  Link Stability TLV - Is it possible to add a TLV that describes how stable an RF link is? In testing, some RF links go down hard when the link is broken while others flop up and down. The link flopping often causes unwanted OSPF SPF calculations. Perhaps a definition would be something like "RF link availability in the past X seconds where X is defaulted to 10 seconds".. Or something like "Average RF link uptime in ms"

2. Separation in TLV between common subset and vendor specific. Some of the TLVs for link quality can be equated from different kinds of radio technologies (omni, tdma, directional, etc.).. .such as MDR, CDR, Latency. Others like RLQ and Resources are harder to define and compare apples-to-apples between disparate radio types (ie: one radio might use Viterbi bit error rate for RLQ while another might have a combination of # of frequencies and time slots). Perhaps separating TLVs into two categories - one that describes apples-to-apples link metrics, and ones that allow vendors to be creative with their radio selection would be appropriate.

3. Flow Control - RFC4938/5578 described a credit-based flow control algorithm. My understanding is that DLEP uses the CDR TLV to provide rate-based flow control. Is there a way that one can guarantee that the CDR reports accurate rate the radio can support? For example, with the credit-based flow control model, the radio could be operating at 2Mbps, but because of lack of frequency or high modem CPU load, it might throttle the data rate the router can send to less. Is there a mechanism to handle this without simply changing CDR rapidly?

4. Link Quality TLVs - In the current instantiation where OSPF recomputes SPF everytime link metrics change, it is desirable to be able to provide hysteresis on things that change rapidly (like latency). Although Section 7.9 describes the Latency as something that modem devices calculate separately, perhaps giving some defaults like "latency should be averaged every 10 seconds and sent no more than 10 seconds at a time by default"... Might help standardize the metrics a bit more.

Just some thoughts for discussion..

-Bow-Nan

On 10/7/10 2:04 PM, "Stan Ratliff" <[email-masked]> wrote:

Joe,

Regards,
Stan

> Assuming the authors are still willing we will proceed with adopting

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

--
Bow-Nan Cheng, Ph.D.
MIT Lincoln Laboratory
Airborne Networks Group
244 Wood St Lexington MA 02420
781-981-4997

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 11 Oct 2010 09:07:14 -0700

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Macker
Sent: Thursday, October 07, 2010 9:50 AM
To: [email-masked]; Stan Ratliff
Subject: [manet] DLEP to a WG document

All:

The initial DLEP draft was presented in Maastricht and there was discussion of adopting it as a WG document.  The response at the time was positive and we discussed giving the list time to comment.  I have received only positive input so far that this is a valuable contribution and worth working within the WG due to the unique needs of manet router/radio interfacing.

Assuming the authors are still willing we will proceed with adopting the document.

-Joe

Joe and Stan,

I reviewed the document published last week and I support the MANET WG working on a standard protocol for radio to router communications.

Has there been any consideration of extending existing protocols before starting down the path of a new protocol?  There is no related work cited in this document, but I'm curious how it may relate to other similar problem spaces and mechanisms defined elsewhere (e.g. detecting network attachment WG (DNA)) as well as the approach of extending IPv6 neighbor discovery for specialized environments (e.g. http://tools.ietf.org/html/draft-ietf-6lowpan-nd-13).  The current draft only deals with protocol issues at a high level and I expect there will need to be a lot of further work done to get to a robust, interoperable specification.

Is it intended to specify how this protocol is transported over Ethernet (and other L2 technologies)?  The draft is vague on this point but it mentions using DTLS which implies UDP or DCCP, but that in turn implies that the modems have IP addresses (not sure whether that is the intent).

Regards,
Tom

---

From: <[email-masked]>
Date: Wed, 13 Oct 2010 15:56:03 +0100

Tom asks about relating to work in the DNA group. We wrote:
http://tools.ietf.org/html/draft-wood-dna-link-properties-advertisement
and presented it in Dublin, but at the time that workgroup was shutting down and reluctant to take on new work. That draft didn't go anywhere.

This approach, like that one, should be entirely UDP-based. Not using PPPoE should be a requirement...

All:

-Joe

Joe and Stan,

Regards,
Tom

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Oct 2010 08:25:28 +0200

On Wed October 13 2010 16:56:03 [email-masked] wrote:
> and presented it in Dublin, but at the time that workgroup was shutting
> down and reluctant to take on new work. That draft didn't go anywhere.
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joseph Macker Sent: Thursday, October 07, 2010 9:50 AM
> of adopting it as a WG document.  The response at the time was positive
> and we discussed giving the list time to comment.  I have received only
> positive input so far that this is a valuable contribution and worth
> working within the WG due to the unique needs of manet router/radio
> interfacing.
> 
> I reviewed the document published last week and I support the MANET WG
> working on a standard protocol for radio to router communications.
> 
> Has there been any consideration of extending existing protocols before
> starting down the path of a new protocol?  There is no related work cited
> in this document, but I'm curious how it may relate to other similar
> problem spaces and mechanisms defined elsewhere (e.g. detecting network
> attachment WG (DNA)) as well as the approach of extending IPv6 neighbor
> discovery for specialized environments (e.g.
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd-13).  The current draft
> only deals with protocol issues at a high level and I expect there will
> need to be a lot of further work done to get to a robust, interoperable
> specification.
> 
> Is it intended to specify how this protocol is transported over Ethernet
> (and other L2 technologies)?  The draft is vague on this point but it
> mentions using DTLS which implies UDP or DCCP, but that in turn implies
> that the modems have IP addresses (not sure whether that is the intent).
I think DLEP should NOT specifiy a transport between the radio and the router, 
just make a few suggestions. Some radios will be conntected through ethernet 
(so they can use UDP), some will use PPPoE, some will use a serial line, some 
might be a PCMCIA-card !

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: <[email-masked]>
Date: Thu, 14 Oct 2010 08:46:42 +0100

> (so they can use UDP), some will use PPPoE, some will use a serial line, some 

It's just a transport for control messages, not for data.

The IETF does things related to IP; UDP is pretty much universal in that IP context (unlike PPPoE), and runs over the scenarios you give. Except for obsolete PCMCIA cards, which are not the IETF's problem.

IP is pretty much assumed to be the base transport here.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 14 Oct 2010 10:38:57 -0400

That's one of the reasons we specified RFC 5444. It's transport  
independent. So, we could theoretically support UDP, or a bus-based  
message-passing scheme. The initial implementation (at least from  
Cisco's perspective) will be UDP based.

Regards,
Stan

On Oct 14, 2010, at 3:46 AM, <[email-masked]>  
<[email-masked]> wrote:

> The IETF does things related to IP; UDP is pretty much universal in  
> that IP context (unlike PPPoE), and runs over the scenarios you  
> give. Except for obsolete PCMCIA cards, which are not the IETF's  
> problem.
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Oct 2010 07:50:57 +0200

> Cisco's perspective) will be UDP based.
I am okay with suggesting UDP as the default solution. It just should not be 
mandatory.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 15 Oct 2010 11:21:09 -0400

Henning,

If the consensus of the WG is to suggest UDP as a default transport,  
I'll put that in the document. However, my preference would be to  
leave the DLEP document as-is, leveraging the transport independence  
of RFC 5444.

Regards,
Stan