Subject: [manet] First feedback on DLEP draft 2

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Mar 2012 10:51:39 +0100

Hello,

I am working on a DLEP prototype implementation at the moment, so I had 
to take a closer look to the current draft. While getting the necessary 
infrastructure in place to work with DLEP, I noticed one thing I would 
like to raise here on the list.

Is there a reason why DLEP invents its own variant of RFC5444 (the 
sub-tlvs)?

I cannot see why this is necessary. Instead of placing TLVs into the 
binary value of another TLV, we could just add them as message-TLVs too. 
This would allow DLEP to be read and generated by standard RFC 5444 
code. Each message would contain a single order (encoded with a 
mandatory 'order' message-TLV) and a series of additional message-TLVs 
which contain the parameters of the order.

Each order would be put into a message of its own, which still can be 
bundled into a single packet to keep orders attached as a 'block'.

I think this could simplify the DLEP draft quite a bit, because it make 
description of the binary structure unnecessary (its already described 
in RFC 5444) and would make it easier to mix DLEP messages with other 
protocols into the same RFC 5444 datastream if necessary.

I am still working through the existing metric TLVs of DLEP at the 
moment and look for other metric values that would be useful for DLEP, I 
will write another mail as soon as I have finished a full review of the 
draft.

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: Thu, 15 Mar 2012 12:55:01 -0400

Henning,

Glad to hear that you are developing an implementation!

The sub-TLV's were created based on earlier comments. The concern  
expressed at the time was that DLEP was going to consume an inordinate  
amount of the TLV space reserved in RFC5444. So in that respect, it  
feels like we're somewhat "between a rock and a hard place"... ;-)

Regards,
Stan

On Mar 15, 2012, at 5:51 AM, Henning Rogge wrote:

> Hello,
>
> I am working on a DLEP prototype implementation at the moment, so I  
> had to take a closer look to the current draft. While getting the  
> necessary infrastructure in place to work with DLEP, I noticed one  
> thing I would like to raise here on the list.
>
> binary value of another TLV, we could just add them as message-TLVs  
> too. This would allow DLEP to be read and generated by standard RFC  
> 5444 code. Each message would contain a single order (encoded with a  
> mandatory 'order' message-TLV) and a series of additional message- 
> TLVs which contain the parameters of the order.
>
> Each order would be put into a message of its own, which still can  
> be bundled into a single packet to keep orders attached as a 'block'.
>
> I think this could simplify the DLEP draft quite a bit, because it  
> make description of the binary structure unnecessary (its already  
> described in RFC 5444) and would make it easier to mix DLEP messages  
> with other protocols into the same RFC 5444 datastream if necessary.
>
> moment and look for other metric values that would be useful for  
> DLEP, I will write another mail as soon as I have finished a full  
> review of the draft.
>
> Henning Rogge
> -- 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Mar 2012 18:05:20 +0100

> Glad to hear that you are developing an implementation!
I am working on an EU project (http://confine-project.eu) which (among
other things) develops a virtualized container for doing research on
mesh nodes. And we would like to use DLEP to get layer-2 data from the
original WLAN cards into the container without giving them full
control over the card.

> The sub-TLV's were created based on earlier comments. The concern expressed
> at the time was that DLEP was going to consume an inordinate amount of the
> TLV space reserved in RFC5444. So in that respect, it feels like we're
> somewhat "between a rock and a hard place"... ;-)
Doesn't each RFC 5444 message have its own registry of Message-TLVs?

My idea was to add a "Order" TLV for the DLEP message so DLEP only
needs a single Message-Type. Inside this message type DLEP would have
256 TLVs of its own, each with 256 extension types.

And maybe even Addresses and Address TLVs might be useful for DLEP.

What do you think about me trying to implement DLEP with the existing
datatypes in this way, so you can have a look at the result and see if
the DLEP draft can be cleaned up this way?

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: Stan Ratliff <[email-masked]>
Date: Thu, 15 Mar 2012 14:06:34 -0400

On Mar 15, 2012, at 1:05 PM, Henning Rogge wrote:

>> expressed

Uhhh, perhaps I'm showing my RFC 5444 ignorance here, but I'm not sure  
what you mean. Can you explain?

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Mar 2012 19:26:10 +0100

RFC5444 has (according to my knowledge) three kinds of TLVs.

a) Packet TLVs
b) Message TLVs
c) Address TLVs

b) and c) are message ID specific.

so if DLEP has its own message type, it will contain its own registry
for Message and Address TLVs.

The HELLO message of NHDP has its own Message-TLV Registry... as will
the TC message of OLSRv2.

Henning Rogge

On Thu, Mar 15, 2012 at 19:06, Stan Ratliff <[email-masked]> wrote:
> Uhhh, perhaps I'm showing my RFC 5444 ignorance here, but I'm not sure what
> you mean. Can you explain?
>
> Regards,
> Stan
>
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 15 Mar 2012 14:37:37 -0400

> for Message and Address TLVs.

OK... that sounds like what we've already called for in DLEP-02. We  
call for the creation of DLEP-specific regstries... The notion of the  
sub-TLVs is that there is data that could/should be attached to  
multiple DLEP messages - for example, a Latency TLV. That could be  
expressed "modem-wide" (e.g. on a Peer Update message), or within the  
context of a specific partner (e.g. on a Neighbor Update message), or  
within the context of a request for resources (e.g. the Link  
Characteristics Request).... so if a data entity may be needed in the  
context of multiple messages, why not create such a sub-TLV to  
standardize the parsing of that information?

Regards,
Stan

>>>> at the time was that DLEP was going to consume an inordinate  
>>>> amount of
>>>> the

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Mar 2012 19:41:45 +0100

Because a Sub-TLV is some "special magic", not part of the RFC 5444 format...

And its not needed in my opinion. Just make the sub-tlvs a message TLV
and it works the same. I will try to make a more complete explanation
tomorrow at work to explain what I am talking about.

Henning Rogge

On Thu, Mar 15, 2012 at 19:37, Stan Ratliff <[email-masked]> wrote:
> OK... that sounds like what we've already called for in DLEP-02. We call for
> the creation of DLEP-specific regstries... The notion of the sub-TLVs is
> that there is data that could/should be attached to multiple DLEP messages -
> for example, a Latency TLV. That could be expressed "modem-wide" (e.g. on a
> Peer Update message), or within the context of a specific partner (e.g. on a
> Neighbor Update message), or within the context of a request for resources
> (e.g. the Link Characteristics Request).... so if a data entity may be
> needed in the context of multiple messages, why not create such a sub-TLV to

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 15 Mar 2012 14:59:50 -0400

> tomorrow at work to explain what I am talking about.

I'll be interested to see the more complete explanation. It sounds to  
me like you're talking about a "latency message", which would be  
unwieldy, IMO.

regards,
Stan

>> call for

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Mar 2012 11:42:56 -0000

Not having looked at the details recently, can you use the type extension field to use multiple type extensions from a single TLV type? There is also a message type specific set of TLVs, but there are drawbacks in their use, so I'm not suggesting them.

As I recall, what I was not entirely happy (again, I haven't checked the latest draft) with was the way addresses had to be packed into TLVs, rather than address blocks. That of course is due to a limitation of 5444 in that area. In defence of 5444 we had to make tradeoffs of simplicity, flexibility and extensibility, with pressures in all three directions. It would be possible to extend 5444 to add a new address block flag so that an address block could override the previously set address length. But that also has drawbacks, not least in leaving existing protocols that use 5444 unspecified as to how they would relate to such a hypothetical 5444bis. For that reason I'm not suggesting this. But if we'd had perfect foresight we might (there are arguments the other way too) have done this differently.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 Stan Ratliff
Sent: 15 March 2012 16:55
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] First feedback on DLEP draft 2

----------------------! 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.
--------------------------------------------------------

Henning,

Regards,
Stan

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Mar 2012 11:45:26 -0000

Not quite, Some message and address block TLVs are message type
specific, some are global. Note that all those defined so far (e.g. for
NHDP) are global.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Rogge
Sent: 15 March 2012 18:26
To: Stan Ratliff
Cc: [email-masked]
Subject: Re: [manet] First feedback on DLEP draft 2

a) Packet TLVs
b) Message TLVs
c) Address TLVs

Henning Rogge

On Thu, Mar 15, 2012 at 19:06, Stan Ratliff <[email-masked]> wrote:
>>> at the time was that DLEP was going to consume an inordinate amount
of
> Uhhh, perhaps I'm showing my RFC 5444 ignorance here, but I'm not sure
what

---

From: Henning Rogge <[email-masked]>
Date: Fri, 16 Mar 2012 13:25:56 +0100

Hello,

I will try to describe my concept of using DLEP without sub-TLVs. The 
mail became a little bit longer than I planned, but I wanted to explain 
the idea detailed enough.

First a few ideas I used in the following text:

- I would suggest using other words than server/client for the DLEP 
peers, because they are not intuitive to understand. My suggestion would 
be using DLEP-Interface for the former client and DLEP-Router for the 
former server. This will describe the default use case quite nicely.

- I am not sure how the Detached Peer Discovery should work, because 
DLEP does not specify communication between multiple DLEP-Interfaces.

- I skipped the Credit Grant scheme in this writeup, because I am not 
sure about its details.

- I also put together all ACK messages into a single Order type, which 
simplifies the protocol description.

- I think there are more options for simplification, but we can discuss 
them later.

DLEP Messages
=============

Each DLEP command/order is contained in a single RFC 5444 message with 
the message type "DLEP". Each of this messages MUST contain a message 
sequence number as specified in RFC 5444, Chapter 5.2. Message sequence 
numbers MUST be increased by each message of a peer and use the range of 
0-65535.

The address length of a DLEP message SHOULD be set to 16, to allow MAC, 
IPv4 and IPv6 addresses (and mixture of all three). If the DLEP peer 
does not support IPv6, is CAN set the address length to 6.

DLEP messages CAN contain one or more addresses of different types. Each 
of these addresses MUST contain a "Address Type" TLV, which describes 
the number of used bytes of the RFC 5444 address, beginning with the 
first byte. The rest of the address MUST be padded with zero bytes, 
which can be compressed with the ahaszerotail option of the address 
block (see RFC 5444, Section 5.3).

All custom DLEP message and address TLVs MUST be allocated from the 
Message-Type specific id range as defined in RFC 5444, chapter 6.1.

Each DLEP message MUST contain a "DLEP-Order" message-TLV, which 
extension type specifies the order the message.

Each DLEP message CAN contain an "Identification" message-TLV, if the 
underlaying transport mechanism does not allow DLEP to distinguish 
between endpoints of the router-interface communication.

Each DLEP message CAN contain a "Peer Type" message-TLV, which describes 
the peer of the DLEP communication with a human readable identification 
string.

If a DLEP message is a response to a former message of its peer, it MUST 
contain a "Reference" message-TLV, which describes the order of the 
referred message and its message sequence number.

DLEP Order: Peer Discovery
==========================

The Peer Discovery is sent by the DLEP-Interface to announce its 
existence to DLEP-Routers on its local interface.

It CAN announce the interval and validity time of the heartbeat of the 
Router.

Message TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Version TLV (optional)
- Peer Type TLV (optional)
- Heartbeat Interval TLV (optional)
- Heartbeat Validity Time TLV (optional)

DLEP Order: Peer Offer
======================

The Peer Offer is sent by the DLEP-Router to acknowledge the presence of 
the DLEP-Interface and setup a session with the Interface.

It CAN announce the interval and validity time of the heartbeat of the 
Router.

Message TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Version TLV (optional)
- Peer Type TLV (optional)
- Heartbeat Interval TLV (optional)
- Heartbeat Validity Time TLV (optional)

DLEP Order: Peer Termination
============================

The Peer Update CAN be sent by both the DLEP-Router and the 
DLEP-Interface to signal that it considers the session terminated.

If the session was terminated because of a message by the peer, this 
message should contain a Status TLV.

Message TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Status TLV (optional)

DLEP Order: Peer Update
=======================

The Peer Update CAN be sent by both the DLEP-Router and the 
DLEP-Interface to update some global data of the peer.

The Peer Update message of the DLEP-Router CAN contain addresses with 
address TLVs to reflect a local address change.

The Peer Update message of the DLEP-Interface CAN contain metric TLVs to 
reflect global changes of its connected network link.

Message TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Current Data Rate TLV (optional for DLEP-Interface)
- Maximum Data Rate TLV (optional for DLEP-Interface)
- Latency TLV (optional for DLEP-Interface)
- Expected Forwarding Time TLV (optional for DLEP-Interface)
- Resources TLV (optional for DLEP-Interface)
- Relative Link Quality TLV (optional for DLEP-Interface)

DLEP Order: Link Characteristics Request
========================================

The Link Characteristics Request is sent by the DLEP-Router to request a 
change in the Peers interface.

It CAN contain a single Address with the Address Type "MAC" to request a 
change of the network mac address of the peer.

Message TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Current Data Rate TLV (optional for DLEP-Interface)

DLEP Order: Heartbeat
=====================

The Heartbeat CAN be sent by both the DLEP-Router and the DLEP-Interface.

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- INTERVAL TIME TLV (optional, see RFC 5497, Section 9.2)
- VALIDITY_TIME TLV (optional, see RFC 5497, Section 9.2)

DLEP Order: Neighbor Up
=======================

The Neighbor Up is sent by the DLEP-Interface when a new neighbor is 
detected on the network.

It CAN contain multiple addresses which reflect the known addresses of 
the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least the MAC 
address of the neighbor.

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Maximum Data Rate TLV (optional)
- Current Data Rate TLV (optional)
- Latency TLV (optional)
- Expected Forwarding Time TLV (optional)
- Resources TLV (optional)
- Relative Link Quality TLV (optional)

DLEP Order: Neighbor Down
=========================

The Neighbor Down is sent by the DLEP-Interface when a new neighbor is 
detected on the network.

It MUST contain a single Address with the Address Type "MAC" with the 
network mac address of the former neighbor.

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Status TLV (optional)

DLEP Order: Neighbor Update
===========================

The Neighbor Update is sent by the DLEP-Interface when the link 
characteristics to the neighbor change.

It MUST contain a single Address with the Address Type "MAC" with the 
network mac address of the neighbor.

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Maximum Data Rate TLV (optional)
- Current Data Rate TLV (optional)
- Latency TLV (optional)
- Expected Forwarding Time TLV (optional)
- Resources TLV (optional)
- Relative Link Quality TLV (optional)

DLEP-Order: Neighbor Address Update
===================================

The Neighbor Address Update is sent by the DLEP-Interface when the known 
addresses of a neighbor change.

It CAN contain multiple addresses which reflect the known addresses of 
the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least the MAC 
address of the neighbor.

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)

DLEP-Order: Message ACK
=======================

The Message ACK is sent as a response to a received DLEP message (all 
orders except Peer Discovery, Heartbeat and Message ACK itself).

Message-TLVs:
- DLEP-Order TLV (mandatory)
- Identification TLV (optional)
- Status TLV (mandatory)
- Reference TLV (mandatory)

Necessary IANA Registrations
============================

Message Types
-------------

+-------+-------+--------------------------------+
| Name  | Type  | Description                    |
+-------+-------+--------------------------------+
| DLEP  |  TBD  | Interface-Router communication |
+-------+-------+--------------------------------+

Message-Type specific TLV Types
-------------------------------

+--------------------+-------+-------+--------+------------------------+
| Name               | Type  | Type- |  Value | Description            |
|                    |       |  Ext. | Length |                        |
+--------------------+-------+-------+--------+------------------------+
| Identification     |  TBD  |   0   |     8  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
| Version            |  TBD  |   0   |     4  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
| Peer Type          |  TBD  |   0   |  1-80  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
| DLEP-Order         |  TBD  |   0   |     0  | Peer Discovery         |
| DLEP-Order         |  TBD  |   1   |     0  | Peer Offer             |
| DLEP-Order         |  TBD  |   2   |     0  | Peer Termination       |
| DLEP-Order         |  TBD  |   3   |     0  | Peer Update            |
| DLEP-Order         |  TBD  |   4   |     0  | Link Characteristics   |
|                    |       |       |        | Request                |
| DLEP-Order         |  TBD  |   5   |     0  | Heartbeat              |
| DLEP-Order         |  TBD  |   6   |     0  | Neighbor Up            |
| DLEP-Order         |  TBD  |   7   |     0  | Neighbor Down          |
| DLEP-Order         |  TBD  |   8   |     0  | Neighbor Update        |
| DLEP-Order         |  TBD  |   9   |     0  | Neighbor Addr. Update  |
| DLEP-Order         |  TBD  |  10   |     0  | Message ACK            |
+--------------------+-------+-------+--------+------------------------+
| Version            |  TBD  |   0   |     2  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
| Status             |  TBD  |   0   |     1  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
| Reference          |  TBD  |   0   |     3  | Reference to a         |
|                    |       |       |        | different message.     |
|                    |       |       |        | The value contains     |
|                    |       |       |        | the order of the       |
|                    |       |       |        | original message and   |
|                    |       |       |        | its sequence number    |
+--------------------+-------+-------+--------+------------------------+
| Heartbeat Interval |  TDB  |   0   |     1  | Interval between       |
|                    |       |       |        | Heartbeats. Value see  |
|                    |       |       |        | RFC 5497, Section 6.1  |
+--------------------+-------+-------+--------+------------------------+
| Heartbeat Validity |  TBD  |   0   |     1  | Validity time of       |
|                    |       |       |        | Heartbeats. Value see  |
|                    |       |       |        | RFC 5497, Section 6.1  |
+--------------------+-------+-------+--------+------------------------+
|Maximum Data Rate   |  TBD  |   0   |     8  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
|Current Data Rate   |  TBD  |   0   |     8  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
|Exp. Forward Time   |  TBD  |   0   |     4  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
|Latency             |  TBD  |   0   |     2  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
|Resources           |  TBD  |   0   |     1  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+
|Relative Link Qual. |  TBD  |   0   |     1  | see Draft 2            |
+--------------------+-------+-------+--------+------------------------+

Message-Type specific Address Block TLV Types
---------------------------------------------

+--------------------+-------+-------+--------+------------------------+
| Name               | Type  | Type- |  Value | Description            |
|                    |       |  Ext. | Length |                        |
+--------------------+-------+-------+--------+------------------------+
| Address Type       |  TBD  |   0   |     0  | This is a 6 byte       |
|                    |       |       |        | MAC address            |
| Address Type       |  TBD  |   1   |     0  | This  is a 4 byte      |
|                    |       |       |        | IPv4 address           |
| Address Type       |  TBD  |   2   |     0  | This  is a 16 byte     |
|                    |       |       |        | IPv6 address           |
+--------------------+-------+-------+--------+------------------------+
| Address Operation  |  TBD  |   0   |     0  | New/existing address   |
| Address Operation  |  TBD  |   1   |     0  | Withdrawn address      |
+--------------------+-------+-------+--------+------------------------+

On 03/15/2012 07:59 PM, Stan Ratliff wrote:
> I'll be interested to see the more complete explanation. It sounds to me
> like you're talking about a "latency message", which would be unwieldy,
> IMO.
>
> regards,
> Stan

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 16 Mar 2012 10:17:47 -0400

Henning,

ACK. Give me a day or two to study.

Regards,
Stan

On Mar 16, 2012, at 8:25 AM, Henning Rogge wrote:

> Hello,
>
> I will try to describe my concept of using DLEP without sub-TLVs.  
> The mail became a little bit longer than I planned, but I wanted to  
> explain the idea detailed enough.
>
> peers, because they are not intuitive to understand. My suggestion  
> would be using DLEP-Interface for the former client and DLEP-Router  
> for the former server. This will describe the default use case quite  
> nicely.
>
> - I skipped the Credit Grant scheme in this writeup, because I am  
> not sure about its details.
>
> - I also put together all ACK messages into a single Order type,  
> which simplifies the protocol description.
>
> - I think there are more options for simplification, but we can  
> discuss them later.
>
>
> DLEP Messages
> =============
>
> Each DLEP command/order is contained in a single RFC 5444 message  
> with the message type "DLEP". Each of this messages MUST contain a  
> message sequence number as specified in RFC 5444, Chapter 5.2.  
> Message sequence numbers MUST be increased by each message of a peer  
> and use the range of 0-65535.
>
> The address length of a DLEP message SHOULD be set to 16, to allow  
> MAC, IPv4 and IPv6 addresses (and mixture of all three). If the DLEP  
> peer does not support IPv6, is CAN set the address length to 6.
>
> DLEP messages CAN contain one or more addresses of different types.  
> Each of these addresses MUST contain a "Address Type" TLV, which  
> describes the number of used bytes of the RFC 5444 address,  
> beginning with the first byte. The rest of the address MUST be  
> padded with zero bytes, which can be compressed with the  
> ahaszerotail option of the address block (see RFC 5444, Section 5.3).
>
> Each DLEP message CAN contain an "Identification" message-TLV, if  
> the underlaying transport mechanism does not allow DLEP to  
> distinguish between endpoints of the router-interface communication.
>
> Each DLEP message CAN contain a "Peer Type" message-TLV, which  
> describes the peer of the DLEP communication with a human readable  
> identification string.
>
> If a DLEP message is a response to a former message of its peer, it  
> MUST contain a "Reference" message-TLV, which describes the order of  
> the referred message and its message sequence number.
>
>
>
>
> It CAN announce the interval and validity time of the heartbeat of  
> the Router.
>
> Message TLVs:
> The Peer Offer is sent by the DLEP-Router to acknowledge the  
> presence of the DLEP-Interface and setup a session with the Interface.
>
> It CAN announce the interval and validity time of the heartbeat of  
> the Router.
>
> Message TLVs:
> The Peer Update CAN be sent by both the DLEP-Router and the DLEP- 
> Interface to signal that it considers the session terminated.
>
> The Peer Update CAN be sent by both the DLEP-Router and the DLEP- 
> Interface to update some global data of the peer.
>
> The Peer Update message of the DLEP-Router CAN contain addresses  
> with address TLVs to reflect a local address change.
>
> The Peer Update message of the DLEP-Interface CAN contain metric  
> TLVs to reflect global changes of its connected network link.
>
> Message TLVs:
> The Link Characteristics Request is sent by the DLEP-Router to  
> request a change in the Peers interface.
>
> It CAN contain a single Address with the Address Type "MAC" to  
> request a change of the network mac address of the peer.
>
> Message TLVs:
> It CAN contain multiple addresses which reflect the known addresses  
> of the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least  
> the MAC address of the neighbor.
>
> Message-TLVs:
> The Neighbor Down is sent by the DLEP-Interface when a new neighbor  
> is detected on the network.
>
> It MUST contain a single Address with the Address Type "MAC" with  
> the network mac address of the former neighbor.
>
> Message-TLVs:
> It MUST contain a single Address with the Address Type "MAC" with  
> the network mac address of the neighbor.
>
> Message-TLVs:
> The Neighbor Address Update is sent by the DLEP-Interface when the  
> known addresses of a neighbor change.
>
> It CAN contain multiple addresses which reflect the known addresses  
> of the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least  
> the MAC address of the neighbor.
>
> Message-TLVs:
> The Message ACK is sent as a response to a received DLEP message  
> (all orders except Peer Discovery, Heartbeat and Message ACK itself).
>
> Message-TLVs:
> |                    |       |  Ext. | Length  
> |                        |
> |                    |       |       |        |  
> Request                |
> |                    |       |  Ext. | Length  
> |                        |
> |                    |       |       |        | MAC  
> address            |
> |                    |       |       |        | IPv4  
> address           |
> |                    |       |       |        | IPv6  
> address           |