Subject: [manet] DLEP and RFC 5444

From: Christopher Dearlove <[email-masked]>
Date: Thu, 29 Mar 2012 18:33:47 +0200

Having had a discussion about RFC 5444 and DLEP with Stan, in which I attempted to be neutral on the subject, here are some thoughts from that, which stray from neutrality at the end.

The underlying philosophy of 5444 is that here are some addresses, here is some data associated with those addresses. (There is also message level and packet level information.) Each piece of data is associated with one or more addresses. 5444 allows different ways of associating data with addresses. For even one type of data associated with one type of TLV, 5444 allows different ways of doing this. The most obvious are that if each address has a different value associated with it, then one multivalued TLV is good. If on the other hand one value is associated with multiple addresses, then a single value TLV is good. If you have a complicated mapping then you need way to pick what mix of TLVs to use. This can be by a simple decision (e.g. always use one multivalued TLV, repeating a value if needed) or by a more complicated heuristic. You can define this on your protocol (a protocol can rule parts of 5444 out of bounds - but had better specify what to do when you receive a message that doesn't conform) or your implementation can be constrained. Or you can make your decision part of the quality of your implementation.

But all that assumes that you have addresses in address blocks. Which is the best place for them to be. But unfortunately DLEP wants to send addresses of different types, in particular of different sizes. 5444 does not support that. I can see three options that can handle this.

The first would be to update 5444 to a 5444bis. Technically, not hard. But there are real issues. For example 6130 (NHDP) says it uses 5444. Not 5444bis. Issuing a 5444bis on it's own wouldn't do that. And as someonw in the middle of trying to get OLSRv2, based on 5444, out, I'd rather not go down this route.

The second and third say let's use 5444 as-is, use a maximal length address in it, specifically 16 octet addresses, and embed all shorter addresses in those. The options differ in their embedding.

The second option is to embed addresses "properly". There are well-defined ways to embed MAC addresses and IPv4 addresses in IPv6 addresses. I think (I don't have the relevant RFCs in front of me - I'm typing this on an iPhone) these are both using the lowest 7 or 4 octets of the IPv6 address. (If not there are some small changes to make, but the principles are the same.) Now the 5444 address block format allows you to send the common 9 or 12 octets once, and then just send the changing octets.

The third option says, let's not worry about "proper" embedding, but rather let's use the most significant 7 or 4 octets, and set the rest to zero. This is because zero-valued tail octets can be omitted.

Now in either of these cases it's up to the protocol using either of these options to indicate how to recognise the address types it uses. For example using the third option it could say anything that has that format is a MAC or IPv4 address.

Normally you would then use a separate address block for each address type, because only in that way can you get the savings noted above. But there could be a hard case if you want to associate the same piece of data with different types of address. That means either having to repeat the TLV for each address block, or some other (probably ugly, I have some ideas) solution.

So is this a good idea for DLEP?  I think yes, subject to some details of understanding I haven't yet done. Then we can have specific TLVs for specific pieces of data. The granularity is still open (one metric TLV with several pieces of data, or one TLV per piece of data) as is whether to be parsimonious in acquiring TLVs, or to use the per-message TLV block, which  is much less (probably in practice not) limited.

An advantage of using 5444 as presented above is that it is possible (I know people who have done it, in different ways) to write generic 5444 software that parses a message and presents some sort of mapping of addresses to associated data (or that data of a certain type is not associated).

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 29 Mar 2012 11:51:10 -0500

Chris/All - 
 
At first blush, I don't agree with the notion of using the address blocks, and (as I understand it) by extension, Henning's proposed changes. Here's why: 
 
What I got from the discussion with Chris is that RFC 5444 inherently uses the notion of "Here's an address, or a block of addresses - and here's some information about the mentioned address(es)". That paradigm fits reasonably well with the notion of a DLEP "neighbor", but doesn't fit so well (IMO) when considering communication with the radio/modem itself. Also, unless some sort of "bending/twisting" of RFC 5444 address blocks is envisioned, it would mean that DLEP messages about an address (or addresses) would potentially need to be repeated "N" times - once for an IPv4 address(es), again for the IPv6 address(es), a third time for the associated MAC, etc.  And having said that, I wouldn't have the foggiest notion of how to express a "radio-wide" metric, since it potentially applies to several (possibly non-contiguous) addresses. 
 
Another thing I got from today's discussion was the notion of "flattening" the TLV's used - by that, I mean (for example) creating a single "DLEP Metric" TLV, consisting of all of the atomic values (e.g. bandwidth, latency, etc etc) all nicely laid out. However, that eliminates the current level of flexibility we have with the existing scheme - if a radio vendor/router vendor wants to add some new metric, it can be done fairly easily with a new sub-TLV in the experimental space. Existing implementations aren't broken, as they (if they're adhering to the spec) parse and drop those TLV's. So, adding the next new whiz-bang metric is relatively straightforward. 
 
So, perhaps I'm still not understanding the scope of the issue properly, but having had the benefit of today's discussion, the change to DLEP would be radical, would be less efficient than the existing implementation, and wouldn't be as flexible. A large cost just to shoe-horn it into existing address blocks. 
 
Regards,
Stan

________________________________

From: Christopher Dearlove [mailto:[email-masked]]
Sent: Thu 3/29/2012 12:33 PM
To: [email-masked]; Christopher Dearlove; Stan Ratliff (sratliff)
Subject: DLEP and RFC 5444

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 30 Mar 2012 09:01:08 +0200

Stan, Chris,

On Thu, Mar 29, 2012 at 6:51 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> Chris/All -
>
> At first blush, I don't agree with the notion of using the address blocks,
> and (as I understand it) by extension, Henning's proposed changes. Here's
> why:
>
> What I got from the discussion with Chris is that RFC 5444 inherently uses
> the notion of "Here's an address, or a block of addresses - and here's some
> information about the mentioned address(es)". That paradigm fits reasonably
> well with the notion of a DLEP "neighbor", but doesn't fit so well (IMO)
> when considering communication with the radio/modem itself. Also, unless
> some sort of "bending/twisting" of RFC 5444 address blocks is envisioned, it
> would mean that DLEP messages about an address (or addresses) would
> potentially need to be repeated "N" times - once for an IPv4 address(es),
> again for the IPv6 address(es), a third time for the associated MAC, etc.
> And having said that, I wouldn't have the foggiest notion of how to express
> a "radio-wide" metric, since it potentially applies to several (possibly
> non-contiguous) addresses.

I would be very much in favor of using RFC5444 address blocks if we
find a good way of integrating different address lengths in a message.
The suggestion Chris (and I think Henning) made sounds good (using 16
octet address length and padding addresses). As Stan said yesterday,
if the WG is going to bring forward this "extension" to RFC5444, it
should be outside of DLEP, as this may be useful for other drafts.
I agree with Stan's observation that it would be undesirable to repeat
the DLEP messages (or message TLVs, as I would call them) for each
address type. Wouldn't it be possible to specify an "ADDRESSLENGTH
TLV" and associate that with the different addresses of an address
block? It could be associated with the different types of addresses to
determine the length of each address. Admittedly, that would make
address compression difficult, but depending on how many DLEP message
TLVs are attached to the different messages, that may still lead to
fewer bits on the channel than repeating the DLEP message TLVs for
each address block.

>
> Another thing I got from today's discussion was the notion of "flattening"
> the TLV's used - by that, I mean (for example) creating a single "DLEP
> Metric" TLV, consisting of all of the atomic values (e.g. bandwidth,
> latency, etc etc) all nicely laid out.

I must have missed that this was suggested. I don't think this would
be a good idea (for the reasons Stan mentions below). But I am also
not a big fan of the sub-TLVs, as I have expressed in my longer review
of DLEP. We have enough message-specific TLVs, which could be used for
a DLEP message.

Best regards
Ulrich

> However, that eliminates the current
> level of flexibility we have with the existing scheme - if a radio
> vendor/router vendor wants to add some new metric, it can be done fairly
> easily with a new sub-TLV in the experimental space. Existing
> implementations aren't broken, as they (if they're adhering to the spec)
> parse and drop those TLV's. So, adding the next new whiz-bang metric is
> relatively straightforward.
>
> So, perhaps I'm still not understanding the scope of the issue properly, but
> having had the benefit of today's discussion, the change to DLEP would be
> radical, would be less efficient than the existing implementation, and
> wouldn't be as flexible. A large cost just to shoe-horn it into existing
> address blocks.
>
> Regards,
> Stan
>
> Having had a discussion about RFC 5444 and DLEP with Stan, in which I
> attempted to be neutral on the subject, here are some thoughts from that,
> which stray from neutrality at the end.
>
> The underlying philosophy of 5444 is that here are some addresses, here is
> some data associated with those addresses. (There is also message level and
> packet level information.) Each piece of data is associated with one or more
> addresses. 5444 allows different ways of associating data with addresses.
> For even one type of data associated with one type of TLV, 5444 allows
> different ways of doing this. The most obvious are that if each address has
> a different value associated with it, then one multivalued TLV is good. If
> on the other hand one value is associated with multiple addresses, then a
> single value TLV is good. If you have a complicated mapping then you need
> way to pick what mix of TLVs to use. This can be by a simple decision (e.g.
> always use one multivalued TLV, repeating a value if needed) or by a more
> complicated heuristic. You can define this on your protocol (a protocol can
> rule parts of 5444 out of bounds - but had better specify what to do when
> you receive a message that doesn't conform) or your implementation can be
> constrained. Or you can make your decision part of the quality of your
> implementation.
>
>
> But all that assumes that you have addresses in address blocks. Which is the
> best place for them to be. But unfortunately DLEP wants to send addresses of
> different types, in particular of different sizes. 5444 does not support
> that. I can see three options that can handle this.
>
> The first would be to update 5444 to a 5444bis. Technically, not hard. But
> there are real issues. For example 6130 (NHDP) says it uses 5444. Not
> 5444bis. Issuing a 5444bis on it's own wouldn't do that. And as someonw in
> the middle of trying to get OLSRv2, based on 5444, out, I'd rather not go
> down this route.
>
> The second and third say let's use 5444 as-is, use a maximal length address
> in it, specifically 16 octet addresses, and embed all shorter addresses in
> those. The options differ in their embedding.
>
> The second option is to embed addresses "properly". There are well-defined
> ways to embed MAC addresses and IPv4 addresses in IPv6 addresses. I think (I
> don't have the relevant RFCs in front of me - I'm typing this on an iPhone)
> these are both using the lowest 7 or 4 octets of the IPv6 address. (If not
> there are some small changes to make, but the principles are the same.) Now
> the 5444 address block format allows you to send the common 9 or 12 octets
> once, and then just send the changing octets.
>
> The third option says, let's not worry about "proper" embedding, but rather
> let's use the most significant 7 or 4 octets, and set the rest to zero. This
> is because zero-valued tail octets can be omitted.
>
> Now in either of these cases it's up to the protocol using either of these
> options to indicate how to recognise the address types it uses. For example
> using the third option it could say anything that has that format is a MAC
> or IPv4 address.
>
> Normally you would then use a separate address block for each address type,
> because only in that way can you get the savings noted above. But there
> could be a hard case if you want to associate the same piece of data with
> different types of address. That means either having to repeat the TLV for
> each address block, or some other (probably ugly, I have some ideas)
> solution.
>
> So is this a good idea for DLEP?  I think yes, subject to some details of
> understanding I haven't yet done. Then we can have specific TLVs for
> specific pieces of data. The granularity is still open (one metric TLV with
> several pieces of data, or one TLV per piece of data) as is whether to be
> parsimonious in acquiring TLVs, or to use the per-message TLV block, which
> is much less (probably in practice not) limited.
>
> An advantage of using 5444 as presented above is that it is possible (I know
> people who have done it, in different ways) to write generic 5444 software
> that parses a message and presents some sort of mapping of addresses to
> associated data (or that data of a certain type is not associated).
>
> --
> Christopher Dearlove
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 30 Mar 2012 10:26:45 +0200

I think mixing the different types if address in one block and not being able to compress is not good.

I think that Stan doesn't like what he describes as "flattening". OK, it was one idea. Separate TLVs (with different type extensions from a single TLV type) for each metric type is the more obvious option; I think we need an example to see what the relative costs of each are.

An issue I see is if we have multiple addresses of different types associated together and with the same data (metrics etc.) Then simply associating the same data with each by putting the addresses in different blocks and repeating metrics etc. is not good (repeated data and don't have the direct address to address association). Then I can see three approaches, depending on details (and there could be others).

- Use one of the addresses in the address block, put others in a TLV (one that just has the address). Works best if one address type is always present and is the one used for the address block, but can work in any case.

- Create an "association" TLV. If addresses A and B of different types, in different address blocks, are associated, pick a number, valid only for this message, and use the association TLV to give each that number. Associate other data with just one of those addresses.

- If all entities (neighbors) have the same set of addresses, then as above except without the association TLV, just associate by order in address blocks.

I dislike at least some aspect of each of these, so I don't think it's a simple thing to say whether an how to change. As I previously said, I think what we need is to come up with a good example, then represent it various ways and see which seems to have the best balance of efficiency, ease of use, fit to 5444, and whatever other criteria seem suitable.

---

From: Teco Boot <[email-masked]>
Date: Fri, 30 Mar 2012 10:37:34 +0200

Op 29 mrt. 2012, om 18:33 heeft Christopher Dearlove het volgende geschreven:

> The underlying philosophy of 5444 is that here are some addresses, here is some data associated with those addresses. (There is also message level and packet level information.) Each piece of data is associated with one or more addresses. 5444 allows different ways of associating data with addresses. For even one type of data associated with one type of TLV, 5444 allows different ways of doing this. The most obvious are that if each address has a different value associated with it, then one multivalued TLV is good. If on the other hand one value is associated with multiple addresses, then a single value TLV is good. If you have a complicated mapping then you need way to pick what mix of TLVs to use. This can be by a simple decision (e.g. always use one multivalued TLV, repeating a value if needed) or by a more complicated heuristic. You can define this on your protocol (a protocol can rule parts of 5444 out of bounds - but had better specify what to do when you receive a mess
> age that doesn't conform) or your implementation can be constrained. Or you can make your decision part of the quality of your implementation.
> 

This needs more thoughts. DLEP provides info for neighbor nodes. The IDs of those are L2 addresses (DLEP builds on L2 radio devices). Mostly used TLVs for the L2 addresses would be the link metrics. L3 address exchange is something that is not needed in many cases (we have ARP/ND for that, or snoop MANET packets).

What would be needed is a DLEP message, with msg-orig-addr being an IPv4/IPv4/other address and an L2 address block. Using an L2 msg-orig-addr  for DLEP would work with current 5444, I think. This limits DLEP to link-local. Seems to fit in most cases, if not all.

Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 30 Mar 2012 10:43:37 +0200

Hi Chris,

> I think mixing the different types if address in one block and not being able to compress is not good.

I agree it's not great.

> I think that Stan doesn't like what he describes as "flattening". OK, it was one idea. Separate TLVs (with different type extensions from a single TLV type) for each metric type is the more obvious option;

Agree.

> I think we need an example to see what the relative costs of each are.

Yes, that could be helpful.

> - Use one of the addresses in the address block, put others in a TLV (one that just has the address). Works best if one address type is always present and is the one used for the address block, but…

Yes, not ideal, probably depends on what typical deployments would put
in as addresses. Would be very good to see examples from "the real
world".

> - Create an "association" TLV. If addresses A and B of different types, in different address blocks, are associated, pick a number, valid only for this message, and use the association TLV to give…

Yeah, not ideal either, makes it complicated to parse.

> I dislike at least some aspect of each of these, so I don't think it's a simple thing to say whether an how to change. As I previously said, I think what we need is to come up with a good example,…

Yes

Regards
Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Fri, 30 Mar 2012 12:48:00 +0300

> I think mixing the different types if address in one block and not being able to compress is not good.

You just have to calculate the tradeof between using two address
blocks (and getting more overhead because you cannot share TLVs
between them) and one address block and loose bytes in compression.
But it can be done.

> I think that Stan doesn't like what he describes as "flattening". OK, it was one idea. Separate TLVs (with different type extensions from a single TLV type) for each metric type is the more obvious…
Putting all metrics into a single TLV is a BAD decision because it
prevents you from skipping a metric value (maybe your radio does not
support it) or adding new metrics.

> An issue I see is if we have multiple addresses of different types associated together and with the same data (metrics etc.) Then simply associating the same data with each by putting the addresses…

I think this is not a problem with DLEP, because (as far as I
understood the current DLEP draft), you just put a single neighbor
into each DLEP message. So all addresses in all blocks will belong to
the same neighbor.

> - Use one of the addresses in the address block, put others in a TLV (one that just has the address). Works best if one address type is always present and is the one used for the address block, but…
I have to admit I do not really like this solution, because it blocks
address compression.

> - Create an "association" TLV. If addresses A and B of different types, in different address blocks, are associated, pick a number, valid only for this message, and use the association TLV to give…

Yes, using an "association TLV" (which can be shared over the whole
group) might be a way, but its not really a nice solution.

> I dislike at least some aspect of each of these, so I don't think it's a simple thing to say whether an how to change. As I previously said, I think what we need is to come up with a good example,…

If we define some way for address grouping, it might even be useful
for OLSRv2 (not the current draft/RFC, but a transparent extension
later!), because it would allow a node to see which addresses of a TC
belongs to the same node, which helps to map the topology of the
protocol.

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: Fri, 30 Mar 2012 11:11:25 +0100

Might I suggest that another way to use address-block TLVs and DLEP
messages is to take a closer look at the semantics of DLEP messages.
There are 2 classes of messages in DLEP: the Peer* messages, that
concern the association between a router and its peered radio, and the
Neighbour* messages that discuss a remote neighbour.

All the neighbour* messages have a requirement to include a MAC address
sub-TLV to distinguish the neighbour, the Peer* messages do not have an
implicit association with an address, just the DLEP session.

Would it over-complicate the protocol to map the Neighbour* messages to
Address-block TLVs, using msg-addr-length=(6-1) and storing the MAC
there, and keep the Peer* messages as RFC5444 Message-block TLVs?

>From my own implementations of draft-00, all neighbour information needs
to be internally indexed by MAC address, and all other information can
be maintained on a per-session basis.

Rick Taylor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Rogge
Sent: 30 March 2012 10:48
To: Christopher Dearlove
Cc: Christopher Dearlove; [email-masked]; Stan Ratliff (sratliff)
Subject: Re: [manet] DLEP and RFC 5444

> I think that Stan doesn't like what he describes as "flattening". OK,
it was one idea. Separate TLVs (with different type extensions from a
single TLV type) for each metric type is the more obvious option; I
think we need an example to see what the relative costs of each are.
Putting all metrics into a single TLV is a BAD decision because it
prevents you from skipping a metric value (maybe your radio does not
support it) or adding new metrics.

> An issue I see is if we have multiple addresses of different types
associated together and with the same data (metrics etc.) Then simply
associating the same data with each by putting the addresses in
different blocks and repeating metrics etc. is not good (repeated data
and don't have the direct address to address association). Then I can
see three approaches, depending on details (and there could be others).

> - Use one of the addresses in the address block, put others in a TLV
(one that just has the address). Works best if one address type is
always present and is the one used for the address block, but can work
in any case.
I have to admit I do not really like this solution, because it blocks
address compression.

> - Create an "association" TLV. If addresses A and B of different
types, in different address blocks, are associated, pick a number, valid
only for this message, and use the association TLV to give each that
number. Associate other data with just one of those addresses.

> - If all entities (neighbors) have the same set of addresses, then as
above except without the association TLV, just associate by order in
address blocks.
>
> I dislike at least some aspect of each of these, so I don't think it's
a simple thing to say whether an how to change. As I previously said, I
think what we need is to come up with a good example, then represent it
various ways and see which seems to have the best balance of efficiency,
ease of use, fit to 5444, and whatever other criteria seem suitable.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 30 Mar 2012 16:44:23 +0200

Can you confirm that the neighbour* messages are the one send out 
most often, or that this has to be because it has the most updates?
This would justify your proposal.

Personally I prefer not to send the peer* messages at all and just
multicast the neighbor state, just like the hellos.

Teco

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 30 Mar 2012 16:12:47 +0100

Teco,

It's not that clear-cut.  The heartbeat messages between router and peer
(Peer*) messages are the most frequent, but are small.  The
NeighbourUpdate messages are the next most common (unless the net is
changing faster than the heartbeat interval) and they have a larger
payload (should be all the changed metrics, but the devices we are using
send all metrics every time).

I can see your point about just multicasting Neighbour* messages, but
the Peer* messages are very useful when sent from router to radio, e.g.
LinkCharacteristics, or when the local radio wants to inform the peered
router of global metric changes, so I am against removing that local
association (and some want to use it for credit-windowing).

Rick Taylor

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 30 March 2012 15:44
To: Rick Taylor
Cc: Henning Rogge; Christopher Dearlove; [email-masked]; Stan Ratliff
(sratliff)

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sat, 31 Mar 2012 11:49:00 +0300

> association (and some want to use it for credit-windowing).

The peer offer/ack can also be used to automatically detect and
configure a radio plugged into the corresponding switch. It might be
interesting to add a VLAN TLV to choose the VLAN Tag the radio is
bridged to.

Henning Rogge