Subject: [manet-dlep-rg] FW: DLEP message classification

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 3 Sep 2013 15:58:17 +0000

Just a repost of my thoughts about DLEP message classification and reliability...

Rick Taylor

-----Original Message-----
From: Taylor, Rick
Sent: 12 August 2013 12:24
To: [email-masked]
Subject: DLEP message classification

As a clarification from those who haven't read a DLEP draft for a while, DLEP protocol messages can be split into the following classes:

1) Discovery messages.
2) Control messages.
3) Event messages.
4) Status messages.

It must be remembered that NONE of these messages travel over the radio medium, the DLEP protocol operates between a radio and a directly connected radio.  If a radio needs to communicate with another device in order to satisfy some part of the DLEP protocol, then it is the radio's business how that occurs.

Discovery messages are broadcast from a radio to discover an attached router, via a link-local multicast/broadcast message.  UDP is proposed as a default protocol.  These messages are unreliable by definition.

Control messages are used for session initiation (and optional termination).  This class may also include flow-control and other functionality-request messages.  These messages require reliable in-order delivery.  They also require a DLEP protocol level acknowledgement.

Event messages describe a change of session state, such as Neighbour_Up, Neighbour_Down.  They must be delivered reliably and in-order, but do not require explicit acknowledgement at the DLEP protocol level: the events have occurred whether the router likes it or not.

Status messages describe the change of status of a link or neighbour, examples include metric updates.  Such messages do not strictly need to be delivered reliably, but must be delivered in order. It is logically valid for a metric change event to be cancelled by the sender before delivery if a later message supersedes the information.  Like event messages, status messages require no explicit acknowledgement at the DLEP protocol level.

TCP is an ideal transport protocol for delivering Control and Event messages, and it is considered by the active DLEP participants that specifying a new protocol that implements all the reliability and in-order delivery of TCP is just reinventing the wheel.  It is also accepted that the Nagle algorithm does not add benefit, and SHOULD be disabled.

It could be debated that a new protocol should be defined for Status messages, taking advantage of the relaxed delivery requirements.  The proposal is to mandate TCP/IP as a default supported protocol, but allow some mechanism within the discovery or session initiation steps to allow compatible routers and radios to establish an alternate protocol to deliver status messages.

It has also been argued that there may be a class of control messages from router to radio (the characteristic request/flow-control messages) that may benefit from a more relaxed delivery model (in-order but allow superseding).  Again, this can be supplied by using a second negotiated protocol as per status messages.

A compelling reason for mandating a TCP + UDP stack as minimal transport protocols is that embedded implementations for these protocols are freely available and the majority of radios implementing DLEP already support an IP stack for the data-plane.  Specifying an elaborate custom transport stack just for DLEP will diminish uptake of the protocol from radio vendors and will relegate DLEP to obscurity.

Just my 2 pennies worth...

Rick Taylor
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com