Subject: Re: [manet] DLEP and multi-hop neighbours

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 11:16:41 +0200

On 03/31/2012 05:59 PM, Das, Subir wrote:
> I do not think that Radio or client interface is considered as a L3 router but Server is.
> Also draft says: "DLEP is independent of the underlying link type and topology."

Yes (especially the type of connection between DLEP client and server 
can be anything), but I think the main goal of DLEP is to connect a 
radio/modem/layer-2 device with a router without loosing access to the 
layer-2 data.

If the radio already contains a full layer-3 router, then I am not sure 
DLEP is necessary.

Henning Rogge

> _Subir
>
> -----Original Message-----
> From: Henning Rogge [mailto:[email-masked]]
> Sent: Saturday, March 31, 2012 11:28 AM
> To: Das, Subir
> Cc: Cole, Robert G CIV USARMY CERDEC (US); [email-masked]; [email-masked]
> Subject: Re: [manet] DLEP and multi-hop neighbours
>
>  From the draft:
>
>> DLEP assumes that participating clients appear to the server as a
>> transparent bridge - specifically, the assumption is that the
>> destination MAC address for data traffic in any frame emitted by the
>> server should be the MAC address of the next-hop router or end-
>> device, and not the MAC address of any of the intervening clients.
>
> If the "Server/Radio/Interface" is a layer 3 router, why should it need DLEP?

-- 
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: "John Dowdell" <[email-masked]>
Date: Tue, 3 Apr 2012 10:45:57 +0100

If the radio implementation contains the radio function and the routing function, then I believe that DLEP is still necessary to allow the radio function to send radio metrics to the routing function.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 03 April 2012 10:17
To: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 11:44:30 +0200

> If the radio implementation contains the radio function and the routing function, then I believe that DLEP is still necessary to allow the radio function to send radio metrics to the routing functi…

Yes, thats right.

But would this also mean IP addresses to be transfered? Most likely they 
are known by the routing function, not the radio one.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 10:48:32 +0100

> > If the radio implementation contains the radio function and the routing
> function, then I believe that DLEP is still necessary to allow the radio
> function to send radio metrics to the routing function.
> 
> Yes, thats right.
> 

They are still of use to the DLEP peer, as it might just be using the DLEP association for analysis purposes, rather than routing.

Rick Taylor

> Sent: 03 April 2012 10:45
> To: [email-masked]
> > If the radio implementation contains the radio function and the routing
> function, then I believe that DLEP is still necessary to allow the radio
> function to send radio metrics to the routing function.
> 
> Yes, thats right.
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 13:51:14 +0200

> They are still of use to the DLEP peer, as it might just be using the DLEP association for analysis purposes, rather than routing.

What is the DLEP peer? Does DLEP communicate over the radio link? If it 
does not, how does it get the IP addresses?

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 13:10:38 +0100

By DLEP peer, I meant the DLEP server/router (rather than the radio).  Of course the DLEP server/router may not actually be doing any routing, just reporting.

Rick Taylor

> Sent: 03 April 2012 12:51
> To: [email-masked]
> > They are still of use to the DLEP peer, as it might just be using the
> DLEP association for analysis purposes, rather than routing.
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 14:16:06 +0200

> By DLEP peer, I meant the DLEP server/router (rather than the radio).  Of course the DLEP server/router may not actually be doing any routing, just reporting.

If I remember the DLEP draft right, the radio (client) is the 
information producer and the router (server) is the information consumer.

 > In order to implement discovery in the DLEP protocol (thereby
 > avoiding some configuration), we have defined a first-speaker and a
 > passive-listener scheme. Borrowing from existing terminology, this
 > document refers to the first-speaker as the 'client', and the passive
 > listener as the 'server', even though there is no client/server
 > relationship in the classic sense. In a typical deployment, a router
 > would appear as the DLEP 'server', and an attached modem device would
 > act as the 'client' (e.g. the initiator for discovery).

If this is right, I still would like to see a use-case where the radio 
knows about IP addresses and has to tell them the router.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 14:23:42 +0200

> knows about IP addresses and has to tell them the router.

Just to clarify this... I really do NOT want to remove anything from 
DLEP that is useful. But at the moment I lack the knowledge about the 
common usecase for IP-addresses in DLEP. Maybe someone can explain his 
usecase.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 13:32:41 +0100

The use-case as I see it is:  

1) A new (unknown) neighbour (modem+router pair) joins the radio net.
2) Each existing modem informs its associated router (server) via a NeighbourUp message of the new arrival.  Included in this message is the layer 2 and layer 3 IP addresses of the new *router*.
3) The routing protocol can now use the new router as a peer for whatever routing protocol it is running without resorting to neighbour discovery (as it is already discovered).

If the IP address is not included in the NeighbourUp message (but the layer 2 address is) then each existing router must perform some kind of discovery (ARP, or IPv6 equivalent) increasing control traffic across the radio net, before any useful router to router communication can be performed.

I hope that helps?

Rick Taylor

> From: Henning Rogge [mailto:[email-masked]]
> Sent: 03 April 2012 13:16
> To: Rick Taylor
> Cc: [email-masked]
> > By DLEP peer, I meant the DLEP server/router (rather than the radio).
> Of course the DLEP server/router may not actually be doing any routing,
> just reporting.
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 14:38:18 +0200

> 2) Each existing modem informs its associated router (server) via a NeighbourUp message of the new arrival.  Included in this message is the layer 2 and layer 3 IP addresses of the new *router*.

Where does the modem of the other side get the IP address? Why is the 
exchange of IP addresses not done between the routing daemons?

If I understand you right you added a custom "layer-3 IP" field into the 
layer-2 network announcement of your radio. In this case, forwarding 
this layer-3 data makes sense.

Does this mean that your layer-2 beacon/announcement contain ALL IP 
addresses of your router? Or just one IP that allows you to contact the 
router over the radio/modem?

> I hope that helps?

Yes, I think it did. We are getting to the important part of my problem. :)

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 13:54:14 +0100

> > 2) Each existing modem informs its associated router (server) via a
> NeighbourUp message of the new arrival.  Included in this message is the
> layer 2 and layer 3 IP addresses of the new *router*.
> 

It does not matter where the IP address is from, possibly DHCP, Autodiscovery, static assignment, etc...,  but it is expected that the address will be valid within the context of the radio net.

Of course, the neighbour IP address is an optional TLV, and we have some radios that do report it on NeighbourUp and some that don't.

The exchange of addresses can be done between the routers, but it may not be needed, and it is more efficient to not do it.  Currently on IPv4 networks I have to send specially crafted ICMP ping packets to populate both routers ARP tables, and this has to be done between each neighbour.  (There may be a better way but InARP isn't well-supported!)

> this layer-3 data makes sense.

As before, when IP addresses are available at the layer-2 control plane, the "radio magic" layer as Stan describes it, then it makes sense to report this via DLEP

> router over the radio/modem?

Only the IP addresses of the interface directly attached to the modem, i.e. the addresses accessible via the layer-2 network of the radios.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 15:02:18 +0200

On 04/03/2012 02:54 PM, Rick Taylor wrote:

> It does not matter where the IP address is from, possibly DHCP,
> Autodiscovery, static assignment, etc...,  but it is expected that
> the address will be valid within the context of the radio net.
>
> Of course, the neighbour IP address is an optional TLV, and we have
> some radios that do report it on NeighbourUp and some that don't.
>
> The exchange of addresses can be done between the routers, but it may
> not be needed, and it is more efficient to not do it.  Currently on
> IPv4 networks I have to send specially crafted ICMP ping packets to
> populate both routers ARP tables, and this has to be done between
> each neighbour.  (There may be a better way but InARP isn't
> well-supported!)

Okay.

>> If I understand you right you added a custom "layer-3 IP" field
>> into the layer-2 network announcement of your radio. In this case,
>> forwarding this layer-3 data makes sense.
>
> As before, when IP addresses are available at the layer-2 control
> plane, the "radio magic" layer as Stan describes it, then it makes
> sense to report this via DLEP

Especially in the context of bandwidth restrained radios this makes sense.

>> Does this mean that your layer-2 beacon/announcement contain ALL
>> IP addresses of your router? Or just one IP that allows you to
>> contact the router over the radio/modem?
>
> Only the IP addresses of the interface directly attached to the
> modem, i.e. the addresses accessible via the layer-2 network of the
> radios.

What would you think about having an address-TLV for this interface IP?
It would only be necessary if the IP is not equals to the mac generated
IPv6 linklocal IP.

If this resolves the usecase for IP addresses in DLEP messages, we could
use normal PacketBB addresses for all the MAC addresses. Which would us
to allow address compression for them.

And it would easily resolve the problem of "attaching" the addresses to
each other... and we would not need multi-length addresses.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 14:20:33 +0100

> What would you think about having an address-TLV for this interface IP?

There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) and IPv6 Address Sub-TLV (10.6, page 15)

These SHOULD be used when layer-3 addresses are known by the modem. (There has been some talk of generalizing them into a Layer-3 Address Sub-TLV of a sockets style [addr_family, addr_len, addr_octets] tuple, but I'm personally not bothered either way).

> It would only be necessary if the IP is not equals to the mac generated

Yes, one could calculate the IPv6 address from the neighbours MAC address and the receiver's prefix if an IPv6 address is not provided.
 
> each other... and we would not need multi-length addresses.

Yes, yes, yes!  This is what I have been trying to get across (badly!).  The Address-Block TLV's are all associated with layer-2 (MAC) addresses, with optional sub-TLV's in the block carrying layer-3 addresses when known.

Of course these Address-Block TLV's only apply to Neighbour* messages.  Any 'local' router<->modem messages (Peer*) should be Message TLV's as they do not have an address context that has any real meaning.

I hope that helps?

Rick Taylor

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 3 Apr 2012 08:26:27 -0500

I think a picture would help - multiple radios and multiple routers with multiple LAN and WAN where the WAN is the radio net.

- Will

On Apr 3, 2012, at 9:20 AM, Rick Taylor wrote:

I hope that helps?

Rick Taylor

Henning Rogge

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

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 15:28:50 +0200

> and IPv6 Address Sub-TLV (10.6, page 15)

Yes, but I think most of the discussion is about getting rid of the 
concept of sub-TLVs and only use what PacketBB does provide.

> These SHOULD be used when layer-3 addresses are known by the modem.
> (There has been some talk of generalizing them into a Layer-3 Address
> Sub-TLV of a sockets style [addr_family, addr_len, addr_octets]
> tuple, but I'm personally not bothered either way).

I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), one 
for IPv4 and one for IPv6 would be okay.

>> It would only be necessary if the IP is not equals to the mac
>> generated IPv6 linklocal IP.
>
> Yes, one could calculate the IPv6 address from the neighbours MAC
> address and the receiver's prefix if an IPv6 address is not
> provided.

And we could also do this calculation already in the DLEP client, so we 
do not need a special TLV for it.

>> If this resolves the usecase for IP addresses in DLEP messages, we
>> could use normal PacketBB addresses for all the MAC addresses.
>> Which would us to allow address compression for them.
>>
>> And it would easily resolve the problem of "attaching" the
>> addresses to each other... and we would not need multi-length
>> addresses.
>
> Yes, yes, yes!  This is what I have been trying to get across
> (badly!).  The Address-Block TLV's are all associated with layer-2
> (MAC) addresses, with optional sub-TLV's in the block carrying
> layer-3 addresses when known.

I hope you are still considering switching to normal (DLEP specific) 
TLVs... and using address TLVs for neighbor specific data (and not 
sub-tlvs at all).

> Of course these Address-Block TLV's only apply to Neighbour*
> messages.  Any 'local' router<->modem messages (Peer*) should be
> Message TLV's as they do not have an address context that has any
> real meaning.

Of course.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 14:51:16 +0100

> concept of sub-TLVs and only use what PacketBB does provide.

Do you mean: Do not use one message TLV-type for DLEP, with individual TLV's in the payload, but use 'top-level' TLV types for each DLEP TLV?

I can see the available numbers running out quickly, particularly with vendor-specific metric TLVs.

Can the <tlv-type-ext> (RFC5444, section 5.4.1, page 15) help here?  Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to tlv-type-ext?

I'm not a packetBB guru, but I can see both sides of the argument, but I am worried about lack of space in the numbering.

> for IPv4 and one for IPv6 would be okay.

I agree, but someone might start shouting about ATM, who knows?

> do not need a special TLV for it.

Hmmm... not always true, what if one neighbour had a shorter IPv6 prefix than the other.  Not ideal I know, but possible.  Remember in MANETs configurations often end up wrong.

> TLVs... and using address TLVs for neighbor specific data (and not

I'd like to hear Stan's opinion, as DLEP is his draft, not mine!

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 09:53:03 -0400

Rick and others,

I would like to go back to the original discussion of reporting multi-hop
topologies within the radio net with DLEP. It has always been the authors
intent that DLEP would only be used to report events(Up/Down) and link
metrics for neighbors that are one hop away. If the radio net happens to be
a layer2 mesh network, that should be transparent to routers running DLEP.
If the radios associated with this layer2 mesh choose to report, via DLEP,
neighbors that are 2 or more hops away in their layer2 mesh then that should
be transparent to the DLEP routers. The radio, with its knowledge of its own
layer2 mesh topology, should craft the DLEP neighbor metrics to account for
neighbors being multiple hops away.

Also I saw where it was mentioned that it would be nice if DLEP could report
link metrics in both directions. The original purpose for DLEP was reporting
up/down and link metrics to provide routing protocols with addition
information to make quicker and more informed decisions on how to reach
one-hop neighbors on a radio net. With that said, I don't understand how a
router would use an inbound traffic link metric. Help me understand the use
case.

Darryl Satterwhite
Cisco Systems

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 16:02:25 +0200

On 04/03/2012 03:51 PM, Rick Taylor wrote:
 >> Yes, but I think most of the discussion is about getting rid of
 >> the concept of sub-TLVs and only use what PacketBB does provide.
 >
 > Do you mean: Do not use one message TLV-type for DLEP, with
 > individual TLV's in the payload, but use 'top-level' TLV types for
 > each DLEP TLV?
 >
 > Can the<tlv-type-ext>  (RFC5444, section 5.4.1, page 15) help here?
 > Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to
 > tlv-type-ext?

You do not need to use the extension type for this.

Each Message type defined for PacketBB can have up to 96 message-type 
specific TLVs (the ids between 128 and 223 including all of their 
extension types). Unless you say that 96 TLVs are not enough for DLEP, 
we should be fine.

See RFC 5444, Section 6.4.

 >> I think using two DLEP-specific Address-TLVs (instead of sub-tlvs),
 >> one for IPv4 and one for IPv6 would be okay.
 >
 >> And we could also do this calculation already in the DLEP client,
 >> so we do not need a special TLV for it.
 >
 > Hmmm... not always true, what if one neighbour had a shorter IPv6
 > prefix than the other.  Not ideal I know, but possible.  Remember in
 > MANETs configurations often end up wrong.

the point is that DLEP does not care about the efficient transport over
the radio metric, it just can assume that the radio can decode it. DLEP
is only local traffic (not over radio), so we do not need to look at
compression that much.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 03 Apr 2012 16:09:27 +0200

On 04/03/2012 03:53 PM, Darryl Satterwhite wrote:
> topologies within the radio net with DLEP.

I am not really happy with this usecase, but I agree that it exists and 
we need a good solution for this.

> It has always been the authors

I do not like this solution because it would hide parts of what is going 
on from the routing protocol. Even if we do it the way you describe, 
DLEP would not be able to push out its full topology.

What do you think about this?

Instead of pushing out ALL the topology in a single DLEP message, we use 
the Originator field of the message for defining a "reference point" for 
the following neighbor data (no originator address means "this radio").

This means that the DLEP agent which has a full knowledge of the 
topology of the mesh below creates one Neighbor-Message for every node 
in the network, each containing the neighbors of this node and the known 
metric data.

I think this might solve the full mesh usecase.

(I would still like to have the option to switch off the meshing 
capability of the radio. Running a layer-3 mesh routing protocol over a 
layer-2 mesh routing protocol is a recipe for a disaster.)

> router would use an inbound traffic link metric. Help me understand the use

Yes, having asymmetric values for the same metric is a common use case. 
Maybe we could do this by using an extension type for "explicit reverse 
metric value" for all link metric address-TLVs ?

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 15:23:39 +0100

> See RFC 5444, Section 6.4.

Aah, I was demonstrating my lack of knowledge of packetBB.  Having
re-read section 6.4, I think 96 DLEP specific TLVs is plenty!

Hopefully we have convinced the authors?

> is only local traffic (not over radio), so we do not need to look at

Agreed

I still need to propose grouping the metric TLV ids to carry extra
semantic information, much like SCTP chunk type id assignments carry
extra information about the handling of the chunk.  But I'll start a new
thread for that.

Rick Taylor

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 10:42:44 -0400

> layer-2 mesh routing protocol is a recipe for a disaster.)
I feel that any bleeding of the layer 2 radio topology into the router's
layer 3 routing domain is recipe for disaster. The radio network should be
transparent to DLEP routers. The DLEP routers should only be aware of
neighbors that can be reached over this radio network and the metrics for
those neighbors which is used to calculate a route cost to reach those
neighbors.

> metric value" for all link metric address-TLVs ?

I understand that there could be asymmetric links but I question how a
router would use this information. How would a router use a metric for
traffic ingress'ing its interface?

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:00:44 +0200

> those neighbors which is used to calculate a route cost to reach those

I agree with you if the layer-2 mesh is just a "border network" with a
single connection to the layer-3 mesh, but not in the general case.

The layer-2 mesh design cannot know what kind of policies and
restrictions are being used on the layer-3 mesh. There might be
information that should only travel over a subset of the nodes. A
special way to combine the routing metrics of multiple hops into a
single one. Or something different.

The point is that there is no real advantage of hiding the details of
the layer-2 mesh, except for restricting the ways the layer-3 mesh
works. The accumulated data can be calculated from the full topology,
not the other way around.

With access to the layer-2 mesh data, the layer-3 might consider
skipping the problem of layering two mesh protocols on top of each
other and just use the layer-2 mesh as an incredible fast layer-2
neighbor/2-hop-neighbor detection. Or it might just offload all the
work on the layer-2 and only consider accumulated total costs for
transit links. But at least all this choices are available.

> traffic ingress'ing its interface?
OLSRv2 use directional link metrics, so hiding one of them from it
would just make it necessary to relay the directional metric values to
the other side with HELLOs. An example for really using both links
might be a quality of service policy that demands that the traffic
only flows over very symmetric links.

Again, I don't see a reason for hiding this information if it is
available on layer-2.

Henning Rogge

-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 16:04:22 +0100

> > I would like to go back to the original discussion of reporting
multi-
> hop

It does exist and the radio vendors are moving towards increasing smart
meshing radios.  All we can hope to do is add sufficient information to
DLEP to allow us to access the topology information.

> > metrics for neighbors that are one hop away. If the radio net
happens to
> be
> > neighbors that are 2 or more hops away in their layer2 mesh then
that
> should
> > be transparent to the DLEP routers. The radio, with its knowledge of
its
> own
> > layer2 mesh topology, should craft the DLEP neighbor metrics to
account
> for

I agree with Henning on this.  Hiding topology information will only
cause problems, and leave routing users of DLEP constantly wondering if
the metrics they receive are true.

> the following neighbor data (no originator address means "this
radio").
 
This seems to be a clever alternative to my proposed Via TLV or a
hop-count.  Of course, it does increase the calculation cost on the
receiving router, but the chances are that the router is already trying
to map the relationships between neighbours.

> I think this might solve the full mesh usecase.

I think it might, but I'll have to think on it.

> layer-2 mesh routing protocol is a recipe for a disaster.)

I don't think radio vendors will like having this option available.
Anyway, I imagine this should be a radio configuration action, not part
of DLEP.

I agree on your point about a disaster, but if we can get some
indication of the topology then we can attempt to mitigate it.

> > Also I saw where it was mentioned that it would be nice if DLEP
could
> report
> > one-hop neighbors on a radio net. With that said, I don't understand
how
> a
> > router would use an inbound traffic link metric. Help me understand
the
> use

Asymmetric links are a problem, but I think the simplest way to approach
them might be for each neighbour to report its relevant metric for
inbound only - I mean the metric value the neighbour can receive, i.e.
how much data can flow out of the receiving router, "receiver-egress".
I have described this poorly, I'm happy to try my hand at ASCII art if
it will help.

On an asymmetric link, each neighbour should receive a different value
(and any routing protocol that cares can exchange such information in
the routing protocol).  The neighbour ingress metric is the critical
metric for routing (as Darryl pointed out) but I think it is worth
explicitly stating it in the DLEP protocol to dissuade radio vendors
from averaging asymmetric link metrics.

Darryl, a possible use of inbound metrics might be a DLEP server/router
that just reports/displays the topology of the radio net rather than
routing, basically a diagnostic tool. Focusing DLEP purely on enabling
layer-3 routing alone I think reduces its usefulness in currently
unforeseen applications.  That said, I'm not sure, now, that we need to
report inbound metrics.

Rick Taylor

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 11:06:12 -0400

> Hopefully we have convinced the authors?

Not sure you've convinced the authors... ;-)

This is why I said in Paris that at least part of this is semantics -  
what we're currently calling "sub-TLV's" can easily be re-named to  
"message-type specific TLV's".... and if that simple name change  
(notice there's no other packet format changes) makes everyone happy,  
then I'm good to go.... If we're talking about shuffling the packet  
formats around, and I never have been clear on that, then I've still  
got a problem.

Regards,
Stan

> [email-masked]

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 3 Apr 2012 16:22:13 +0100

> From: Stan Ratliff [mailto:[email-masked]]
> 

"Bother!" said Pooh.

> formats around, and I never have been clear on that, then I've still

I think there are 2 issues here concerning packetBB and DLEP.

1) Sub-TLVs
2) Address blocks

As I understand it, the change request for 1, is to move the sub-TLV ids
into the message-private TLV space, a minimal change.

The change request for 2 is more of a "Keeping in the spirit of
packetBB" request.  The proposal is to move the Neighbour* messages from
the Message-TLV block to the per-message Address Block TLVs, indexed by
the layer-2 (MAC) address of the neighbour. This is a compatible change
with 1, but requires more document changes.

The question really is, does change 2 reduce the message size
noticeably, or is the proposal just about making the packets look nicer?

packetBB gurus, please enlighten me?

Rick Taylor

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 11:24:59 -0400

I'll attempt to explain the use case for radio knowledge of IP  
addresses:

 From a Layer 3 perspective, metrics are *useless* unless they are in  
the context of a next-hop (or destination) address - for example it's  
all well and good to say "I've got 54Mbps of bandwidth on that 802.11g  
device hanging off of interface FastEthernet0/1", but if the router  
doesn't know what traffic might be sent out said interface, what good  
does it do you? Yes, I know - the standard response to that is "well,  
we can ARP, or use IPv6 ND to figure out the Layer 3 addresses".  
Problem is, that takes time. Time some of these networks don't have.

Some of my deployments (not all, but some) are in the military space.  
Putting routers and radios on military vehicles is interesting.  
Putting routers and radios on military airplanes is even MORE  
interesting. Sometimes, you don't have 60 seconds for the link to  
stabilize, and discovery protocols to run, and routing protocols to  
converge - you have a relatively short amount of time to recognize the  
asset overhead, determine metrics to it (and possibly through it), and  
push data while you can. So having nice, neat, interesting things like  
a Layer 2 MAC address, AND all of the associated Layer 3 addresses  
right up front (like in a Neighbor Up message) helps that out a bunch.

Regards,
Stan

On Apr 3, 2012, at 8:23 AM, Henning Rogge wrote:

> DLEP that is useful. But at the moment I lack the knowledge about  
> the common usecase for IP-addresses in DLEP. Maybe someone can  
> explain his usecase.
>
> Henning Rogge
>
> --

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 16:28:11 +0100

There are in effect 65536 different TLVs. OK, some are experimental, and some fall in a category I'll get to in a minute. But fundamentally the only thing special about the 256 with type extension zero is that they save an octet when sent.

That said, it makes sense not to treat them completely independently. And using one type for metric, with up to 256 different variants, is exactly what does make sense. Take a look at OLSRv2 for that approach.

And the case I mentioned above? A range of message type specific TLV types. If all else fails, or because that's your preference, use some of those.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: 03 April 2012 14:51
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:30:25 +0200

Maybe we can do both without extending the data format of DLEP too much.

If a radio layer-2 mesh wants to hide its internal structure (or is
configured to do so), it just produce a single "Neighbor update"
message for itself with all to targets in the whole mesh and
accumulated metric values attached to the neighbor MACs. An optional
hopcount TLV at each neighbor gives the layer-3 routing protocol some
idea about being on a mesh, but even that is optional.

If a radio layer-2 mesh can provide the full topology, it will send
out multiple "Neighbor update" messages to push the link state of all
nodes in the mesh, all of them (except the one for its own neighbors)
using the originator address to tell the router which neighbors
linkstate they are sending.

Both systems use the same semantic, the first one would just look like
a pure "one hop" network (if you don't care for the hopcount TLV).

This would make this "full topology dump" a feature, so the
manufacturer of the device can decide what is supported.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 16:31:04 +0100

See OLSRv2 (and the discussion in draft-dearlove-metrics, currently expired, for why) for use of inbound metrics. In short, although the ultimate route uses outbound metrics, inbound metrics are used for MPR selection, because links (other than the first) in routes go from MPR to MPR selector.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darryl Satterwhite
Sent: 03 April 2012 14:53
To: Henning Rogge; Rick Taylor
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Rick and others,

Darryl Satterwhite
Cisco Systems

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 11:32:49 -0400

> with 1, but requires more document changes.

Ah, we've reached the crux of my concern. What I've HEARD (not  
necessarily what's been said) about use of address blocks is basically  
"well, since you can hold an IPv4 address in 128 bits, with  
"appropriate" padding, and you can hold a MAC address in 128 bits,  
with appropriate padding, then we can somehow encode IPv4 addresses  
and MAC addresses into these larger entities, and 'pretend' they are  
IPv6 addresses, for purposes of RFC 5444. That allows DLEP to use RFC  
5444 address blocks." My pain with that is that it is a hack. Pure and  
simple. It's also DLEP specific. I'm opposed to doing anything like  
that. It's also been said that one route to resolve the issue is to  
effectively open up discussions on "RFC 5444 bis", to "fix it right".  
My position is that if there's something that needs to be "fixed",  
then we SHOULD (perhaps, we MUST?) "fix it right"... ;-)

The current fact of the matter is that DLEP needs visibility to  
multiple address types, both at Layer 2 and Layer 3. RFC 5444 doesn't  
provide a clean mechanism to do so. So, we put in a series of OPTIONAL  
TLV's to do it in an efficient manner. If there is sufficient entropy  
in the WG to fix the problem the right way, then OK. If not, we're  
just trying to force-fit a square peg farther down into a round hole,  
and I fail to see the rationale behind doing that.

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 16:35:53 +0100

As discussion in I think autoconf considered, a critical question is whether the L2 forwarding decrements IP packet hop limit (TTL). If it does then unpleasantness results, but if it doesn't then L2 can be hidden.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:35:45 +0200

> I think there are 2 issues here concerning packetBB and DLEP.
Yes.

> noticeably, or is the proposal just about making the packets look nicer?
Yes, it should do so.

First, if you have multiple Neighbors inside your Neighbor-Update
message, you can share the metric TLV headers between them.

You also can compress the MAC addresses down to 3 bytes if they are
from the same block because they are from the same manufacturer.

On Tue, Apr 3, 2012 at 17:24, Stan Ratliff <[email-masked]> wrote:
> I'll attempt to explain the use case for radio knowledge of IP addresses:
>
> From a Layer 3 perspective, metrics are *useless* unless they are in the
> context of a next-hop (or destination) address - for example it's all well
> and good to say "I've got 54Mbps of bandwidth on that 802.11g device hanging
> off of interface FastEthernet0/1", but if the router doesn't know what
> traffic might be sent out said interface, what good does it do you? Yes, I
> know - the standard response to that is "well, we can ARP, or use IPv6 ND to
> figure out the Layer 3 addresses". Problem is, that takes time. Time some of
> these networks don't have.
Most Layer-3 routing protocols use Linklayer multicasts to communicate
with each other. So they just have to look into the mac addresses of
the received protocol messages to detect the MAC. No network traffic
necessary at all.

We have a plugin in our OLSR.org implementation that use this strategy
to fill the ARP cache even before you get traffic, which makes the
whole ARP unnecessary.

> Putting routers and radios on military vehicles is interesting. Putting
> routers and radios on military airplanes is even MORE interesting.
> Sometimes, you don't have 60 seconds for the link to stabilize, and
> discovery protocols to run, and routing protocols to converge - you have a
> relatively short amount of time to recognize the asset overhead, determine
> metrics to it (and possibly through it), and push data while you can. So
> having nice, neat, interesting things like a Layer 2 MAC address, AND all of
> the associated Layer 3 addresses right up front (like in a Neighbor Up
> message) helps that out a bunch.
Using the Layer-2 as the (2-hop?) neighbor detection for a layer-3
routing protocol might be an interesting choice. Most TDMA-MACs have
to learn their two-hop neighbors anyway.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 11:38:05 -0400

> to fill the ARP cache even before you get traffic, which makes the

Cool. In that case, you could actually use the DLEP information to  
fill the ARP cache in... ;-)  Yet another use case for radios that  
OPTIONALLY know about the Layer 3 addresses.

Regards,
Stan

>> Putting

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:42:31 +0200

On Tue, Apr 3, 2012 at 17:32, Stan Ratliff <[email-masked]> wrote:
> Ah, we've reached the crux of my concern. What I've HEARD (not necessarily
> what's been said) about use of address blocks is basically "well, since you
> can hold an IPv4 address in 128 bits, with "appropriate" padding, and you
> can hold a MAC address in 128 bits, with appropriate padding, then we can
> somehow encode IPv4 addresses and MAC addresses into these larger entities,
> and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That allows
> DLEP to use RFC 5444 address blocks." My pain with that is that it is a
> hack. Pure and simple. It's also DLEP specific. I'm opposed to doing
> anything like that. It's also been said that one route to resolve the issue
> is to effectively open up discussions on "RFC 5444 bis", to "fix it right".
> My position is that if there's something that needs to be "fixed", then we
> SHOULD (perhaps, we MUST?) "fix it right"... ;-)

> The current fact of the matter is that DLEP needs visibility to multiple
> address types, both at Layer 2 and Layer 3. RFC 5444 doesn't provide a clean
> mechanism to do so. So, we put in a series of OPTIONAL TLV's to do it in an
> efficient manner. If there is sufficient entropy in the WG to fix the
> problem the right way, then OK. If not, we're just trying to force-fit a
> square peg farther down into a round hole, and I fail to see the rationale
> behind doing that.

Most MAC-Layers do not even know about Layer-3 addresses, so they are
a special case. The typical DLEP messages might only contain MAC
addresses. Think about DLEP for IEEE 802.11 for example.

I think use a special TLV for a special MAC-Layer is okay.

> Cool. In that case, you could actually use the DLEP information to fill the ARP cache in...
> Yet another use case for radios that OPTIONALLY know about the Layer 3 addresses.

Thats why I think the "IPv4 Interface address" and "IPv6 Interface
address" TLV is a necessary addition for this radios.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:45:52 +0200

Forgot something in my last post...

> SHOULD (perhaps, we MUST?) "fix it right"... ;-)

The concept I (developed and) discussed in the discussion with Rick
was to use 6 byte addresses in DLEP so you can put in MACs in a clean
way. If you have IPs available, add them with two special address
TLVs.

DLEP is about the layer-2, so its not unreasonable to give the MAC
addresses a special place. And it would also sidestep the problem with
padding.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 16:50:30 +0100

I really need to read DLEP properly. But I just quickly skimmed trying to look at sub-TLVs. And I don't see that term used. I do see a lot of normal looking TLVs in a TLV block. But what I need to look more carefully at is addresses and their handling.

What isn't correct, at least for normal use of 5444,  is packets. As defined in 5444/5498, DLEP doesn't get to define a packet, it  just defines one or more messages. Packets are owned by 5444 and allowed to include messages of different types, from different protocols, piggybacked together.

The more precious resource is messages. There are only 256 (minus private/experimental) of these, and DLEP appears to be rather profligate with these, claiming 17. NHDP and OLSRv2 manage with one apiece. I don't believe 17 can be justified, and that (agreed, at a cost of a small number of extra bytes) this could, and should, be reduced a lot.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 03 April 2012 16:06
To: Rick Taylor
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 11:52:10 -0400

Henning,

I'm beginning to get lost with what you are proposing as an alternative to
the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us
non-RFC5444 experts, can you clarify?

Darryl Satterwhite
Cisco Systems

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 16:53:45 +0100

As I've said, what we need is a good example, one showing the features. This should be of the form indicating what advertising, and what information (addresses, metrics etc.) for those. In particular this needs to be a complicated case (though a simpler, typical, case as well wouldn't hurt), so if there may be multiple address types in one message, the example needs to include that, etc. (Possibly more than one example is needed, I don't know.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: 03 April 2012 16:22
To: Stan Ratliff
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

"Bother!" said Pooh.

1) Sub-TLVs
2) Address blocks

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 17:57:15 +0200

> non-RFC5444 experts, can you clarify?
I talked with Rick Taylor today quite a lot to understand the need of
IPv4/IPv6 and I think we got to a better solution than my earlier
proposal.

The new idea is to set the address length field in the message header
to 6, so we can put neighbor MAC addresses into the message in a
proper way. We then can add metrics as TLVs to this addresses. We can
also compress the MAC addresses as described in RFC 5444.

If the Mac-Layer had additional knowledge about IPv4 and IPv6 address
of the interface of the other side, we put this in a special address
TLV attached to the MAC address. This way we don't waste space with
padding.

This "add IP as TLV to a MAC address" is special for DLEP, but so is
layer-3 knowledge in layer-2 radios.

Henning Rogge

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 11:59:46 -0400

On 4/3/12 11:50 AM, "Dearlove, Christopher (UK)"
<[email-masked]> wrote:

> I really need to read DLEP properly. But I just quickly skimmed trying to look
> at sub-TLVs. And I don't see that term used. I do see a lot of normal looking
> TLVs in a TLV block. But what I need to look more carefully at is addresses
> and their handling.
> 
> What isn't correct, at least for normal use of 5444,  is packets. As defined
> in 5444/5498, DLEP doesn't get to define a packet, it  just defines one or
> more messages. Packets are owned by 5444 and allowed to include messages of
> different types, from different protocols, piggybacked together.
> 
> The more precious resource is messages. There are only 256 (minus
> private/experimental) of these, and DLEP appears to be rather profligate with
> these, claiming 17. NHDP and OLSRv2 manage with one apiece. I don't believe 17
> can be justified, and that (agreed, at a cost of a small number of extra
> bytes) this could, and should, be reduced a lot.

I don't believe this to be the case. We, I thought, were only using 1 to
specify the it's a DLEP message and all other type definitions are done
within the context of a DLEP message. This was something that we did as part
of recommendations that were made when we submitted DLEP version 1.

Darryl Satterwhite
Cisco Systems

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 12:00:49 -0400

I think MAC address compression is a red herring. You can't assume a  
single vendor, so I doubt whether that will be usefull. Also, remember  
that DLEP traffic (99% of it, anyway) only occurs on the link between  
the router and its "local" radio.

Regards,
Stan

On Apr 3, 2012, at 11:57 AM, Henning Rogge w

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 12:01:54 -0400

Yeah, I'll add my voice to that as well. We tried to get DLEP to the  
point where it only uses 1 RFC 5444 message TLV. If that's not the  
case, then I need to understand.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 18:04:24 +0200

On Tue, Apr 3, 2012 at 18:01, Stan Ratliff <[email-masked]> wrote:
> Yeah, I'll add my voice to that as well. We tried to get DLEP to the point
> where it only uses 1 RFC 5444 message TLV. If that's not the case, then I
> need to understand.
>
> Regards,
> Stan

We can still do this, we just need a TLV to carry the "order" of the
DLEP message.

I see the most advantage of using "only" RFC 5444 encoding that you
can use a common parser/generator for DLEP. At the moment DLEP is not
using RFC 5444... its just a wrapper around a partly proprietary
encoding.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 17:04:48 +0100

I don't know what Henning is proposing. I know I'm not proposing anything. I didn't raise the "let's make it more 5444 natural" point, though I have definite sympathies with it. But I also see the multiple address types problem. Personally, I couldn't make a good suggestion (whether to change to X, or leaves things as they are) without specific examples to think about, and ones derived by someone else from DLEP.

For example (not DLEP, rather the sort of thing that might be said).

I want to advertise a number, let's say 3 for example, of entities. The first has a MAC address and an IPv4 address, the second has a MAC address and an IPv6 address (derived from the MAC address) and the third has a MAC address and an IP address (not derived from the MAC address). All have metric types A, B and C, the first two also have metrics of type D, the last two also have metrics of type E.

Then one could think about it (and that example is, deliberately, nasty - the question is whether real DLEP messages are that nasty).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darryl Satterwhite
Sent: 03 April 2012 16:52
To: Henning Rogge; Stan Ratliff
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Henning,

Darryl Satterwhite
Cisco Systems

---

From: "Powell lll, Nelson" <[email-masked]>
Date: Tue, 3 Apr 2012 16:10:57 +0000

I apologize for not keeping up with all of the discussions, but to provide a "future" use case in concurrence with what Stan has said, I took a stab at some ASCII art.  

                                      Radio               
                          +------------------------------+           
                          |                              |           
   +--------+             |  +--------+     +---------+  |           
   |        |             |  |  host  |     |         |  |           
   | router |-------------|--|   or   |-----|  modem  |--|<-- RF -- >
   |        |   (PPP)     |  |  rtr?  |     |         |  |           
   +--------+ (Ethernet)  |  +--------+     +---------+  |           
                (USB)     |                              |           
                          +------------------------------+           

In other postings, I saw mention of 802 based waveforms as the use case; but moving into military, public safety, and other private radio use cases, more advanced devices may incorporate a host or routing capabilities within the radio that allows for waveform specific optimizations.

I do not want to relegate the use of 802 based waveforms. I would like, however, to ensure the compatibility of forward looking waveforms that provide event driven metrics in association with end point routing information.  If a Layer-2 MESH can provide the end-point information initially and merely update metrics as event occur, this will greatly reduce the overhead of a layer 3 routing protocol traversing the wireless space, and thus returning throughput to the user.

Nelson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: Tuesday, April 03, 2012 11:25 AM
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 12:11:52 -0400

My point is that DLEP ALREADY does that - it ALREADY uses just 1 TLV  
code point from the 5444 perspective. At least I believe it does.  
Please show me where I'm wrong.  And as far as the encoding, OK - I  
think the benefit is minimal. But if the encoding requires us to  
"pretend" that addresses aren't in different families when they really  
are, then it's time for RFC 5444 bis.

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 17:14:13 +0100

Address compression (head and tails) was certainly designed for common IPv4 and IPv6 scenarios. Any gain with MAC addresses would be, as Stan indicates, fortuitous.

But going back to Henning's model of all have MAC addresses, some have IPv4/6 addresses, is this correct? Do all entities have a MAC address? Do we get both IPv4 and IPv6 addresses together? How many addresses is typical/maximal? (there's a lot of difference designing for one, occasionally two, than for normal average is half a dozen or more).

But if it's MAC address always etc. then Henning's proposal makes some sense in that it allows parsing to associate information with entities, entities defined by MAC address, less painful than some alternatives. It gets no address compression. If all entities had an IP address then using that as the address block and MAC addresses as a TLV would work more cleanly (especially if there are subnet lengths). If there were lots of entities then there are ideas that could save space, but (not having counted bytes) I suspect the saving is too small for the complexity. (And I also don't see a 5444bis - something that would be painful for other reasons - helping either in the case of small numbers of addresses, some with IP addresses, some without.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 03 April 2012 17:01
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 17:16:01 +0100

I said I'd skimmed, I appear to have skimmed too lightly in this case. Apologies.

-----Original Message-----
From: Darryl Satterwhite [mailto:[email-masked]] 
Sent: 03 April 2012 17:00
To: Dearlove, Christopher (UK); Stan Ratliff; Rick Taylor
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Darryl Satterwhite
Cisco Systems

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Apr 2012 17:17:54 +0100

That's also suggesting a mis-skimming by me. But as I've said, what I'd rather do is start from "this is what we are trying to communicate" and design from there.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 03 April 2012 17:12
To: Henning Rogge
Cc: Darryl Satterwhite; Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 12:23:05 -0400

The problem with that approach is what I mentioned earlier - Neighbors  
have an associated MAC, but the DLEP "Peers" (e.g. the radio itself)  
doesn't, and therefore, doesn't fit the model.

Regards,
Stan

On Apr 3, 2012, at 12:14 PM, Dearlove, Christopher (UK) wrote:

> Address compression (head and tails) was certainly designed for  
> common IPv4 and IPv6 scenarios. Any gain with MAC addresses would  
> be, as Stan indicates, fortuitous.
>
> But going back to Henning's model of all have MAC addresses, some  
> have IPv4/6 addresses, is this correct? Do all entities have a MAC  
> address? Do we get both IPv4 and IPv6 addresses together? How many  
> addresses is typical/maximal? (there's a lot of difference designing  
> for one, occasionally two, than for normal average is half a dozen  
> or more).
>
> But if it's MAC address always etc. then Henning's proposal makes  
> some sense in that it allows parsing to associate information with  
> entities, entities defined by MAC address, less painful than some  
> alternatives. It gets no address compression. If all entities had an  
> IP address then using that as the address block and MAC addresses as  
> a TLV would work more cleanly (especially if there are subnet  
> lengths). If there were lots of entities then there are ideas that  
> could save space, but (not having counted bytes) I suspect the  
> saving is too small for the complexity. (And I also don't see a  
> 5444bis - something that would be painful for other reasons -  
> helping either in the case of small numbers of addresses, some with  
> IP addresses, some without.)
>
> -- 
> Christopher Dearlove

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 18:25:52 +0200

On Tue, Apr 3, 2012 at 18:23, Stan Ratliff <[email-masked]> wrote:
> The problem with that approach is what I mentioned earlier - Neighbors have
> an associated MAC, but the DLEP "Peers" (e.g. the radio itself) doesn't, and
> therefore, doesn't fit the model.
>
> Regards,
> Stan

Why does the radio itself has no MAC? I am certain it has a MAC, it
might even make sense to use this MAC as the "server-id".

Henning Rogge

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 3 Apr 2012 12:05:35 -0500

> I have described this poorly, I'm happy to try my hand at ASCII art if

Very nice if you every need to do ASCII art.

http://www.jave.de/

Of course, other drawing packages and post URL to some web site works too.

- Will

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 13:30:32 -0400

A DLEP neighbor always has a MAC address in the DLEP messages that
correspond to "neighbor up", "neighbor down", and "neighbor metric"
exchanges to uniquely identify the neighbor that the radio has discovered.
IPv4 and Ipv6 addresses are optional in the "neighbor up" exchange to speed
layer 3 address discovery for the layer 3 routing protocols when radios have
that knowledge. Without these optional layer 3 address TLV, address
discovery occurs using the normal ARP and ND mechanisms.

So a neighbor up event will have a MAC address and one or all of the
following:
1) IPv4 address
2) IPv6 Link Local
3) 1 or more IPv6 Global addresses

Darryl Satterwhite
Cisco Systems

On 4/3/12 12:14 PM, "Dearlove, Christopher (UK)"
<[email-masked]> wrote:

> Address compression (head and tails) was certainly designed for common IPv4
> and IPv6 scenarios. Any gain with MAC addresses would be, as Stan indicates,
> fortuitous.
> 
> But going back to Henning's model of all have MAC addresses, some have IPv4/6
> addresses, is this correct? Do all entities have a MAC address? Do we get both
> IPv4 and IPv6 addresses together? How many addresses is typical/maximal?
> (there's a lot of difference designing for one, occasionally two, than for
> normal average is half a dozen or more).
> 
> But if it's MAC address always etc. then Henning's proposal makes some sense
> in that it allows parsing to associate information with entities, entities
> defined by MAC address, less painful than some alternatives. It gets no
> address compression. If all entities had an IP address then using that as the
> address block and MAC addresses as a TLV would work more cleanly (especially
> if there are subnet lengths). If there were lots of entities then there are
> ideas that could save space, but (not having counted bytes) I suspect the
> saving is too small for the complexity. (And I also don't see a 5444bis -
> something that would be painful for other reasons - helping either in the case
> of small numbers of addresses, some with IP addresses, some without.)

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 19:48:10 +0200

> 3) 1 or more IPv6 Global addresses

Does a Neighbor Up event needs to contain any IP address? I assume the
"just the mac" would be a valid option, right?

Henning Rogge

---

From: Darryl Satterwhite <[email-masked]>
Date: Tue, 03 Apr 2012 13:57:16 -0400

> "just the mac" would be a valid option, right?
Yes that is correct, and in most cases layer 3 addresses will NOT be
present.

But to reiterate what Stan mentioned earlier, there is also a peer session
between the radio and router which exchanges global information and
maintains heartbeats for local client(radio) to server(router) sanity.
Current implementations use Ethernet so adding a MAC address to peer
messages is unnecessary.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 20:26:05 +0200

> Yes that is correct, and in most cases layer 3 addresses will NOT be
Just wanted to be sure, thanks.

> Current implementations use Ethernet so adding a MAC address to peer

Not necessarily. The communication from the radio might get the MAC of
the ethernet device, not the one of the radio interface. But if the
transport protocol guarantees the right MAC, it will be unnecessary to
add the MAC to the DLEP message.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 14:55:14 -0400

I'm not necessarily OK with the notion that a Neighbor Up will  
"normally" be just a MAC. With the radio implementation we have right  
now, that's the case. But I would hope as DLEP matures, and more  
implementations come online, then there should be more of a use for  
Layer 3 addressing on the Neighbor Up.

Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we  
worked to get DLEP running over RFC 5444 was for transport  
independence. So now we're going to *assume* a Layer 2 MAC address?  
What if the implementation is a radio card in a chassis - I can see  
using a 5444 packet transfer, but doing that over some Bus-passing  
scheme. I don't want to create "phantom" MAC addresses for that...

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 21:14:07 +0200

On Tue, Apr 3, 2012 at 20:55, Stan Ratliff <[email-masked]> wrote:
> I'm not necessarily OK with the notion that a Neighbor Up will "normally" be
> just a MAC. With the radio implementation we have right now, that's the
> case. But I would hope as DLEP matures, and more implementations come
> online, then there should be more of a use for Layer 3 addressing on the
> Neighbor Up.
If the DLEP-equipped radio just bridges its interface to the datapath
towards the users OS, it doesn't need to have an IP. The user of the
radio can set the IP on his side of the connection.

> worked to get DLEP running over RFC 5444 was for transport independence. So
> now we're going to *assume* a Layer 2 MAC address? What if the
> implementation is a radio card in a chassis - I can see using a 5444 packet
> transfer, but doing that over some Bus-passing scheme. I don't want to
> create "phantom" MAC addresses for that...

As long as the radio interface has a MAC it use to set up the data
path with the user I am fine. The control plane between the DLEP
connection of radio and router does not necessarily need a MAC.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 Apr 2012 15:26:21 -0400

One of us has this backwards.... and at this point, it's probably  
me. ;-)

On Apr 3, 2012, at 3:14 PM, Henning Rogge wrote:

>> "normally" be

What? The IP addresses I'm referring to are the ones on the *far end*  
of the connection - the addresses of the neighbor. Bridging to the  
datapath doesn't matter.

>> independence. So

Again... What? In the environment I'm envisioning, the far-end devices  
have a MAC. The radios themselves wouldn't.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 3 Apr 2012 22:01:06 +0200

Op 3 apr. 2012, om 21:26 heeft Stan Ratliff het volgende geschreven:

> One of us has this backwards.... and at this point, it's probably me. ;-)
> 
> What? The IP addresses I'm referring to are the ones on the *far end* of the connection - the addresses of the neighbor. Bridging to the datapath doesn't matter.
> 
> 
> Again... What? In the environment I'm envisioning, the far-end devices have a MAC. The radios themselves wouldn't.

Interesting. How works L2 next hop resolving? IP packets have SA and DA, not a next_hop_IP. L2-headers would have the router MAC addresses. Modems could spoof router MAC address, or use its own addresses for TA and RA (transmitter/receiver addresses, like 802.11 WDS). I don't like spoofed addresses, it brings limitations.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Apr 2012 22:04:25 +0200

> One of us has this backwards.... and at this point, it's probably me. ;-)
maybe just too much work by me with thinking about the radios as a
linux device itself.

> What? The IP addresses I'm referring to are the ones on the *far end* of the
> connection - the addresses of the neighbor. Bridging to the datapath doesn't
> matter.

I think it does matter.

If the IP is set on a device outside the DLEP-client equipped radio,
DLEP should neither know nor care about the IP in the default case.
Unless the IP is configured/sent into the radio too for delivering it
with some special MAC-layer.

> a MAC. The radios themselves wouldn't.

That depends on the design of the radio. If it contains a full
operation system (with a radio driver and an ethernet driver), its
might have one MAC address for each of them, just to make it easier to
handle them internally. And if the DLEP-client is connected to the
DLEP-server via UDP, the radios ethernet will most likely need a MAC
for its ethernet too.

For the DLEP message content, only the MAC used to transmit data over
the radio is important, be it on the far-end device or on the radio.

This is a sketch how I would see one possible DLEP-capable radio
device based on a normal OS:

      +-----------------------------------------+
 \    |                                         |
  \   |             +--------+        VLAN1     |
 --+----------------+ bridge +----------------+ |
  /   | radio-if    +--------+      ethernet  | |
 /    |                                       | |
      |                                       +----------
      |                                       | |
      |         +-------------+       VLAN2   | |
      |         | DLEP-Client +---------------+ |
      |         +-------------+     ethernet    |
      |                                         |
      +-----------------------------------------+

The VLAN1-ethernet interface has no IP address, its only used to
connect on layer-2 directly to the radio interface.
The VLAN2-ethernet interface will have an IP address to allow
communication between the DLEP-Client (and maybe other radio services)
with the outside (could be an IPv6 linklocal based on the ethernets
MAC).

In this example the other end of the VLAN1-ethernet (in the router
device) should have the same MAC as the radio-if, the "bridge" is a
kernel module that just copies packets between two interfaces without
caring about their MAC. We tested this bridging last week on linux
with a standard WIFI-card.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 3 Apr 2012 22:29:50 +0200

> device based on a normal OS:

As I understand, this is cloning.
Can be used if only one "other" device is on VLAN1.
The bridge function is in fact a repeater: no address learning and
no filtering.

FYI, cloning-mode or 4-addr-mode should be transparent for the DLEP 
protocol. The neighbors are the far-end router MAC addresses. It 
is up to the near DLEP modem to get metrics for each L3 peer behind
the far-end DLEP modem. With 4-addr-mode, multiple routers behind
a far-end would have same metrics.

We might need to support privacy addresses, also at L2. How to 
support this with DLEP is an open question, I think.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 10:11:50 +0100

It's going to be impossible to make a sensible suggestion as to how DLEP messages should be formatted until all these sorts of questions are answered.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 03 April 2012 19:55
To: Henning Rogge
Cc: Darryl Satterwhite; Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 4 Apr 2012 13:43:53 +0100

I think what might be getting lost in all this discussion about packet formatting is that all DLEP communication happens between a modem and a directly connected router.  That's a direct wire link, probably Ethernet. So the whole discussion of compression of packet size is irrelevant in the grand scheme of things. No DLEP packets are going over the air or across lossy or multi-hop links.

The *only* reason for using packetBB for DLEP is that DLEP is a MANET RFC, and all MANET RFC's must use packetBB.

Discussions about how to fit DLEP messages into packetBB packets is purely about 'correctness', any discussion about performance is largely pointless.

DLEP would operate perfectly well as an XML SOAP service over HTTP.  In fact, I haven't thought of a good reason why DLEP doesn't use a TCP connection between router and modem and dispense with heartbeats and sequence numbers altogether.

To answer a previous question, all Neighbour* messages in DLEP refer to that neighbours MAC address + extra information.  My reading of RFC5444 is that an Address-Block address may be of arbitrary length (i.e. 6 octets for MAC) avoiding any need to cludge a MAC into an IP address, but I stand by my first point that this is all just about the 'prettiness' of the fit of DLEP semantics to the packetBB format.

Can we split the DLEP discussions into 2 threads: 1) What is the information that needs to be communicated between router and modem.  2) How this information is encapsulated in packetBB/RFC5444?

Rick Taylor

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dearlove, Christopher (UK)
> Sent: 04 April 2012 10:12
> To: Stan Ratliff; Henning Rogge
> Cc: [email-masked]
> It's going to be impossible to make a sensible suggestion as to how DLEP
> messages should be formatted until all these sorts of questions are
> answered.
> 
> --
> Christopher Dearlove

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 13:46:11 +0100

I agree the 1/2 split makes sense, but you really need to answer 1 before answering 2.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 04 April 2012 13:44
To: Dearlove, Christopher (UK); Stan Ratliff; Henning Rogge
Cc: [email-masked]
Subject: RE: [manet] DLEP and multi-hop neighbours

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 04 Apr 2012 14:51:08 +0200

On 04/04/2012 02:43 PM, Rick Taylor wrote:
> Can we split the DLEP discussions into 2 threads: 1) What is the
> information that needs to be communicated between router and modem.
> 2) How this information is encapsulated in packetBB/RFC5444?

I think that sounds like a reasonable approach to resolve this thread, 
lets start with point 1).

If we have a consensus about WHAT information we need in DLEP to fulfill 
the use-cases, we can move to 2).

Henning Rogge

---

From: Darryl Satterwhite <[email-masked]>
Date: Wed, 04 Apr 2012 09:54:12 -0400

If we are targeting "1)", then all that I remember hearing are:

1) A dimensionless Metric (We currently have RLQ which is dimensionless)
2) A way to report metrics in both directions for asymmetric links.

Were there others?

Darryl Satterwhite
Cisco Systems

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 15:07:51 +0100

How are entities about which information (metrics etc.) identified? What kinds of addresses do they always/sometimes have?

This is fundamental to how to include information in a 5444 message, the basic design of which is that a message contains two sorts of information: (a) information specific to the message, (b) information specific to an entity identified by an address. There may be ways to use 5444 more creatively than that, but that was the original design logic.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darryl Satterwhite
Sent: 04 April 2012 14:54
To: Henning Rogge; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Were there others?

Darryl Satterwhite
Cisco Systems

---

From: Henning Rogge <[email-masked]>
Date: Wed, 04 Apr 2012 16:08:57 +0200

> 2) A way to report metrics in both directions for asymmetric links.

I would add a few things:
- the MAC address of every neighbor for identification of links
- IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol of 
the radio
- an identification string for radio and router
- timing information how often radio and router announce their presence 
in the DLEP session
- the MAC address of the radio/connected interface for identification of 
the DLEP-Client (instead of the current 32bit server id)?
- a way to report metric data of links not directly connected to the 
local radio (if known to the radio)?

We most likely could add quite a few more metric related data like:
- current transmission speed of broadcasts
- link throughput
- signal strength
- signal/noise ratio
- frequency
- packet loss and other link specific layer-2 statistics easily gathered 
by the link layer.

I would also consider splitting our list into the "passive" and "active" 
part of DLEP. The passive DLEP part is just about querying data, the 
active one is about controlling the interface (Link Characteristic 
Request) and traffic shaping (Credit messages).

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Apr 2012 16:28:20 +0200

I remember the static micro-wave serial link and satcom bended bit-pipe 
use cases, where the p2p link (also uni-directional receiver in the satcom 
use case) had a TX and RX clock. It was hard to get this info into the
router / routing protocol. The modems had ethernet management ports, but
there wasn't a standard protocol implemented (or so to say, routers do
not poll MIBs).

This problem still exists. DLEP could be used, but it has some new
requirements: no sub-IP protocol, the modems are only aware of link
speed and signal strength & quality @ local node. There could be EOW,
but I am not aware this is used for DLEP-related info exchange.

This is still used in static ad hoc networks (SANET?). 

Teco

Op 4 apr. 2012, om 16:08 heeft Henning Rogge het volgende geschreven:

> - IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol of the radio
> - timing information how often radio and router announce their presence in the DLEP session
> - the MAC address of the radio/connected interface for identification of the DLEP-Client (instead of the current 32bit server id)?
> - a way to report metric data of links not directly connected to the local radio (if known to the radio)?
> 
> - packet loss and other link specific layer-2 statistics easily gathered by the link layer.
> 
> I would also consider splitting our list into the "passive" and "active" part of DLEP. The passive DLEP part is just about querying data, the active one is about controlling the interface (Link Characteristic Request) and traffic shaping (Credit messages).
> 
> Henning Rogge
> --

---

From: Dr John P Mullen <[email-masked]>
Date: Wed, 4 Apr 2012 08:30:00 -0600

Hi,

Concerning:
------------------------
We most likely could add quite a few more metric related data like:
- current transmission speed of broadcasts
- link throughput
- signal strength
- signal/noise ratio
- frequency
- packet loss and other link specific layer-2 statistics easily gathered by the link layer.
------------------
I think it is good to keep in mind that almost all of these characteristics are random variables. If we try to circulate too many details, we may end up circulating more sampling error than information. This would be especially true of a situation in which the nodes are moving fairly rapidly, relative to transmission range. Also, it is possible that different estimates of these parameters will arrive via different routes, leaving the receiving node with the problem of justifying the conflicts. Additionally, as the number of hops increases, the latency also increases, making information less current/reliable.

In this case, I think less is more. It would seem better to provide a single metric, say p(reception), about nearby nodes with further detail possibly available through a specific query about a specific node. This would reduce the load on the channel and simplify the process of dealing with information.

John Mullen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Wednesday, April 04, 2012 8:09 AM
To: Darryl Satterwhite
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

I would also consider splitting our list into the "passive" and "active" 
part of DLEP. The passive DLEP part is just about querying data, the active one is about controlling the interface (Link Characteristic
Request) and traffic shaping (Credit messages).

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: Wed, 4 Apr 2012 10:33:01 -0400

Wow. Just. Wow.

I'm trying to figure out how we got this far off into the weeds -  
specifically, how we're on the 02 version of a working group draft  
(with the individual submission versions before that), and all of a  
sudden there's supposedly no consensus about "WHAT information we need  
in DLEP to fulfill the use-cases"?????  Seriously? Did no one read the  
other versions of the draft?

To be honest, I really don't know how to respond to where this tread  
has wound up. It almost looks like the participants in the thread have  
suddenly come to the conclusion of "Hey, maybe we need a way for a  
radio to transfer "some" data to a locally attached router! Brilliant!  
I wonder what data we need?" The current DLEP draft is an attempt to  
articulate JUST THAT - what data is needed. It is based on the  
experiences of the co-authors in deploying these networks. So, draft- 
ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT  
is needed. It also represents the notions of the co-authors as to HOW  
the data should be transmitted. The packets fit into RFC 5444 format,  
as required by the MANET working group. Past that, this discussion is  
devolving into something that simply isn't useful, IMO. To camp out on  
this and spin several iterations doesn't do anyone any good -  
especially those that are trying to actually put products into the  
field to help customers.

Regards,
Stan

On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote:

> I think that sounds like a reasonable approach to resolve this  
> thread, lets start with point 1).
>
> If we have a consensus about WHAT information we need in DLEP to  
> fulfill the use-cases, we can move to 2).
>
> Henning Rogge
> --

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 Apr 2012 10:37:35 -0400

Adding specific metric types like this is a fairly straightforward  
exercise, provided there is consensus in the working group to do so.  
That is, in the current packet format...

Having said that, the current draft also allows for a number space of  
"experimental TLV's". Those could be used to initially transport  
values such as this for experimentation, with a subsequent revision of  
the DLEP draft to incorporate them if they are seen as universally  
beneficial.

So, I'll leave it to the WG to determine consensus on adding the items  
below.

Regards,
Stan

On Apr 4, 2012, at 10:30 AM, Dr John P Mullen wrote:

> I think it is good to keep in mind that almost all of these  
> characteristics are random variables. If we try to circulate too  
> many details, we may end up circulating more sampling error than  
> information. This would be especially true of a situation in which  
> the nodes are moving fairly rapidly, relative to transmission range.  
> Also, it is possible that different estimates of these parameters  
> will arrive via different routes, leaving the receiving node with  
> the problem of justifying the conflicts. Additionally, as the number  
> of hops increases, the latency also increases, making information  
> less current/reliable.
>
> In this case, I think less is more. It would seem better to provide  
> a single metric, say p(reception), about nearby nodes with further  
> detail possibly available through a specific query about a specific  
> node. This would reduce the load on the channel and simplify the  
> process of dealing with information.
>
> John Mullen
>
>
>
> - the MAC address of the radio/connected interface for  
> identification of the DLEP-Client (instead of the current 32bit  
> server id)?
> Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg,  
> Germany

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 15:54:57 +0100

I've been trying to consider the issue of 5444 fit, having an interest as an author of 5444. And despite several requests, I haven't seen a clear statement and good example(s) of what that information is. And having to dig through the draft is not the answer to that. I'm actually not worried (in this context) about the details of how many link metric types there are, for example, what matters is that there may be several pieces of information and whether in a given message each reported entity may have different subsets of associated data, or all will have the same? But how those entities are identified - by what sort of addresses and whether any are always present etc. - is critical. And if there is information not associated with addressed entities, is that one-of or multiple, and if the latter how they identified? These are the critical questions with regard to formatting, and they aren't being clearly and simply answered.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 04 April 2012 15:33
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Wow. Just. Wow.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Apr 2012 17:04:06 +0200

Also important: having running code.

> Wow. Just. Wow.
At least you have attention :-)

> 
> I'm trying to figure out how we got this far off into the weeds - specifically, how we're on the 02 version of a working group draft (with the individual submission versions before that), and all of a sudden there's supposedly no consensus about "WHAT information we need in DLEP to fulfill the use-cases"?????  Seriously? Did no one read the other versions of the draft?
Some did.

> 
> To be honest, I really don't know how to respond to where this tread has wound up. It almost looks like the participants in the thread have suddenly come to the conclusion of "Hey, maybe we need a way for a radio to transfer "some" data to a locally attached router! Brilliant! I wonder what data we need?" The current DLEP draft is an attempt to articulate JUST THAT - what data is needed.
Needed for the protocols you work with. Good starting point, no one suggested to throw away something. I could easily miss a posting.

But I have some opinions on parts of the protocol. We (IETF) have already STD TRACK protocols for for example L2 address resolving. And I dislike the flow control part being part of the STD TRACK DLEP protocol. Just me and a couple of others.

> It is based on the experiences of the co-authors in deploying these networks. So, draft-ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT is needed.
Thanks for sharing your experiences. Thanks publishing. Now *we* (MANET GW) come into the difficult part going forward with it.

> It also represents the notions of the co-authors as to HOW the data should be transmitted. The packets fit into RFC 5444 format, as required by the MANET working group.
I am not so sure on this "required". If it makes sense, yes. If not, select a better transport protocol for the data.

There were some postings on DLEP messages and packets. DLEP messages cannot be carried in packets for MANET routing protocols. The source & destinations are different.

> Past that, this discussion is devolving into something that simply isn't useful, IMO. To camp out on this and spin several iterations doesn't do anyone any good - especially those that are trying to actually put products into the field to help customers.
Accepted. Although active members on this thread may have these goals. I have. I do put products into the field.

Back to what this thread is about. Subject is "DLEP and multi-hop neighbours". This is a somewhat inaccurate subscription. For the router, neighbors are neighbors and they are 1-hop away. 2-hop neighbors are neighbor neighbors, so not real neighbors. DLEP is about link metrics to (L3) neighbors.

I think I came up with a requirement for a metric, from sub-IP-layer, directly to be used by L3 routing. Then sub-IP and IP routing has exactly the same info for the topology. Makes live more easy for those that deploy such.

Teco.

>> I think that sounds like a reasonable approach to resolve this thread, lets start with point 1).
>> 
>> If we have a consensus about WHAT information we need in DLEP to fulfill the use-cases, we can move to 2).
>> 
>> Henning Rogge
>> --

---

From: David Young <[email-masked]>
Date: Wed, 4 Apr 2012 09:57:58 -0500

On Wed, Apr 04, 2012 at 08:30:00AM -0600, Dr John P Mullen wrote:
> information. This would be especially true of a situation in which the
> nodes are moving fairly rapidly, relative to transmission range. Also,
> it is possible that different estimates of these parameters will
> arrive via different routes, leaving the receiving node with the
> problem of justifying the conflicts. Additionally, as the number of
> hops increases, the latency also increases, making information less
> current/reliable.

Apropos the latency problem, more important than plumping the set of
metrics may be adding a timestamp telling the time when the metrics were
recorded, the units (ms, us, ns) of time, the time source & origin (GPS
& GMT), and the time itself.  In this way a router can discard data that
is old or superseded by data.

Dave

-- 
David Young
[email-masked]    Urbana, IL    (217) 721-9981

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Apr 2012 17:18:38 +0200

> I've been trying to consider the issue of 5444 fit, having an interest as an author of 5444. And despite several requests, I haven't seen a clear statement and good example(s) of what that informat…

Let me try to describe what I see in DLEP in a more general way.

DLEP (mostly) is about transporting data from a layer-2 device to a
layer-3 agent (for example radio to routing agent).

DLEP should allow the layer-3 agent to discover the DLEP-capable
interfaces without explicitly configuring them one by one.

DLEP should provide a list of other layer-2 participants behinds its
local interface identified by their MAC address.

DLEP provide both data about layer-2 participants (addresses, local
resources,...) and data about connection between layer-2 participants
(link-metrics, statistics, ...). As long as they are known to the MAC
layer of course.

-----

Some Layer-2 MACs are aware of link data beyond their direct
neighborhood. Especially TDMA implementations often keep track of at
least the two-hop neighborhood (had a long talk with the Software
Defined Radio group in our institute). In fact, a lot of them are
running something similar to NHDP on layer-2. Exporting this collected
link data would be interesting for layer-3 too.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Apr 2012 17:21:52 +0200

> Concerning:

I totally disagree with this. Access to layer-2 data is important for
good routing metrics, but the layer-2 cannot know what kind of routing
metric the layer-3 is using. Mixing everything together on layer-2 and
only providing some "dimensionless" metric value would be a total
disaster, because the layer-3 doesn't even know what it mean. Or it
might not fit the global metric the routing is using.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 Apr 2012 11:23:26 -0400

On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote:

> I've been trying to consider the issue of 5444 fit, having an  
> interest as an author of 5444. And despite several requests, I  
> haven't seen a clear statement and good example(s) of what that  
> information is. And having to dig through the draft is not the  
> answer to that. I'm actually not worried (in this context) about the  
> details of how many link metric types there are, for example,

Actually, digging through the draft *is* the answer to that, given  
that your knowledge & experience with RFC 5444 formatting (being a co- 
author) is better than mine. By definition, relying on my synopsis of  
what's going on may lead you down an incorrect path - but I'm willing  
to try.

> what matters is that there may be several pieces of information and  
> whether in a given message each reported entity may have different  
> subsets of associated data, or all will have the same? But how those  
> entities are identified - by what sort of addresses and whether any  
> are always present etc. - is critical. And if there is information  
> not associated with addressed entities, is that one-of or multiple,  
> and if the latter how they identified? These are the critical  
> questions with regard to formatting, and they aren't being clearly  
> and simply answered.
>

The goal is to identify *both* the radio device (it doesn't *have* to  
be a radio, BTW) *and* the community of devices that the radio come  
into contact with. The devices that a given RF net might come into  
contact with WILL have associated Layer 2 addresses, they will  
certainly have at least 1 flavor of Layer 3 address, but in my  
deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH  
Link-Local and Global IPv6 addresses). As mentioned in an earlier  
post, metrics don't have meaning from a routing perspective unless/ 
until said metrics can be associated with addresses - destinations.  
The idea is for the RF device to tell the router when it "sees"  
another device over the RF (Neighbor Up), and when it "goes  
away" (Neighbor Down). Upon seeing a device, there may (or may not) be  
metrics associated with it. Those metrics may change whilst the device  
is in RF range, hence the need for Neighbor Update. Also, Layer 3  
addressing could theoretically change (via modifying configuration  
from a console, for example) whilst the device is in RF range. So the  
ability to change the Layer 2/Layer 3 relationships, quickly, needs to  
be there - that's why we have address ADD and DROP orders.

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 Apr 2012 11:30:52 -0400

On Apr 4, 2012, at 11:04 AM, Teco Boot wrote:

>> sudden there's supposedly no consensus about "WHAT information we  
>> need in DLEP to fulfill the use-cases"?????  Seriously? Did no one  
>> read the other versions of the draft?
> Some did.
>
>>
>> To be honest, I really don't know how to respond to where this  
>> tread has wound up. It almost looks like the participants in the  
>> thread have suddenly come to the conclusion of "Hey, maybe we need  
>> a way for a radio to transfer "some" data to a locally attached  
>> router! Brilliant! I wonder what data we need?" The current DLEP  
>> draft is an attempt to articulate JUST THAT - what data is needed.
> Needed for the protocols you work with. Good starting point, no one  
> suggested to throw away something. I could easily miss a posting.
>
> But I have some opinions on parts of the protocol. We (IETF) have  
> already STD TRACK protocols for for example L2 address resolving.  
> And I dislike the flow control part being part of the STD TRACK DLEP  
> protocol. Just me and a couple of others.

The rough consensus about the flow control seems to be to leave it in  
there. At least I haven't seen push-back from anywhere else.

>
>> It is based on the experiences of the co-authors in deploying these  
>> networks. So, draft-ietf-manet-dlep-02 represents the notions of  
>> the co-authors as to WHAT is needed.
> Thanks for sharing your experiences. Thanks publishing. Now *we*  
> (MANET GW) come into the difficult part going forward with it.

Yes, and last I looked, I *AM* at part of that WG...

>
>> It also represents the notions of the co-authors as to HOW the data  
>> should be transmitted. The packets fit into RFC 5444 format, as  
>> required by the MANET working group.
> I am not so sure on this "required". If it makes sense, yes. If not,  
> select a better transport protocol for the data.
>
> There were some postings on DLEP messages and packets. DLEP messages  
> cannot be carried in packets for MANET routing protocols. The source  
> & destinations are different.
>
>> Past that, this discussion is devolving into something that simply  
>> isn't useful, IMO. To camp out on this and spin several iterations  
>> doesn't do anyone any good - especially those that are trying to  
>> actually put products into the field to help customers.
> Accepted. Although active members on this thread may have these  
> goals. I have. I do put products into the field.
>
> Back to what this thread is about. Subject is "DLEP and multi-hop  
> neighbours". This is a somewhat inaccurate subscription. For the  
> router, neighbors are neighbors and they are 1-hop away. 2-hop  
> neighbors are neighbor neighbors, so not real neighbors. DLEP is  
> about link metrics to (L3) neighbors.
>
> I think I came up with a requirement for a metric, from sub-IP- 
> layer, directly to be used by L3 routing. Then sub-IP and IP routing  
> has exactly the same info for the topology. Makes live more easy for  
> those that deploy such.

And your question has already been asked and answered - RLQ. As far as  
the "directly to be used by L3 routing" part, that's out of scope for  
DLEP, as we've said time & time again - DLEP is about getting the data  
across the chasm, NOT about what you do with it once you get it there.

Regards,
Stan

---

From: Dr John P Mullen <[email-masked]>
Date: Wed, 4 Apr 2012 10:06:13 -0600

Hi,

True, but a node can request further information as needed.

What concerns me is a node in a dense network which might have 10 or 20 one- or two- hop neighbors. Circulating detailed information about will add significantly to the load on the channel. If a node is interested in getting to a specific other node which is a two-hop neighbor, it only really needs information about the path to that node. Selection might involve a number of different paths through one-hop neighbors, but probably not all. A summary metric can rule out bad choices so the protocol can focus on better ones. Given that the processes are random, point estimates are not enough for good decision-making. So providing information as needed will help reduce the demand on the channel and simplify the overall process.  

John Mullen

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2012 9:22 AM
To: Dr John P Mullen
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

> Concerning:

I totally disagree with this. Access to layer-2 data is important for good routing metrics, but the layer-2 cannot know what kind of routing metric the layer-3 is using. Mixing everything together on layer-2 and only providing some "dimensionless" metric value would be a total disaster, because the layer-3 doesn't even know what it mean. Or it might not fit the global metric the routing is using.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government."

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Apr 2012 18:17:14 +0200

> What concerns me is a node in a dense network which might have 10 or 20 one- or two- hop neighbors. Circulating detailed information about will add significantly to the load on the channel. If a no…

I think a node should only offer the data it has available over DLEP,
nothing more. If the MAC-layer runs a TDMA which informs it about the
link metrics of 1-hop to 2-hop neighbors, DLEP should offer this data.
Some radios might only a few metrics, other many more.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 17:46:01 +0100

That says that a device will have a MAC address. However I'm sure I've seen a post in this thread saying that a device might not have a MAC address.

But assuming that a MAC address is always present, then the 5444 natural thing to do would be to use the MAC addresses as the addresses in the address block. No address compression advantages, but now it's straightforward to associate information with those addresses, in an indexed way, with metrics etc. being normal TLVs. A good generic 5444 parser will then produce some sort of MAC address to other information map or other data structure.

That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put them in an address block. So they need to go in another normal TLV. That's a shame, but I don't see a way round it. (I can't even see a good way round it allowing a 5444bis, unless you have many addresses and efficiency really matters. Of course if someone can see a way they think is better, I'm listening.) That will automatically handle the "only some entities have type of address X issue". (There are run-time tradeoffs to be made there, but that's another issue.) There are some different ways to design such a TLV, or TLVs, and that would depend I think on two things. One is the relative priorities of simplicity and efficiency. Another is how you are going to create and use the addresses.

Let's start with the simple case. An ADDRESS TLV that can contain IPv4 or IPv6 addresses. Any given instance of the TLV can only contain one or the other, but you can have more than one instance, even attached to the same MAC address. (You can thank the IESG for that.) You can tell which type of address from the length field. Or you could have two TLVs that also redundantly told you this in the TLV type.

Now if efficiency matters, we can start reinventing aspects of address compression. But does it? (Real question, I'm not making an assumption either way, I'm just not investing the effort in how that might be done unless it's a real need.)

(A quick comment on the runtime tradeoff. Suppose we have MAC addresses with and without IPv4 and/or IPv6 addresses - just one IPv6 for the moment. We could most efficiently use the ADDRESS TLV by, for example, sorting addresses to e.g. no IP addresses, then IPv4 only, then both, then IPv6 only. That way you can use one each multivalue ADDRESS TLV for IPv4 and IPv6 addresses. But DLEP spec should just advise that, and accept whatever complicated set of ADDRESS TLVs that an implementer chooses to send.)

Metrics etc. are then just standard address block TLVs.

Any information not associated with MAC addresses then has to go in the message TLV block.

If creating an ADDRESS TLV, I'd put that in the global TLV space. Metric TLVs etc.  can be discussed.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 04 April 2012 16:23
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Apr 2012 17:52:20 +0100

I might not use Henning's "total disaster" phrase, but perhaps "won't handle many real use cases". An obvious one is that I don't care if a data link is stable, with an excellent signal to noise ratio, and virtually no latency, if it offers a user data rate of 16 kbit/s and I have high quality video to send. But if I have mission critical short messages to send, give me that link.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 04 April 2012 16:22
To: Dr John P Mullen
Cc: [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 Apr 2012 13:00:58 -0400

On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote:

> That says that a device will have a MAC address. However I'm sure  
> I've seen a post in this thread saying that a device might not have  
> a MAC address.

In the current implementation, every RF partner (neighbor) will have  
some sort of Layer 2 address. There's a bit of a side conversation  
about how a router would communicate with it's LOCAL radio - for  
example, if the router were a card in a chassis, and the radio was the  
next card over in the same chassis...

>
> But assuming that a MAC address is always present, then the 5444  
> natural thing to do would be to use the MAC addresses as the  
> addresses in the address block. No address compression advantages,  
> but now it's straightforward to associate information with those  
> addresses, in an indexed way, with metrics etc. being normal TLVs. A  
> good generic 5444 parser will then produce some sort of MAC address  
> to other information map or other data structure.
>
Then that leave me with "router to LOCAL radio" communication -  
information that "my radio" wants to communicate about itself, and  
*all* of the traffic associated with it. That's currently in DLEP -  
the notion that a radio could quickly state "the maximum data rate on  
all destinations via me is X". Not sure how to do that while we're  
encoding MAC addresses into address blocks. Also, that gives the  
metrics the notion of existing "within a context" - either they apply  
to a single RF partner (a neighbor), or all RF partners via the radio  
- that's what the current DLEP refers to as a "peer-level metric".

Regards,
Stan

> That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put  
> them in an address block. So they need to go in another normal TLV.  
> That's a shame, but I don't see a way round it. (I can't even see a  
> good way round it allowing a 5444bis, unless you have many addresses  
> and efficiency really matters. Of course if someone can see a way  
> they think is better, I'm listening.) That will automatically handle  
> the "only some entities have type of address X issue". (There are  
> run-time tradeoffs to be made there, but that's another issue.)  
> There are some different ways to design such a TLV, or TLVs, and  
> that would depend I think on two things. One is the relative  
> priorities of simplicity and efficiency. Another is how you are  
> going to create and use the addresses.
>
> Let's start with the simple case. An ADDRESS TLV that can contain  
> IPv4 or IPv6 addresses. Any given instance of the TLV can only  
> contain one or the other, but you can have more than one instance,  
> even attached to the same MAC address. (You can thank the IESG for  
> that.) You can tell which type of address from the length field. Or  
> you could have two TLVs that also redundantly told you this in the  
> TLV type.
>
> Now if efficiency matters, we can start reinventing aspects of  
> address compression. But does it? (Real question, I'm not making an  
> assumption either way, I'm just not investing the effort in how that  
> might be done unless it's a real need.)
>
> (A quick comment on the runtime tradeoff. Suppose we have MAC  
> addresses with and without IPv4 and/or IPv6 addresses - just one  
> IPv6 for the moment. We could most efficiently use the ADDRESS TLV  
> by, for example, sorting addresses to e.g. no IP addresses, then  
> IPv4 only, then both, then IPv6 only. That way you can use one each  
> multivalue ADDRESS TLV for IPv4 and IPv6 addresses. But DLEP spec  
> should just advise that, and accept whatever complicated set of  
> ADDRESS TLVs that an implementer chooses to send.)
>
>> need

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 4 Apr 2012 18:08:29 +0100

> That says that a device will have a MAC address. However I'm sure I've
> seen a post in this thread saying that a device might not have a MAC
> address.

My reading of Stan's draft agrees, all neighbour messages have a MAC address.  There are however peer messages (between local router and modem) that do not.

> But assuming that a MAC address is always present, then the 5444 natural
> thing to do would be to use the MAC addresses as the addresses in the
> address block. No address compression advantages, but now it's
> straightforward to associate information with those addresses, in an
> indexed way, with metrics etc. being normal TLVs. A good generic 5444
> parser will then produce some sort of MAC address to other information map
> or other data structure.

Yes, I think Henning and I have been proposing this.

> That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put them
> in an address block. So they need to go in another normal TLV. That's a
> shame, but I don't see a way round it. (I can't even see a good way round
> it allowing a 5444bis, unless you have many addresses and efficiency
> really matters. Of course if someone can see a way they think is better,
> I'm listening.) That will automatically handle the "only some entities
> have type of address X issue". (There are run-time tradeoffs to be made
> there, but that's another issue.) There are some different ways to design
> such a TLV, or TLVs, and that would depend I think on two things. One is
> the relative priorities of simplicity and efficiency. Another is how you
> are going to create and use the addresses.

There is already an IPv4 and IPv6 address TLV in the draft, and consensus seems to be that they are the best way to express the addressing information in RFC5444 terms.  The IP addresses directly link to the MAC address of the address-block they can appear in, they are not separate.

> Let's start with the simple case. An ADDRESS TLV that can contain IPv4 or
> IPv6 addresses. Any given instance of the TLV can only contain one or the
> other, but you can have more than one instance, even attached to the same
> MAC address. (You can thank the IESG for that.) You can tell which type of
> address from the length field. Or you could have two TLVs that also
> redundantly told you this in the TLV type.

See my comment above concerning the current draft.  Yes, one could consolidate to one standard Address TLV, using the length to determine the address family.

> Now if efficiency matters, we can start reinventing aspects of address
> compression. But does it? (Real question, I'm not making an assumption
> either way, I'm just not investing the effort in how that might be done
> unless it's a real need.)

Efficiency is of little interest in reality - the traffic is only flowing across a local fixed link, not across the MANET.

> (A quick comment on the runtime tradeoff. Suppose we have MAC addresses
> with and without IPv4 and/or IPv6 addresses - just one IPv6 for the
> moment. We could most efficiently use the ADDRESS TLV by, for example,
> sorting addresses to e.g. no IP addresses, then IPv4 only, then both, then
> IPv6 only. That way you can use one each multivalue ADDRESS TLV for IPv4
> and IPv6 addresses. But DLEP spec should just advise that, and accept
> whatever complicated set of ADDRESS TLVs that an implementer chooses to
> send.)

Really not needed.  The MAC address is the only mandatory address used with neighbours.  Use MAC addresses in address-blocks, and carry any additional addresses associated with that MAC as Address-block data.

> Metrics etc. are then just standard address block TLVs.

Yes, agreed.

> Any information not associated with MAC addresses then has to go in the

Yes, agreed.

> TLVs etc.  can be discussed.

I'd rather not create them, except as 'data' TLVs in an MAC-address Address-Block.

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 4 Apr 2012 18:14:03 +0100

> Stan Ratliff

I always imagined these LOCAL messages would remain as is specified in
the draft: Message-Block TLVs...  

> - that's what the current DLEP refers to as a "peer-level metric".

No association with a neighbour, no Address-Block TLVs, just
Message-Block TLVs.

Rick Taylor

********* snip ***********

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Apr 2012 19:23:00 +0200

> the draft: Message-Block TLVs...

Or a series of Message-TLVs, one for each parameter we need. This
makes it very easy to leave out parameters that are not necessary and
even add optional data to DLEP orders later.

> No association with a neighbour, no Address-Block TLVs, just
Yes, message TLVs are a good solution to transport information about
the whole radio.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 10:01:39 +0100

The local information could go in the message TLV block. If it's of a similar nature to the non-local information, then you need to duplicate the TLVs, but that's just paperwork (and IANA are encouraged to give it the same number by some text in 5444, IIRC). That's fine as long as any DLEP message has a well-defined (by source IP address if nothing else, but there's also originator IP address, or you could invent a TLV) local entity that the message TLV block refers to.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 04 April 2012 18:01
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 10:06:17 +0100

Rick
> Me
addresses

> Really not needed.  The MAC address is the only mandatory address used
with
>  neighbours.  Use MAC addresses in address-blocks, and carry any
additional
> addresses associated with that MAC as Address-block data.

I think that's missing my point. But it's secondary and we can get back
to it later.

>> If creating an ADDRESS TLV, I'd put that in the global TLV space.
Metric
>> TLVs etc.  can be discussed.

> I'd rather not create them, except as 'data' TLVs in an MAC-address
Address-Block.

I'm not sure what you mean that's different to what I mean.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 10:15:10 +0100

I had in mind separate TLVs, both address block and message, for each meaningful piece of data.

Thus, for example, we might have a TLV for data rate, a TLV for delay etc. These might use different subtypes of a single TLV type, which we might use the collective term metric for. There mcould be message and address block versions of the TLV, identical except for the TLV space. Those in an address block TLV block then indicate which MAC address they apply to, implicitly a neighbour, and those in the message TLV block apply locally. If we have a data rate but not a delay for a neighbour then there is no TLV of the delay type associated with that MAC address. 

(Actually, in another secondary point, it might make things easier if the metric value allowed an "unknown" option, probably coded zero, to allow multivalue TLVs to span over ranges including some addresses with known e.g. delays and some without. But let's not get hung up on this point now.)

IP addresses are then another meaningful piece of data in the sense of my first paragraph above.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 04 April 2012 18:23
To: Rick Taylor
Cc: Stan Ratliff; Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 05 Apr 2012 11:26:35 +0200

On 04/05/2012 11:01 AM, Dearlove, Christopher (UK) wrote:
> The local information could go in the message TLV block. If it's of a
> similar nature to the non-local information, then you need to
> duplicate the TLVs, but that's just paperwork (and IANA are
> encouraged to give it the same number by some text in 5444, IIRC).
agreed.

> That's fine as long as any DLEP message has a well-defined (by source
> IP address if nothing else, but there's also originator IP address,
> or you could invent a TLV) local entity that the message TLV block
> refers to.
Source-IP doesn't work, because DLEP should be transport protocol 
independent. DLEP over USB would have no IPs on both ends for example.

But instead of originator-IP (DLEP will most likely use 6 byte 
addresses, so no IP as originator), we could use the radios MAC (which 
must exist somewhere to allow it working in an IP network) as the 
originator-address of the RFC5444 message.

On 04/05/2012 11:15 AM, Dearlove, Christopher (UK) wrote:
 > Thus, for example, we might have a TLV for data rate, a TLV for delay 
etc. These might use different subtypes of a single TLV type, which we 
might use the collective term metric for. There mcould be message and 
address block versions of the TLV, identical except for the TLV space. 
Those in an address block TLV block then indicate which MAC address they 
apply to, implicitly a neighbour, and those in the message TLV block 
apply locally. If we have a data rate but not a delay for a neighbour 
then there is no TLV of the delay type associated with that MAC address.

Using one TLV-type for each kind data format might work too. One TLV 
tpye for all kind of "data rates" (always x bytes measured in bits/s), 
one for counters, one for signal strength, ...

 > (Actually, in another secondary point, it might make things easier if 
the metric value allowed an "unknown" option, probably coded zero, to 
allow multivalue TLVs to span over ranges including some addresses with 
known e.g. delays and some without. But let's not get hung up on this 
point now.)
I think we do not need the "unknown" encoding. In most radio 
implementations we have a certain metric type for each of the neighbors 
or for none.

If we want a "unknown" encoding, it should not be a value that is also 
included in the valid range of the metric. Otherwise we could not see 
the difference between "not measured" and a metric that is accidentally 
the 'default value'.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 10:31:11 +0100

I will defer to Stan on the question of whether the scenario "collecting metric X, know it for neighbours A, B, C but not D, E, F" is one DLEP needs.

Absolutely agree with that if we include unknown then it needs to be an out of band value. Zero usually is, or all bits set may be reserved for that purpose. But let's address the point above first, and before that the basic concept.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 05 April 2012 10:27
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

agreed.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 5 Apr 2012 09:57:30 -0400

My apologies for being dense...

So, we've gone from a set of sub-TLV's that are common in all cases to  
a notion where it's entirely possible (wording in 5444  
notwithstanding) where Latency could be known by 2 different TLV's?  
One referencing an Address block, and the other a Message TLV? And  
this is supposed to make the protocol "better"?  And how many 5444  
TLV's are we talking about consuming? One of the biggest complaints  
about the earlier versions of the protocol (specifically, from Justin  
Dean) was that we were consuming too much of the TLV number space in  
5444. So, we went to an implementation where we consumed exactly 1. I  
don't see how this makes anything better...

Regards,
Stan

On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote:

> Thus, for example, we might have a TLV for data rate, a TLV for  
> delay etc. These might use different subtypes of a single TLV type,  
> which we might use the collective term metric for. There mcould be  
> message and address block versions of the TLV, identical except for  
> the TLV space. Those in an address block TLV block then indicate  
> which MAC address they apply to, implicitly a neighbour, and those  
> in the message TLV block apply locally. If we have a data rate but  
> not a delay for a neighbour then there is no TLV of the delay type  
> associated with that MAC address.
>
> (Actually, in another secondary point, it might make things easier  
> if the metric value allowed an "unknown" option, probably coded  
> zero, to allow multivalue TLVs to span over ranges including some  
> addresses with known e.g. delays and some without. But let's not get  
> hung up on this point now.)
>
>>> From: [email-masked] [mailto:[email-masked]] On  
>>> Behalf
>> Of
>>> Stan Ratliff
>>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 15:22:48 +0100

Message TLVs and address block TLVs are independent spaces. So we're not really here talking about two different TLVs, but the same TLV, existing in two spaces. As an example look at RFC 5497 which defines validity and interval time TLVs. These were wanted by OLSRv2 (and NHDP) as message TLVs, but some people wanted them also defined as address block TLVs for possible per-address use (though no one has yet done so). But you just describe once, and IANA allocates twice. It's just paperwork, not a real addition in complexity. (It's slightly more complicated in 5497, as even the two TLVs have much in common, so there are two layers of description.)

And as has been previously said, you can consume 0 TLVs from the global space if you want to, by making the TLVs message type specific. And allowing that types are really 16 bit numbers (half is called a type extension, but it is in effect 8 bits of the overall type) there are quite a lot of TLVs. Obviously you'd logically organise the selected types.

The point would be to allow a generic 5444 parser, such as that several people already have, to be able to fully parse a DLEP message into some sort of associative data structure without any new code needing to be written for DLEP alone. And the overall DLEP code could be simpler.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 05 April 2012 14:58
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; Rick Taylor; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 5 Apr 2012 10:43:16 -0400

But the fact that they're in two different spaces means that, by  
definition, they could wind up numbered differently. Even if the  
initial allocation is done "correctly", when considering follow-on  
additions (as mentioned by Tom Henderson), you can't guarantee the  
same code point will be available in both spaces. The way we've  
currently done it, if at some point in the future, there is a need for  
a "Size-of-tin-can to length-of-string ratio" metric, then fine. It  
gets allocated - ONCE - out of the DLEP defined space. Not TWICE - and  
*hopefully* that same one - out of two different spaces.

As to the utility of a generic 5444 parser, I see that this may save  
someone a few lines of code - but at what cost? IMO, this makes the  
protocol MUCH more complex. And while we're on the topic of code, as I  
mentioned in Paris, there are 3 *existing* implementations of DLEP  
code. I feel Thomas' pain when mentioning "running code" - or have we  
changed the IETF mantra to "rough consensus, and to hell with the  
running code"???

Regards,
Stan

On Apr 5, 2012, at 10:22 AM, Dearlove, Christopher (UK) wrote:

> Message TLVs and address block TLVs are independent spaces. So we're  
> not really here talking about two different TLVs, but the same TLV,  
> existing in two spaces. As an example look at RFC 5497 which defines  
> validity and interval time TLVs. These were wanted by OLSRv2 (and  
> NHDP) as message TLVs, but some people wanted them also defined as  
> address block TLVs for possible per-address use (though no one has  
> yet done so). But you just describe once, and IANA allocates twice.  
> It's just paperwork, not a real addition in complexity. (It's  
> slightly more complicated in 5497, as even the two TLVs have much in  
> common, so there are two layers of description.)
>
> And as has been previously said, you can consume 0 TLVs from the  
> global space if you want to, by making the TLVs message type  
> specific. And allowing that types are really 16 bit numbers (half is  
> called a type extension, but it is in effect 8 bits of the overall  
> type) there are quite a lot of TLVs. Obviously you'd logically  
> organise the selected types.
>
> The point would be to allow a generic 5444 parser, such as that  
> several people already have, to be able to fully parse a DLEP  
> message into some sort of associative data structure without any new  
> code needing to be written for DLEP alone. And the overall DLEP code  
> could be simpler.
>
> -- 
> Christopher Dearlove

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Apr 2012 16:30:46 +0100

There is IIRC, a comment in the expert review/IANA section that advises the same numbering (each has its own complete set of numbers). And if in the private numbering space, that is easy, as you are starting from a clean sheet (in effect) and the common numbering can be mandated. (Not that different numbering need actually be difficult. The point of generic 5444 parsing code is that it doesn't need to know. But agreed that it would be stupid.) I think the difference between allocated once and twice is trivial, it's a trivially more complicated instruction to IANA is all.

Note that I'm mainly engaged in this as a "this is how to do it best fitting 5444". I admit that's my natural preference. But I don't currently have a basis/need to make a tradeoff between "better" and "running code". We don't do votes, but if we did I'd probably abstain. However I would want the debate to be fully informed, which is my intention here. Coding also cuts two ways. With changes suggested I already have a DLEP parser - it's my generic 5444 parser, it just needs a few trivial callback functions added. With sub-TLVs I would need new code. I'm just an example that doesn't matter here, but are there others?

I definitely do not agree with that this makes the protocol much more complex. In the eye of this beholder, it makes it simpler. (Which is simpler, using TLVs as already defined, or inventing a whole new concept of sub-TLVs to be parsed? Loaded wording, but accurate.) It depends where you are starting from. (If we cared about efficiency - we don't seem to - that could also be assessed, and I have no idea which would win there - probably neither.)

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 05 April 2012 15:43
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; Rick Taylor; [email-masked]
Subject: Re: [manet] DLEP and multi-hop neighbours

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 9 Apr 2012 10:36:34 -0700

Hi,

I agree with Chris' position. Using message/address block TLVs instead of
sub-TLVs would not waste space from the registry when using message
specific TLVs. And with the type extension, there are plenty of available
TLVs anyway.

Henning mentioned in one of the previous emails that currently DLEP does
not really use the 5444 message format, but rather a 5444-wrap-around of a
proprietary format. I somewhat agree with that. A common RFC5444 parser
could not deal with DLEP messages, an additional parser would need to be
implemented, leading to additional code. Thus my desire to use address
blocks and address/message TLVs rather than sub-TLVs and addresses in TLVs.
I don't see why this would lead to additional complexity, assuming that an
RFC5444 parser is required anyway for the L3 routing protocol.

>From skimming through the 100 emails that have been exchanged during my
one-week vacation, it seems that there is some consensus that using MAC
addresses in address blocks and IP addresses in TLVs seems to be a
reasonable compromise. (at least it sounds reasonable to me, but not being
a DLEP specialist, I might miss something).

Since there are existing implementations and deployments, it could be
helpful for this discussion to see some examples of typically exchanged
messages (with real MAC/IP addresses and metrics etc) in a human-readable
format. This would allow for better understanding what the messages look
like (e.g. how many IP addresses, what kind of metric information is
associated with which addresses etc). That could be even added to the DLEP
appendix, similar to RFC6130/OLSRv2.

Regards
Ulrich

On Thu, Apr 5, 2012 at 7:43 AM, Stan Ratliff <[email-masked]> wrote:

> definition, they could wind up numbered differently. Even if the initial
> allocation is done "correctly", when considering follow-on additions (as
> mentioned by Tom Henderson), you can't guarantee the same code point will
> be available in both spaces. The way we've currently done it, if at some
> point in the future, there is a need for a "Size-of-tin-can to
> length-of-string ratio" metric, then fine. It gets allocated - ONCE - out
> of the DLEP defined space. Not TWICE - and *hopefully* that same one - out
> of two different spaces.
>
> mentioned in Paris, there are 3 *existing* implementations of DLEP code. I
> feel Thomas' pain when mentioning "running code" - or have we changed the
> IETF mantra to "rough consensus, and to hell with the running code"???
>
> Regards,
> Stan
>
>
>  Message TLVs and address block TLVs are independent spaces. So we're not
>> really here talking about two different TLVs, but the same TLV, existing in
>> two spaces. As an example look at RFC 5497 which defines validity and
>> interval time TLVs. These were wanted by OLSRv2 (and NHDP) as message TLVs,
>> but some people wanted them also defined as address block TLVs for possible
>> per-address use (though no one has yet done so). But you just describe
>> once, and IANA allocates twice. It's just paperwork, not a real addition in
>> complexity. (It's slightly more complicated in 5497, as even the two TLVs
>> have much in common, so there are two layers of description.)
>>
>> And as has been previously said, you can consume 0 TLVs from the global
>> space if you want to, by making the TLVs message type specific. And
>> allowing that types are really 16 bit numbers (half is called a type
>> extension, but it is in effect 8 bits of the overall type) there are quite
>> a lot of TLVs. Obviously you'd logically organise the selected types.
>>
>> The point would be to allow a generic 5444 parser, such as that several
>> people already have, to be able to fully parse a DLEP message into some
>> sort of associative data structure without any new code needing to be
>> written for DLEP alone. And the overall DLEP code could be simpler.
>>
>> --
>> Christopher Dearlove
>> ------------------------------**--------------------------
>>
>>> ------------------------------**--------------------------
>>>
>>>> From: [email-masked] [mailto:[email-masked]**] On
>>>>> Behalf
>>>>>
>>>> Of
>>>>
>>>>> Stan Ratliff
>>>>>
>>> ************************************************************************
>>> ************************************************************************
>>>
>>>
>>
>>
> ______________________________**_________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/manet<https://www.ietf.org/mailman/listinfo/manet>
>

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 10 Apr 2012 16:11:30 +0100

Following the massive debate on fitting DLEP to RFC5444/packetBB, I have
started to draw up some ASCII art packets, and have immediately hit a
question.  I will try to provide some background...

In OLSR, there are 3 Message-Types: HELLO, TC, and MID.  Each has its
own assigned number, and can contain TLVs either in the message-block or
the address-block as is relevant.

In DLEP, there are 17 potential message-types (currently).  Now, in
draft-02, the authors have opted to have a single message-type
(DLEP_MESSAGE) and then have 17 TLVs for each 'message' with sub-TLVs to
carry per-TLV extra data, some mandatory, some optional.

As I see it, there are 3 choices:

1) DLEP reserves 17+ top-level message type ids, and the sub-TLVs become
TLVs.

2) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and the
sub-TLVs remain. 

3) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and each
DLEP message has a single mandatory message-private TLV (containing all
the mandatory per-DLEP-message data) and uses the TLV-type-extension
mechanism to handle optional sub-TLVs.  The problem with this solution
is the implicit ordering introduced between the extension TLV-types and
the 'base' TLV type.

Note: I am *not* discussing address-block TLVs vs message-block TLVs, as
I believe there is rough consensus on that issue.

As an example of option 3)

Here is a DLEP Attached Peer Discovery message, with the mandatory
server and client IDs, and with 1 optional ext-type TLV for version.  I
include the packet header as well.  You might have to consult your copy
of RFC5444 to check the flag-bits (and I might have got them reversed)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Packet |Packet |  Msg Type =   |  Msg  |  Msg  | Message Size  ~
|Version| Flags | DLEP_MESSAGE  | Flags |AddrLen|               ~
|  0x0  |0 0 0 0|  (value TBD)  |0 0 0 1|   0   |      27       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Size  |                               |  TLVs length  ~
~               |    Message Sequence Number    |               ~
~               |                               |      19       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~  TLVs length  | DLEP Attached |   TLV flags   |  TLV length   |
~               |Peer Discovery |               |               |
~               |  (value TBD)  |0 0 0 1 0 0 0 0|       8       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Server ID                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Client ID                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP Attached |   TLV flags   | TLV Ext Type  |   TLV length  |
|Peer Discovery |               |   'VERSION'   |               |
|  (value TBD)  |1 0 0 1 0 0 0 0|  (value TBD)  |       4       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
|             Major             |             Minor             |
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Hope that is clear enough to start another round of discussion...

Rick Taylor

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 10 Apr 2012 08:22:56 -0700

Hi Rick,

> 1) DLEP reserves 17+ top-level message type ids, and the sub-TLVs become

That's probably not a good idea, given that we only have 255 message types
for MANET protocols.

> 2) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and the

For the reasons I wrote in my last email, I don't think this is a good idea
either (redundant parser code).

> is the implicit ordering introduced between the extension TLV-types and

Isn't there a 4th possible solution:
4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV which
defines the "message type" plus zero or more message-specific TLVs for the
data? (i.e. no sub-TLVs, and not necessarily a type extension).

Or is that what you mean?

Regards
Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 10 Apr 2012 21:13:55 +0200

> data? (i.e. no sub-TLVs, and not necessarily a type extension).

We could even make this "message type" TLV a generic message TLV and
call it MESSAGE_EXTTYPE. It would either have a 1 byte value or an
extension type itself, it would be similar to the optional extension
type of normal TLVs, extending the concept to messages.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 09:56:05 +0100

> > defines the "message type" plus zero or more message-specific TLVs
for
> type of normal TLVs, extending the concept to messages.

Could you elaborate on this for me please? I don't see how this is
different from Stan's sub-TLV proposal?

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 11:02:19 +0200

On 04/11/2012 10:56 AM, Rick Taylor wrote:
>> On Tue, Apr 10, 2012 at 17:22, Ulrich Herberg<[email-masked]>
> wrote:

I support the same strategy Ulrich Herberg suggested, moving all subTLVs 
into normal message TLVs and addresses/address-TLVs.

To allow the receiver of the DLEP message to differentiate between the 
DLEP protocol messages (called "orders" in the current draft), we add an 
additional TLV that carries the order number (either as a 1-byte value 
or as the TLV extension type).

I think instead of making this TLV a DLEP-specific, we could use a TLV 
from the "global" message TLV scope. The concept of having an "extension 
type" for the message type could be useful in other future protocols too.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 11:43:02 +0100

> type" for the message type could be useful in other future protocols
too.

Isn't this very similar to what I proposed?  DLEP-specific TLVs that
state which DLEP order is contained in the message + extra TLVs to carry
additional information?

>From my reading of draft-02, each 'order' carries some mandatory
information, which can be placed in a single message-specific TLV, plus
optional information, that can be carried in message-specific
order-extension TLVs in the same message?  By careful selection of
extension type ids we can keep the sub-TLV concept.

If I analyse the DLEP draft and assign some simple IDs, the orders are:

KEY:
  0xXX   - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type)
  0xXXYY - Optional TLV type 0xXX+128, extension 0xYY

All address-block-TLVs use a <address-len> of 6 and the MAC address of
the neighbour.

Please note the encoding of the extension types, i.e. the extension-id
is constant, just the type-id changes (sort of covering the sub-TLV
concept)

I have also made version and status mandatory whenever specified.

Attached Peer Discovery (message-block-TLVs)
  0x01  Identification + Version
  0x0101 Peer Type
  0x0102 Heartbeat Interval
  0x0103 Heartbeat Threshold
  0x0104 Link Characteristics ACK Timer
  0x0181 Maximum Data Rate
  0x0182 Current Data Rate
  0x0183 Latency
  0x0184 Expected Forwarding Time
  0x0185 Resources
  0x0186 Relative Link Quality

Detached Peer Discovery (message-block-TLVs)
  0x02  Identification + Version
  0x0201 Peer Type
  0x0202 Heartbeat Interval
  0x0203 Heartbeat Threshold
  0x0204 Link Characteristics ACK Timer
  0x0281 Maximum Data Rate
  0x0282 Current Data Rate
  0x0283 Latency
  0x0284 Expected Forwarding Time
  0x0285 Resources
  0x0286 Relative Link Quality

Peer Offer (message-block-TLVs)
  0x03  Identification + Version + Status
  0x0301 Peer Type
  0x0302 Heartbeat Interval
  0x0303 Heartbeat Threshold
  0x0304 Link Characteristics ACK Timer
  0x0311 IPv4 Address
  0x0312 IPv6 Address

Peer Update Message (message-block-TLVs)
  0x04  Identification + Version
  0x0401 Peer Type
  0x0411 IPv4 Address
  0x0412 IPv6 Address
  0x0481 Maximum Data Rate
  0x0482 Current Data Rate
  0x0483 Latency
  0x0484 Expected Forwarding Time
  0x0485 Resources
  0x0486 Relative Link Quality
  
Peer Update ACK Message (message-block-TLVs)
  0x05  Identification + Status

Peer Termination Message (message-block-TLVs)
  0x06  Identification + Status

Peer Termination ACK Message (message-block-TLVs)
  0x07  Identification + Status

Peer Heartbeat Message (message-block-TLVs)
  0x08  Identification

Neighbour Up Message (address-block-TLVs)
  0x01  Identification
  0x0101 Credit Window Status
  0x0111 IPv4 Address
  0x0112 IPv6 Address
  0x0181 Maximum Data Rate
  0x0182 Current Data Rate
  0x0183 Latency
  0x0184 Expected Forwarding Time
  0x0185 Resources
  0x0186 Relative Link Quality

Neighbour Up ACK Message (address-block-TLVs)
  0x02  Identification + Status
  0x0201 Credit Window Status
  
Neighbour Down Message (address-block-TLVs)
  0x03  Identification + Status

Neighbour Down ACK Message (address-block-TLVs)
  0x04  Identification + Status

Neighbour Update Message (address-block-TLVs)
  0x05  Identification
  0x0501 Credit Window Status
  0x0502 Credit Grant
  0x0503 Credit Request
  0x0581 Maximum Data Rate
  0x0582 Current Data Rate
  0x0583 Latency
  0x0584 Expected Forwarding Time
  0x0585 Resources
  0x0586 Relative Link Quality

Neighbour Address Update Message (address-block-TLVs)
  0x07  Identification
  0x0711 IPv4 Address
  0x0712 IPv6 Address

Neighbour Address Update ACK Message (address-block-TLVs)
  0x08  Identification + Status

Link Characteristics Request Message (address-block-TLVs)
  0x09  Identification
  0x0982 Current Data Rate
  0x0983 Latency

Link Characteristics ACK Message (address-block-TLVs)
  0x0A  Identification
  0x0A82 Current Data Rate
  0x0A83 Latency

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 12:48:49 +0200

On 04/11/2012 12:43 PM, Rick Taylor wrote:
> All address-block-TLVs use a<address-len>  of 6 and the MAC address of
> the neighbour.
>

Why should we use different TLV types/exttypes for each of the orders?

One TLV-type for "Peer Type" (as an example) should be enough for all 
orders used in DLEP.

The same is true for every TLV used for the data necessary for any DLEP 
order.

We should work on making the protocol SIMPLER without loosing 
functionality, not making it even more complex.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 12:19:02 +0100

> One TLV-type for "Peer Type" (as an example) should be enough for all

Then how do you handle the multiple optional parts of each DLEP order?

Can you give an example please?  I think I'm being stupid!

> functionality, not making it even more complex.

I completely agree.  I was happy with sub-TLVs, but there has been some
feedback from others that it doesn't match RFC5444 well.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 13:38:04 +0200

On 04/11/2012 01:19 PM, Rick Taylor wrote:
>> One TLV-type for "Peer Type" (as an example) should be enough for
>> all orders used in DLEP.
>

RFC5444 allows you just to leave out any TLV you don't want to add. The 
parser can recognize which TLVs are present without any overhead in the 
message or signaling.

> Can you give an example please?  I think I'm being stupid!

I just use TLV-types starting with 100 in the following simplified example:

Message-TLVs
============

ORDER TLV: type=100, 1 byte binary value (order of this DLEP-message)

PEER_TYPE TLV: type=101, 1-80 bytes binary value (text describing the peer)

Address TLVs
============

IPV4 TLV: type 102, 5 bytes binary value (4 byte IPv4 address plus 1 
byte prefix length)

IPv6 TLV: type 103, 17 bytes binary value (16 byte IPv6 address plus 1 
byte prefix length)

Attached Peer Discovery Message:
- ORDER TLV
- PEER_TYPE TLV (optional)

Peer Offer Message:
- ORDER TLV
- PEER_TYPE TLV (optional)

Peer Update Message:
- ORDER TLV
- MAC address
--- IPv4 TLV (optional)
--- IPV6 TLV (optional)

>> The same is true for every TLV used for the data necessary for any
>> DLEP order.
>>
> I completely agree.  I was happy with sub-TLVs, but there has been
> some feedback from others that it doesn't match RFC5444 well.

Yes.

At the moment the complete RFC5444 generation of DLEP could be described at:

1) Add static prefix 1
    (packet header + message header before sequence number)
2) Add sequence number
3) Add static prefix
    (message header after sequence number and TLV header)

and then add the Sub-TLVs.

The receiver-part could be this:

1) Ignore static prefix 1
2) read sequence number
3) Ignore static prefix 2
4) read sub-TLVs

Thats not really RFC5444.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 13:38:57 +0100

> I just use TLV-types starting with 100 in the following simplified

*** SNIP ***

Aaah... I see now.  This is very close to what I was proposing, but with
a simplification (no extension types).  I would add the Identification
parts, etc. to the order TLV as well, just to save a bit of processing.
I was just suggesting encoding some context into the id assignment.

My concern would be that in the message-specific type range there are
only 96 ids, and I can imagine radio vendors adding a *load* of extra
metrics and consuming ids quickly...

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 14:53:13 +0200

> I was just suggesting encoding some context into the id assignment.

I am not even sure why the "identification" and "version" TLV is a good 
idea to include at all.

In the current draft DLEP allows only a single connection between a 
radio and a router and does not use the identification for anything. Why 
do we need it?

I see the reason for a "version" field in other protocols, but I think 
we might not need it with RFC5444 as the transport format. As long as we 
do not change the semantics of a DLEP order, we can easily add new TLVs 
without breaking compatibility of old/new parsers/generators. If we 
change the semantics, using a new "order" number might be easier (and 
allow us to announce version incompatibilities on a message level!).

> metrics and consuming ids quickly...

We could group TLVs which use the same format and semantics, which 
should allow for a more efficient number space use.

Example:

TLV x "DATARATE": 8 bytes, measured in bits/s

TLV x exttype 0: current outgoing datarate
TLV x exttype 1: current incoming datarate
TLV x exttype 2: maximum network datarate
TLV x exttype 3: maximum radio hardware datarate
(252 new datarates still left)

TLV y "TRAFFIC": 8 bytes, measured in total bytes since connect

TLV y exttype 0: outgoing traffic
TLV y exttype 1: incoming traffic
(254 new types of traffic counting still left)

TLV z "PACKETS": 8 bytes, measured in packets since connect

TLV z exttype 0: outgoing packets
TLV z exttype 1: incoming packets
TLV z exttype 2: retransmitted packets
TLV z exttype 3: lost packets
(252 new types of packet counting still left)

If we start this way, most radio vendor extensions will already have 
their TLV-type and might only need another extension type.

If a radio vendor has lots of custom metrics, he might just grab a 
single TLV and use the 256 extension type of the TLV for his "special 
stuff".

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 14:03:35 +0100

> I am not even sure why the "identification" and "version" TLV is a
good

It is useful when there are connections from 1 router to multiple
modems.  It's not vital when using IP as you can use the src address to
differentiate, but with USB/Firewire/etc. I'm not so sure...

> allow us to announce version incompatibilities on a message level!).

Yes, I agree with you, but I think the authors have the final say...

*** SNIP ***

Yes, I was thinking along the same lines.  I would like to somehow
connect the status TLV to the understanding of received TLVs.  Have a
look at how SCTP chunk-types are numbered (RFC 6096).  The high-bits of
the id of a chunk specify how it should be reported in case of error or
failure to parse.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 15:20:33 +0200

> differentiate, but with USB/Firewire/etc. I'm not so sure...

I agree, an identification for the radio side is usefull, but for this 
we should have the MAC address of the radio. If the radio knows (or can 
calculate) the MAC of every neighbor, it should also know its own MAC.

We could put the MAC of the radio as the "originator address" RFC5444 
message header field in each DLEP message. No need for a TLV of its own.

It would still be transport independent (USB/Firefire/Ethernet/...), not 
being used to address the radio, just as a 6 Byte unique identification.

> Yes, I agree with you, but I think the authors have the final say...

I would still like to get an idea what kind of behavior change the 
protocol should support. If we can support the same thing without a 
mandatory version field, we should consider dropping it.

> the id of a chunk specify how it should be reported in case of error or

You mean using a bit in the extension type to tell the parser which TLVs 
are mandatory to understand the order and which not? So it can say "oh, 
don't worry about this one, its not mandatory?"

(metric TLVs would be all non-mandatory I think)

Maybe we can split the extension types used by DLEP-specific TLVs into 
ranges... something like

0-224: TLV is not mandatory to understand DLEP order
225-255: TLV is mandatory to understand DLEP order

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 14:31:55 +0100

> >> radio and a router and does not use the identification for
anything.
> > Why
> >> we might not need it with RFC5444 as the transport format. As long
as
> > we

I agree the version is not truly needed, but I know people get attached
to version numbers in protocols...

Yes.

> (metric TLVs would be all non-mandatory I think)

Yes.  I was thinking particularly about the credit-windowing TLVs.
Draft-02 is still unclear on the Status TLV contents when
credit-windowing is desired by a router, but unsupported by a modem.
I.e. the peering can happen, but no credit-windowing allowed.

> 225-255: TLV is mandatory to understand DLEP order

Only for extension types?  Why not for all message-specific TLV types?

How about classifying as: MUST understand (kill association), SHOULD
understand (status code response), MAY understand (standard-specified
value, but no status response required), OPTIONAL (must have extension
type?)

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 15:39:50 +0200

> value, but no status response required), OPTIONAL (must have extension

Yes, something like this is missing in RFC 5444.

Hmm, I just noticed something interesting... there are two unused bits 
in the TLV header itself. Maybe this would be something interesting to 
discuss as an extension of RFC5444.

It would be a much cleaner solution than to hack something into the 
extension types or message-tlv types.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Wed, 11 Apr 2012 14:48:35 +0100

> extension types or message-tlv types.

Yes... but there was some comment on this list about not wanting to
update RFC5444 (yet).  And also, how do you connect that the status code
response?  A 'standard' RFC5444 status TLV?

I wanted at some point to suggest an RFC5444 compliant way of handling
ACKs, a packet-TLV with the ackno for the received packet seqno, but I
need to concentrate on DLEP at the moment.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 11 Apr 2012 15:55:21 +0200

On 04/11/2012 03:48 PM, Rick Taylor wrote:
> update RFC5444 (yet).

And if there will be an update some days, it should be forward and 
backward compatible with the current data format of RFC 5444.

> And also, how do you connect that the status code
A status TLV might be a good standard addition to the TLVs, both on 
packet and on message level. But need more thought and input for the 
semantics of a TLV like this.

At the moment DLEP would be the only use-case, OLSR/NHDP/DYMO don't need 
status updates.

DLEP needs it for the active parts of the draft (request link 
characteristics, credit scheme).

> need to concentrate on DLEP at the moment.

Maybe a "Reference" TLV, which contains the sequence number it 
corresponds to as a 2-byte value? Could work both on packet level (for 
link ACKs) and message level (for DLEP).

Of course if a protocol wants to use this TLV, it has to activate the 
sequence numbers on the packet/message level.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Apr 2012 10:03:39 +0000

There were discussions about encoding optional/mandatory information in what became RFC 5444. These weren't used because they weren't good - and they wouldn't have worked for DLEP as they concentrated on different aspects of optional/mandatory-ness than DLEP would have wanted (about forwarding for example). This demonstrates that design for an uncertain future is hard, and best avoided if possible. In addition the proposals confused format and function, where 5444 was intended to provide the former not the latter. (Some function in packet management crept in because 5498 - against the ignored protests of the 5444 authors - dumped some of what it should have done back on 5444.)

I'm catching up elsewhere, so not planning to participate in this for a bit. But I will just note that having a TLV type for metric, and a type extension for which metric, is the poster child for the purpose of a type extension.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 11 April 2012 14:40
To: Rick Taylor
Cc: [email-masked]; [email-masked]; Dearlove, Christopher (UK)
Subject: Re: [manet] DLEP and RFC5444 message types

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Apr 2012 12:41:32 +0200

On 04/19/2012 12:03 PM, Dearlove, Christopher (UK) wrote:
> There were discussions about encoding optional/mandatory information
> in what became RFC 5444. These weren't used because they weren't good
> - and they wouldn't have worked for DLEP as they concentrated on
> different aspects of optional/mandatory-ness than DLEP would have
> wanted (about forwarding for example). This demonstrates that design
> for an uncertain future is hard, and best avoided if possible. In
> addition the proposals confused format and function, where 5444 was
> intended to provide the former not the latter. (Some function in
> packet management crept in because 5498 - against the ignored
> protests of the 5444 authors - dumped some of what it should have
> done back on 5444.)

Okay.

> I'm catching up elsewhere, so not planning to participate in this for
> a bit. But I will just note that having a TLV type for metric, and a
> type extension for which metric, is the poster child for the purpose
> of a type extension.

I think that does only make sense as long as the 'data format' (value) 
of the TLV is always the same type. Having one extension type of 
"metric" for datarate (bits/s, 8 byte data) and another extension type 
for signal strength (dBm, 2 byte data?) sounds strange.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Apr 2012 10:51:30 +0000

I agree that when the format is the same it's an even better fit than when it isn't. But when metrics don't have the same format, using different type extensions of a single type is still better than using separate types. For a start you get to require IANA to create a registry, and you can create rules for that registry about what metric type properties you can and can't add in the future (subject to whichever management of policy for inclusion you set - Expert Review is good). You could also create sub-ranges for different data formats, or various other ways of organising things.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 20 April 2012 11:42
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] DLEP and RFC5444 message types

Okay.

Henning Rogge

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 20 Apr 2012 12:45:17 -0500

From:
http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01

"   The authors of modemLPA have been in discussion with the authors of
   "Dynamic Link Exchange Protocol (DLEP)"  determine
   if DLEP will fullfil the needs that ModemLPA is targeted
   at.  DLEP is currently a client/server session oriented protocol that
   provides link layer information to directly connected devices -
   generally routers.  The Modem Link Property Advertisment protocol
   broadcasts link status notifications to directly-attached devices and
   devices or applications that may be multiple hops away from the modem
   (or other sending device).

   It should be possible to use the DLEP message formats without all the
   signalling required for the DLEP client/server session to perform the
   functions addressed in this draft.  The modem would simply provide
   link states out via multicast or unicast UDP datagrams (DLEP-Lite).
   Whether or not this is a good idea, or acceptable to the manet group,
   is yet to be determined.    "

Basically, DLEP and modemLPA are doing similar things. It is my understanding that DLEP is mainly targeted at providing information to directly attached routers in ad hoc networks.  

ModemLPA is targeted are very simple deployment with a modem (or crypto device or whatever) providing upstream entities with at least some minimal idea of what may be going on in the wireless link by periodically broadcasting status or changes in status .  ModemLPA is looking at devices and applications that may be multiple hops away.  Thus, if DLEP were used, one would operate in a "notification" or "broadcast" mode where status message would be sent to either unicast addresses, link-local multicast addresses or scoped multicast addresses.  The upstream entities would simply listen of the appropriate port.  No response would be required.  
see -
http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01#page-8

For a general idea of modemLPA see - 
http://roland.grc.nasa.gov/~ivancic/shared/modemLPA/ModemLPA.pdf

Questions:

1) Is this a good idea?

2) Is this acceptable to the manet wg to be included as part of DLEP?

3) Should modemLPA remains a separate protocol?

3a) if so, should modemLPA use the DLEP message structure?

- Will

---

From: Henning Rogge <[email-masked]>
Date: Sat, 21 Apr 2012 01:10:13 +0200

We are still in the process of discussing how the mechanisms of DLEP
should work like. Teco already suggested that just multicasting the
layer-2 data regularly and listening by the clients should be a valid
usecase of DLEP.

At the moment the draft contains a lot of complexity, and I still do
not know why its necessary. I hope we will get this resolved.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sat, 21 Apr 2012 08:57:11 +0200

Thanks echoing. I think there is room for a simple protocol, that 
just provide link info to be used for path calculation. DLEP
looks flexible, but it is complex due to IMHO unneeded functions.

I say the STD link exchange protocol MUST support 802.11 IBSS, 
802.11S and infrastructure mode. This brings the default 802.11S 
link metric (airtime / ETT), the optional BestThroughput (Minstrel, 
available at Tx) and many-to-many support on the radio-router link. 
And the 802.11S multi-hop sub-IP topology. (I've seen OSPF on top of 
OLSR...). Sure the protocol MUST support other (some say better) media 
access. 802.11* is just a standardized reference.

I prefer a single STD protocol. Could be DLEP-Lite. Other options 
are IMHO experimental. I already suggested to split off flow control
and address negotiation. There are already better solutions for this.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sat, 21 Apr 2012 10:49:56 +0200

I am experimenting with a "simplified DLEP" implementation at the
moment, which use UDP packets to transport linklayer data from the
linux mac80211 stack.

I skipped all the active parts (both Request Link Characteristics and
the Token scheme) and reduced the rest to four message orders.

Instead of using ACKs or Heartbeats, EVERY message contains a
Validity-Time Message-TLV and has to be repeated within the interval
to stay valid. This makes the whole session handling and state machine
unnecessary without making the protocol unreliable on a lossy
connection to the router (which should be unlikely anyways). Its a
direct copy of the mechanisms of NHDP/OLSRv2.

My current message orders are:

1) interface discovery (radio to router)
Announce the presence of the radio interface via multicast. Can be
used for autodiscovery of radios/modems.

2) neighbor address update (radio to router)
A list of known direct neighbors.
I plan to generate an additional one of this messages every times the
linklayer detects a new neighbor or loose an old one. This can speed
up neighbor discovery.

3) neighbor metric update (radio to router)
Contains metric values of all neighbors.

4) connect router (router to radio)
An optional message that can be sent to the radio to request getting
all its messages also through unicast.

What do you think?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 08:40:41 +0200

> used for autodiscovery of radios/modems.
This is optional? For using a management port/vlan, and
ports/vlans for data? It can be eliminated (see 4).

I think the basic mode would be using a single interface, with 
filter blocking DLEP on the RF interface. Then, there is no need
for interface discovery.

> linklayer detects a new neighbor or loose an old one. This can speed
Why? Metric updates provides the neighbors. This needs triggered 
updates anyway.

> Contains metric values of all neighbors.
I think we need only incremental updates (lots of small messages).
Use a HighestValue (or whatever) metric for lost neighbors.
Most lost neighbors would have increasing metrics, towards
what practically equals to lost. 

> all its messages also through unicast.
Useful. On wired connections, multicast should not be a problem.
Maybe TCP for flow control, preventing overruns (CPU, buffers) on router.
It also provides a trigger for DB transfer, in case the router lost state.

The "also" could be weakened. For a 1-to-1 relation between radio and
router, with unicast, the multicast could be stopped. This suppression 
needs valid_time, so the radio starts multicasting when state of the 
router is lost.

You could combine 1 & 4. Radio simply multicasts neighbor state, until 
it is told to do it different. Router multicasts: please send your DLEP 
info with [ tcp | udp | other ] on interface [ this | vlan nn | other ], 
duration [ valid_time], and [ do | do_not] suppress multicast. 

> What do you think?
I like simple and efficient protocols, which do exactly what is needed.
Nothing less, nothing more. I think you took the right approach.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sun, 22 Apr 2012 09:34:15 +0200

> ports/vlans for data? It can be eliminated (see 4).
But then you would need to know the IP address of the radio. If you
are willing to configure it, this could be skipped.

You could switch this off in my code by setting the Radio Discovery
Interval to zero.

> filter blocking DLEP on the RF interface. Then, there is no need
There is still the question for the IP address. Unless your
DLEP-Service is on the same node than your router (in which case DLEP
is just a hardware abstraction layer).

> Why? Metric updates provides the neighbors. This needs triggered
I want a message type I can send when the link layer loose a neighbor.
Theoretically, this messages could be joined with the metric update.

> what practically equals to lost.
I think a single "link lost" TLV would be better than have special
values for metrics.

Incremental updates are already possible in my current code, as long
as you repeat one metric at least once every Validity Time. A new
message does not overwrite the old database entry at the moment, it
just overwrites the new metric values of the database entry and resets
the validity time.

I have no "per metric value" validity time planned.

> It also provides a trigger for DB transfer, in case the router lost state.

TCP doesn't work well with RFC 5444, because it does not contain a
total "length" packet. UDP is a much easier way to do this. In
addition to this the kernel can simply throw away UDP packets when
overloaded.

> needs valid_time, so the radio starts multicasting when state of the
Hmm... I am not sure I like this. By keep repeating the Interface
Discovery and Connect Router every Validity Time, i get the
information on both sides that the connection between router and
radio/modem is still present.

> duration [ valid_time], and [ do | do_not] suppress multicast.
I am not sure I like this, but it could be done... I would like to
keep the protocol practically stateless, with easy ways to support
multiple radios on a router and multiple layer-2 data-consumers (one
router, one logging system) getting data from a radio.

> Nothing less, nothing more. I think you took the right approach.
Thank you.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 12:48:18 +0200

> are willing to configure it, this could be skipped.
Msg_3 provides the IP address (or MAC address, for one that likes L2).
Msg_4 is unicast towards this address.
If the protocol switches to unicast, there is no need for VLANs 
or DLEP filter (to prevent DLEP flooding on RF).

> You could switch this off in my code by setting the Radio Discovery
You could remove the code :-), this function is not needed.

> is just a hardware abstraction layer).
I would say that id one wants a multi-hop L3 path between radio and
router, configuration is needed.
If it is only a single L2 link, discovery is easy, using msg_3.

> Theoretically, this messages could be joined with the metric update.
It is the same function, lower complexity and more efficient.

> I think a single "link lost" TLV would be better than have special
It is taste. Or religion. It is a special TLV or a special value.

With special value, DLEP-lite needs only a single (dimensionless...) 
metric TLV. All other TLVs are extensions, and IMHO optional / experimental. 
More important, do not expect compatibility from the other TLVs.

> just overwrites the new metric values of the database entry and resets
:-)

> I have no "per metric value" validity time planned.
Not needed. Could be done with separate messages.

> addition to this the kernel can simply throw away UDP packets when
IP protocol would be OK also.

> radio/modem is still present.
Why? The router to radio unicast will not be forwarded over RF link.
The effect is that the radio sends DLEP to router only.

The DLEP filter in the radio is needed anyway, blocking multicast on RF-link.

> keep the protocol practically stateless,
Me to !!!

> with easy ways to support
My suggestion to suppress DLEP multicast blocks auto-discovery for multiple 
consumers. Easy to fix: let the radio send out a multicast message every now 
and then. Could be empty "announcement" packet.

Teco

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 12:58:37 +0200

> You could remove the code :-), this function is not needed.
Msg_1 is the announcement packet, so the function is needed
Thereafter, Msg_4 is send, where the router requests data.
Then, Msg_3 (and Msg_2) are send.

On Msg_2: do you provide L2/L3 address mapping? Why not trigger router 
HELLO and ARP/NDP? I don't like DLEP-related info over RF-link. We cannot
assume DLEP radio has any idea on L3-stuff on other sides.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sun, 22 Apr 2012 13:48:19 +0200

> Msg_4 is unicast towards this address.
This is an interesting idea, yes.

> or DLEP filter (to prevent DLEP flooding on RF).
I am not sure this works well, especially if you want to bridge the
radio and the router interface on the radio. Especially with
IEEE802.11 radios, you will run into problems because of the mac
addresses.

> You could remove the code :-), this function is not needed.
If an "empty" Neighbor Update message is valid, this could work out
well (Interface discovery without a radio neighbor in range).

Yes.

> More important, do not expect compatibility from the other TLVs.
I totally disagree with this. I don't even think the "dimensionless"
metric TLV is really useful for DLEP, because the router would not
know what this value is about. This whole "hiding information from the
radio" is a bad idea in a lot of cases.

And even with this, the "dimensionless metric" would have to be a
special case, otherwise an "infinite" metric there would not mean the
other DLEP metrics become "infinite" too.

DLEP is for transporting layer-2 data from the radio to the router, so
the router can calculate the metric. So I would consider the raw
metric data (and not some precalculated value) important.

> Not needed. Could be done with separate messages.
Not with my current implementation, because the database that stores
the metric values have only one validity time per set of metrics for a
neighbor.

> IP protocol would be OK also.

As long as it is packet and not stream based, it should work out fine.
IP, UDP, it doesn't matter that much.

> The DLEP filter in the radio is needed anyway, blocking multicast on RF-link.
I don't think this "bridging everything together" will work well in
all cases. Especially with IEE802.11

> and then. Could be empty "announcement" packet.

Hmm... I think just keep the linklocal multicast with the radio data
might be easier. The radio can start sending out unicasts if necessary
in addition to this.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Sun, 22 Apr 2012 13:51:46 +0200

> Then, Msg_3 (and Msg_2) are send.

Yes, thats how it works at the moment... Msg_1 is just "I am here and
that is the MAC address of my radio".

> assume DLEP radio has any idea on L3-stuff on other sides.

At the moment my DLEP implementation does transport any layer-2
information about the radio to the router, because in my current
usecase the DLEP-Server (the radio) will not even have an IP set for
the radio interface. It will just bridge it on layer-2 to the
ethernet.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 14:14:27 +0200

> the radio interface. It will just bridge it on layer-2 to the
DLEP describes some kind of address resolving for far-end neighbors.
This overlaps with hello & arp/ndp. You do not implement such, and let
the router take care of L3. Better approach.

Teco

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 14:30:13 +0200

> IEEE802.11 radios, you will run into problems because of the mac
It is solved in 802.11S. Or IBSS with 4-address mode. Vanilla 802.11 
stack needs some kind of repeater, as you mentioned some time ago.

> radio" is a bad idea in a lot of cases.
Not every user will write it's own metric calculation routine. How is it 
guaranteed any DLEP implementation is interoperable? We need a minimum
set that MUST be implemented.

> metric data (and not some precalculated value) important.
Yes, raw is important. Supporting incompatible raw is also required.

> the metric values have only one validity time per set of metrics for a
Your dlep receiver would support it. Why not?

> all cases. Especially with IEE802.11
It is up to the radio to provide transparent L2 transport. It can be done with
802.11 on multiple special ways, as you and I know.

> might be easier. The radio can start sending out unicasts if necessary
Then router gets data twice?

I don't see much benefits of getting rid of multicast, other than an implicit 
filter the DLEP data is not send over RF. But the filter is needed anyway.

Link-local multicast is not enough for the filter. Is needs to be L2 link-local.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sun, 22 Apr 2012 15:37:30 +0200

> stack needs some kind of repeater, as you mentioned some time ago.

802.11s is a layer-2 mesh with a 6-mac address format. I think using
DLEP on a full layer-2 mesh is even more complex, lets get the basics
right first.

> set that MUST be implemented.

I don't think a dimensionless metric is a useful "minimum". Without
knowing what the radio means with this metric, it would just lead to
crazy results.

> Yes, raw is important. Supporting incompatible raw is also required.

Yes, fortunately a standard RFC5444 reader should be able to skip
unknown data (metric TLVs) easily.

> Your dlep receiver would support it. Why not?

I have split my implementation work into several parts.

I have a "layer 2 database", both in the radio and the router. I use
the DLEP-server and DLEP-client code to mirror this database from the
radio to the router. And I have NL80211-listener code that can fill
the database by using tha mac80211 linux code.

The layer-2 db on both radio and router side are API-compatible. Which
makes it easily to switch from DLEP-using router to directly reading
one. And this database only has a single VTime-field for each SET of
layer-2 data.

> 802.11 on multiple special ways, as you and I know.
Still I see no advantage by unicast over a linklocal multicast. The
second one should be interface specific too.

> Link-local multicast is not enough for the filter. Is needs to be L2 link-local.

Linklocal multicast (at least for IPv6) is always interface specific.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 19:41:47 +0200

> Linklocal multicast (at least for IPv6) is always interface specific.

You may miss my point. Assume a flat ethernet (no VLANs), and radio and router
use link multicast. Radio is a bridge. Bridges do flood broadcast / multicast
(OK, there are L2 multicast mechanisms that snoop IGMP/MLP). How can we make
sure the DLEP traffic is not send over RF? How can snoop work, when both
ends use same DLEP multicast address?

Simple example: Ethernet-SDSL bridge (switched 100Mbps RJ45s and couple of jacks
for phone wire). Now, due to DLEP, this bridge needs some multicast filter. Or 
additional management VLANs, only for DLEP (there would be a normal management 
VLAN that spans both ends). The special DLEP VLANs must be blocked on the SDSL 
ports.
Example with radios would be similar to the simple VLAN bridge.

Teco

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 19:49:11 +0200

> second one should be interface specific too.
In a more complex link between radio and router, unicast takes single path, where
multicast is flooded.
Unicast doesn't touch the multicast filter that much (see other mail) and
often has better performance.
The multicast filter is needed for announcement packets, these must be multicast 
and must be kept local. So it cannot be unicast-only.

Multicast-only is straightforward and often without negative effects. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 20:08:04 +0200

> DLEP on a full layer-2 mesh is even more complex, lets get the basics
4 of the 6 addresses of 802.11s are out of scope of DLEP. Only the SA and 
DA are of interest. 802.11s has metrics for each DA it knows about.
It is cleaner than IBSS & bridging.

WiFi Direct is a bit of a problem. I don't think the non access points
has knowledge of link quality for the access point with the other nodes.
In this scenario, the 802.11 stack provides wrong info. 
Same for normal BSS/EBSS stations and stations attached to 802.11s.

I don't say I like 802.11s meshing in combination with a MANET protocol.
It just has capabilities to provide needed info and has no problems with 
bridging.

Teco

---

From: Teco Boot <[email-masked]>
Date: Sun, 22 Apr 2012 21:07:59 +0200

Op 22 apr. 2012, om 15:37 heeft Henning Rogge het volgende geschreven:

>>> ...    I don't even think the "dimensionless"
Owners of incompatible standards_based gear will get crazy.

What is the minimum set of TLVs that MUST be implemented? Negotiations?
Our task as IETF is make gear compatible.
(dlep-02: only MDR is mandatory) 

>>> other DLEP metrics become "infinite" too.
Is this a special case?

I say: we don't need neighbor_up messages. Any link metric for a new
neighbor, except "infinite metrics", is an up trigger. The MANET protocol
would start detecting bi-directionality. 

Neighbor_down cannot be detected easily (as old-days carrier-detect), as 
we are facing frame based media access. Due to movements, signals fade
away and DLEP link metrics provide this to the router. The router on its 
turn prefer an alternate path, if available.
A radio may implement an I_will_shutdown message, for local and remote 
radio. Some max_value would do, or RLQ=0 &| CDR=0. Similar for link layer
notifications.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Mon, 23 Apr 2012 10:42:03 +0200

On 04/22/2012 09:07 PM, Teco Boot wrote:
> radio. Some max_value would do, or RLQ=0&| CDR=0. Similar for link layer
> notifications.

Maybe we can just reuse Address TLVs from RFC 6130 (NHDP) and OLSRv2, in 
addition to the VALIDITY_TIME tlv from RFC 5497 (Time-TLV)?

In NHDP we have the LINK_STATUS Address TLV, which can transport the 
values "lost", "symmetric" or "heard". I think that might be useful here 
to encode the status of a neighbor (mostly the 'lost' and 'heard' value, 
unless the radio checks bi-directional connectivity).

In OLSRv2 we will have the LINK_METRIC Address TLV, which could be used 
for transporting a dimensionless metric value. This would allow to 
specify if the metric is directional or bi-directional too.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 23 Apr 2012 08:57:29 +0000

Teco
> IMHO unneeded functions.

One man's unneeded function is another man's essential function. I think when there's a function one doesn't see a need for, it's time to ask why it's there before suggesting removing it.

---

From: Teco Boot <[email-masked]>
Date: Mon, 23 Apr 2012 12:36:27 +0200

> One man's unneeded function is another man's essential function. I think when there's a function one doesn't see a need for, it's time to ask why it's there before suggesting removing it.

I did not have any intention to remove functionality. I meant IETF has already protocols for functions DLEP also provides. We should try to use existing protocols as much as possible, before standardizing new ones. I suggested to split DLEP in what is needed and isn't in place (STD TRACK) and what can be done in some special cases (experimental). IMHO flow control and address resolving are unneeded and I asked why these are in DLEP. I did not get satisfying answers. 

Teco

---

From: Henning Rogge <[email-masked]>
Date: Mon, 23 Apr 2012 12:51:09 +0200

On 04/23/2012 12:36 PM, Teco Boot wrote:
>> One man's unneeded function is another man's essential function. I
>> think when there's a function one doesn't see a need for, it's time
>> to ask why it's there before suggesting removing it.
>
> I did not have any intention to remove functionality. I meant IETF
> has already protocols for functions DLEP also provides. We should try
> to use existing protocols as much as possible, before standardizing
> new ones. I suggested to split DLEP in what is needed and isn't in
> place (STD TRACK) and what can be done in some special cases
> (experimental). IMHO flow control and address resolving are unneeded
> and I asked why these are in DLEP. I did not get satisfying answers.

I think they are in DLEP because there are already quite a few IP 
capable radios who KNOW their own and their neighbors IP address because 
of their internal protocol.

If the radio has knowledge about this, it should be able to tell the 
router about it so the router can set the right IP on his local interface.

But the DLEP-Service (radio) should only report whats already known, it 
should not generate additional traffic.

Henning Rogge