Subject: [manet] DLEP draft 5 comments

From: "Viberg, Neil" <[email-masked]>
Date: Tue, 29 Jul 2014 12:51:36 -0600

Folks,

I've been working on an implementation of DLEP for a company
demonstration. As a result of that work I have a few comments on Draft
5. These are personal views, not company views.

My overwhelming impression is very positive. This protocol will work
nicely for us and provides great value. Nice job.

The demo DLEP uses all of the mandatory messages and recognizes but
ignores the optional messages. All of the data items in sections 9.1 to
9.22 except 9.19 are implemented. Only IPv4 sessions are implemented.
Section 4 and 10.4 restrictions on including/excluding metrics that were
not announced in a Peer Initialization are not implemented.

For the wire format I used (and modified) the RFC5444
construction/parsing code from the dlep_tools project that Cisco kindly
put on SourceForge. The packets are constructed as RFC5444 packets
without a sequence number, including the packet TLV block and containing
zero (0) messages. This is a valid RFC5444 packet format and, with the
exception of a little extra RFC5444 packet header overhead and an extra
flag byte for each TLV, matches the Draft 5 format quite closely. The
Signal TLV is implemented as an actual TLV.

Editorial comments are as follows:

1. Section 2 in the last paragraph has the phrase "running over the TCP
transport, utilizing a well-known TCP Port number." The use of the Peer
Offer message negates the need for a "well-known TCP Port number."  The
only well-known port number needs to be the one used for multicast
discovery messages.

2. Section 9 does not list the Identification TLV

3. Section 9 does not list the MAC Address TLV

4. Section 9.18 and 10.4 indicate that the Heartbeat Interval is
mandatory for the Peer Initialization message but Section 7 does not.

5. Section 9.18 indicates that the receipt of any DLEP message within
two Heartbeat Intervals prevents a timeout but the description of the
value (below the figure) indicates that the Interval is the time between
heartbeat messages. Maybe "Interval, in seconds, since the last
transmitted DLEP message until a heartbeat message is transmitted" would
be more accurate. Because the interval is also part of the receive
timeout, a phrase about timing out if a DLEP message from the peer is
not received within 2 x Interval seconds is appropriate.

6. The Neighbor down ACK timer is mentioned in Section 9 but nowhere
else.

7. The Link Characteristics ACK Timer is mentioned in the table of
contents, Section 9, Section 9.19 and Section 12.4 but not in the Peer
Initialization Message description in Section 10.4.

8. Section 9.15 indicates that the Relative Link Quality (Receive) is a
MANDATORY data item and then starts the second sentence with "If
supported". 

9. Section 9.17 doesn't specify the Status TLV as MANDATORY for Peer
Initialization ACK.

10. The Signal "TLV" is not consistent with a standard TLV. Section 8
has the figure labeled "Signal TLV Type," a description that starts
"Signal - One of the DLEP Message TLV type values" and a 16-bit length.
Section 10 refers to "DLEP Signal Type value," followed by a one byte
"DLEP Message length" and a Section 10.1 title of "Signal TLV Values."
Neither example has a Type field and the length field is variable
length. Maybe the message format could be 2 bytes in network byte order
giving the message length followed by a standard TLV for the Signal
(i.e., a Type field for the Signal TLV, length of 1 byte and then the
Signal value). 

11. Section 10 references section 11.1 which does not exist.

12. Section 10.2 references the packet format described in section 11
but section 11 is security.

13. Section 10.2 indicates that there are no data item TLVs associated
with the Peer Discovery message but Section 7 and 9.1 indicate that the
DLEP Version data item is mandatory.

14. Section 10.3 indicates that Heartbeat Interval is a mandatory data
item for a Peer Offer message but Section 7 and 9.18 do not.

15. Section 12.1 indicates 15 signals but Section 12.3 lists 16.

16. Section 12.1 indicates 21 data items but there is at least 22 and
possibly more depending on whether Signal, Neighbor down ACK timer
and/or Link Characteristics ACK timer are valid data items.

Thoughts on the protocol:

1. Section 10.2 indicates that retry heuristics are optional. Since the
startup of a router DLEP process and modem DLEP processes are
independent it would seem that a retry is not an option but a
requirement. Furthermore, the retry should increase in length to reduce
processing load following startup. A truncated binary exponential
backoff, or something similar, could be suggested. I chose a truncated
Fibonacci sequence.

2. If the "server" behaviour was moved from the router to the modem then
one session setup step can be removed. For example, the modem multicasts
a discovery message that includes the identification, version, IP
address(es), port and a heartbeat interval for the modem. The router
responds with a TCP connect and the modem sends a Peer Initialization.

3. The timeout for the Peer Initialization message is not clearly
stated. If the router sends the heartbeat in the Peer Offer message then
it would be appropriate to use 2*that value for a timeout since the
modem's choice is not yet available. The timeout for the Peer
Initialization ACK should be 2*the modem's timeout choice.

4. The Termination message seems to be redundant when a timeout followed
by a TCP close() terminates the connection.

5. The ACK messages for mandatory signals do not seem worthwhile,
especially with a reliable transport protocol being used. The Peer
Initialization ACK and Termination ACK are not a problem because they
must be immediately acknowledged before continuing but all an ACK really
does is postpone a heartbeat message. All of the rest of the ACK
messages would have to be correlated with the message that they are
ACKing to have a purpose. There is no easy way to do the correlation
without sequence numbers **unless** it is assumed that all messages that
**can** be acknowledged are acknowledged. In that case a stop and wait
mechanism works but, again, doesn't seem to provide any value except
postponing heartbeats. If optional ACK messages are retained then it
would seem to make sense to require them to never be used or always be
used.

6. Peer Update and Link Characteristics Requests originating from the
router are anomalies to the normal message flow. By and large the DLEP
protocol is a modem to router information flow. These two particular
messages go against that. Since they are optional it is not a big deal
but they feel more appropriate to a management protocol. 

7. If RFC5444 construction/parsing code is widely available then simply
specifying DLEP messages as RFC5444 packets with a packet level TLV
block and zero RFC5444 messages may be less work and more attractive to
implementers.

8. It is not clear that the time scale of DLEP messages will match the
time scale needed for the use of the credit-windowing scheme.
Conceptually the credit window approach seems to be a better match for
packet forwarding time scales rather than the DLEP time scales,
especially with the use of TCP moving DLEP firmly up to the application
layer.

9. The draft does not clearly state the meaning of a MAC address and it
appears from traffic on the mailing list that many people assume an
Ethernet 48-bit MAC Address. Our understanding is that the MAC address
space is the modem's choice though a router clearly must be able to
discover its own MAC address. A further constraint is that MAC addresses
must be unique for the modem's RF domain that is represented in a single
DLEP session. One reason for the assumption of Ethernet MAC addresses
may stem from an absence of discussion about how to actually get
appropriately addressed packets to the modem. Everybody understands
Ethernet frames with MAC addresses but that may not be appropriate in
all cases and commenting that the traffic interface to the modem is
modem specific may clarify the situation.

10.  We assume that a system management interface to the modem is
required even though it is not mentioned in the specification. It may
reduce pressure to add "management" capabilities like "link
characteristic request" if it was mentioned that a system management
interface is assumed.

11. If a system management interface is assumed then one thought to help
out discovery would be to add some data items to the discovery message
like management IP address and port. A protocol indication may also be
useful.

Hope these comments are useful.

Cheers,

Neil Viberg

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.