Subject: Re: [manet] Data Link Exchange Protocol

From: Ulrich Herberg <[email-masked]>
Date: Fri, 6 Aug 2010 17:21:06 +0200

I also think that this document is interesting and in scope for the MANET WG.

Ulrich

On Tue, Jul 27, 2010 at 4:47 PM, Thomas Heide Clausen
<[email-masked]> wrote:
> 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
>
> On Fri, Jul 23, 2010 at 3:08 PM, Teco Boot <[email-masked]> wrote:
>>
>> 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:
>>
>> > 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
>> > <DLEP-draft.txt>
>> > _______________________________________________
>> > manet mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/manet
>>
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 9 Aug 2010 08:01:31 +0200

> I also think that this document is interesting and in scope for the MANET

I also support this document as a WG document.

I know there is a rival approach based on a PPPoE extension from Cisco which 
is already used, but it's neither extensible nor really well done, so this 
might become a very interesting and useful addition to any kind of radio 
system for wireless communication.

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: Mon, 9 Aug 2010 09:32:31 +0100

On 9 Aug 2010, at 07:01, Henning Rogge wrote:

> is already used, but it's neither extensible nor really well done,

Henning,

You're referring to RFC4938 and RC5578 by Bo Berry, Stan Ratliff et al.

http://tools.ietf.org/html/draft-sratliff-dlep by Bo Berry, Stan Ratliff
et al. is very similar in terms of use of TLVs, metrics, etc.

> so this 
> <signature.asc>_______________________________________________
> manet mailing list
> [email-masked]

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

---

From: "Rogge Henning" <[email-masked]>
Date: Mon, 9 Aug 2010 10:57:14 +0200

> Von: [email-masked] [mailto:[email-masked]] 
> 
> http://tools.ietf.org/html/draft-sratliff-dlep by Bo Berry, 
> Stan Ratliff et al. is very similar in terms of use of TLVs, 
> metrics, etc.
Yes.

RFC 5578 has several drawbacks in my oppinion.

First it mixes up a channel between two routers (PPP) with a control channel
between the radio and the router. I'm not sure this is a good idea.

It has no concept of addresses (or address tlvs) except as a parameter of a
TLV. This makes the RFC hard to use in a radio enviroment with more than two
radios, because it cannot encode parameters for the radios. It prevents the
radio doing neighbor discovery on the MAC layer and propagating quality data
back to the higher layers on the router.

I think using RFC 5444 (packetbb) for this is a better sollution.

The other thing I noticed is the definition of the link quality metric. It
assumes that unmeasurable links are always perfect quality. This will make a
network NOT to use links with a measurable quality, which makes upgrading
networks hard. In addition to this the minimal bandwith is 1 kbit/s, which
might be too high for HF radios.

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: Stan Ratliff <[email-masked]>
Date: Tue, 10 Aug 2010 20:01:11 -0400

Teco,

>>> would help. Something like RFC 5578 figure 1.

I'll work something like the figure you reference into the next  
version of the draft.

>>> used, how are the peer IP addresses discovered? Are DLEP messages  

The DLEP protocol suggests that the modem device can be delivered RFC  
5444 packets. In some implementations, this is done over UDP. Most  
radio devices have a UDP stack, as they are configured via Telnet, or  
HTTP. Also, since these devices support SNMP, they'll have the  
necessary stack. In cases where the transport is RFC 5444 via UDP, the  
IP addressability on the modem device falls into the same category as  
the config tools. Therefore, I don't see any impact on multicast (the  
modem would treat it as it currently does), unless I"m missing  
something.

>>> needed. Are asymmetric metrics supported, and if so, what model is  

I believe the DLEP draft would support asymmetric links -- at least  
links where bi-directional connectivity exists, though potentially at  
different speeds. This is analogous to RFC 5778 operation. In RFC  
5778, each side of a connection gets metrics that represent the  
ability of that side to send to the partner. If one side runs at a  
slower speed than the other, different "send metrics" are reported to  
the respective routers.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 11 Aug 2010 09:26:09 +0200

Stan,

Op 11 aug 2010, om 02:01 heeft Stan Ratliff het volgende geschreven:

> I'll work something like the figure you reference into the next version of the draft.
> 
>>>> 
> The DLEP protocol suggests that the modem device can be delivered RFC 5444 packets. In some implementations, this is done over UDP. Most radio devices have a UDP stack, as they are configured via Telnet, or HTTP. Also, since these devices support SNMP, they'll have the necessary stack. In cases where the transport is RFC 5444 via UDP, the IP addressability on the modem device falls into the same category as the config tools. Therefore, I don't see any impact on multicast (the modem would treat it as it currently does), unless I"m missing something.

I expect bridges replicate multicast on all port, unless there is a L2 multicast management protocol.
I don't like a mechanism where local management traffic (on high speed Ethernet) is flooded over an relatively low speed radio.
Using a management port or management VLAN would solve this issue. Or other mechanism.
More text and figure on the architecture would make things more clear (remarks above), and I suggest adding some text that the modem should keep this DLEP traffic local. 

> I believe the DLEP draft would support asymmetric links -- at least links where bi-directional connectivity exists, though potentially at different speeds. This is analogous to RFC 5778 operation. In RFC 5778, each side of a connection gets metrics that represent the ability of that side to send to the partner. If one side runs at a slower speed than the other, different "send metrics" are reported to the respective routers.

I think it is important to specify the semantics of the provided metrics. For what direction does this data apply?
OSPF-MANET and OLSR have different requirements here: OSPF requires outbound direction, OLSR inbound.
Maybe DLEP could support both models, and mode is negotiated.

Regards, Teco

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 11 Aug 2010 12:48:38 -0400

Teco,

On Aug 11, 2010, at 3:26 AM, Teco Boot wrote:

>> The DLEP protocol suggests that the modem device can be delivered  
>> RFC 5444 packets. In some implementations, this is done over UDP.  
>> Most radio devices have a UDP stack, as they are configured via  
>> Telnet, or HTTP. Also, since these devices support SNMP, they'll  
>> have the necessary stack. In cases where the transport is RFC 5444  
>> via UDP, the IP addressability on the modem device falls into the  
>> same category as the config tools. Therefore, I don't see any  
>> impact on multicast (the modem would treat it as it currently  
>> does), unless I"m missing something.
>
> I don't like a mechanism where local management traffic (on high  
> speed Ethernet) is flooded over an relatively low speed radio.
> More text and figure on the architecture would make things more  
> clear (remarks above), and I suggest adding some text that the modem  
> should keep this DLEP traffic local.
>
>
>> links where bi-directional connectivity exists, though potentially  
>> at different speeds. This is analogous to RFC 5778 operation. In  
>> RFC 5778, each side of a connection gets metrics that represent the  
>> slower speed than the other, different "send metrics" are reported  
>> to the respective routers.
>
> I think it is important to specify the semantics of the provided  
> metrics. For what direction does this data apply?

OK, what if we changed the metric packet to include both inbound and  
outbound bandwidth? That way, no negotiation would be required, and  
the routing protocol could select the data it needs.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 11 Aug 2010 19:21:17 +0200

Stan,

Op 11 aug 2010, om 18:48 heeft Stan Ratliff het volgende geschreven:

> OK, what if we changed the metric packet to include both inbound and outbound bandwidth? That way, no negotiation would be required, and the routing protocol could select the data it needs.
If information is available, it can be provided without high costs.
If it is optionally available, e.g. it requires transfer over the radio, it should be made available only if needed.
This can be configuration or negotiation. 

It is not only bandwidth, it applies to other metrics also. Maybe the whole set. 

Regards, Teco

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 11 Aug 2010 14:03:27 -0400

Teco,

On Aug 11, 2010, at 1:21 PM, Teco Boot wrote:

>>>> have the necessary stack. In cases where the transport is RFC  
>>>> 5444 via UDP, the IP addressability on the modem device falls  
>>>> into the same category as the config tools. Therefore, I don't  
>>>> see any impact on multicast (the modem would treat it as it  
>>>> currently does), unless I"m missing something.
>>>
>>> clear (remarks above), and I suggest adding some text that the  
>>> modem should keep this DLEP traffic local.
>>>
>>>
>>>> I believe the DLEP draft would support asymmetric links -- at  
>>>> least links where bi-directional connectivity exists, though  
>>>> potentially at different speeds. This is analogous to RFC 5778  
>>>> operation. In RFC 5778, each side of a connection gets metrics  
>>>> that represent the ability of that side to send to the partner.  
>>>> If one side runs at a slower speed than the other, different  
>>>> "send metrics" are reported to the respective routers.
>>>
>>> OSPF-MANET and OLSR have different requirements here: OSPF  
>>> requires outbound direction, OLSR inbound.
>> OK, what if we changed the metric packet to include both inbound  
>> and outbound bandwidth? That way, no negotiation would be required,  
>> and the routing protocol could select the data it needs.
> If it is optionally available, e.g. it requires transfer over the  
> radio, it should be made available only if needed.
If you're talking about configuration in the radio, then I'm good to  
go with that. I'm concerned about putting routing-protocol-sensitive  
negotiation (or configuration) into DLEP itself. That just doesn't fit  
to me, making this protocol know (or care) about what routing protocol  
or protocols might be running.

> It is not only bandwidth, it applies to other metrics also. Maybe  
I'm OK with this. Are there other opinions on the list?

Regards,
Stan

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 11 Aug 2010 11:14:20 -0700

> I'm OK with this. Are there other opinions on the list?

Look in the IEEE 802.16 specification.  Table 14 (in Chapter 6 of the
-2004 version I have) contains the roughly four dozen MAC messages that
control the network segment.  Many of the variables trafficked here are
reflected one way or another in the MIB.  

Is not what your asking for is some way to reflect some of this data up
to layer 3?