Re: [manet-dlep-rg] London meet up?

"Taylor, Rick" <> Mon, 10 March 2014 10:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F8E51A0412 for <>; Mon, 10 Mar 2014 03:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2XL2UoVM8Mlv for <>; Mon, 10 Mar 2014 03:27:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2916C1A040F for <>; Mon, 10 Mar 2014 03:27:29 -0700 (PDT)
Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([]) by with ESMTP; 10 Mar 2014 11:27:23 +0100
Received: from ([]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 10 Mar 2014 11:27:20 +0100
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Mar 2014 11:27:19 +0100
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Mar 2014 11:27:19 +0100
Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by ([::1]) with mapi id 14.02.0318.004; Mon, 10 Mar 2014 10:27:01 +0000
From: "Taylor, Rick" <>
To: " Group, (" <>
Thread-Topic: [manet-dlep-rg] London meet up?
Date: Mon, 10 Mar 2014 10:27:01 +0000
Message-ID: <>
References: <> <>, <>, <> <11b98a4c-f848-48b7-bf02-09c22b80900c@SUCNPTEXC01.COM.AD.UK.DS.CORP>
In-Reply-To: <11b98a4c-f848-48b7-bf02-09c22b80900c@SUCNPTEXC01.COM.AD.UK.DS.CORP>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Mar 2014 10:27:19.0825 (UTC) FILETIME=[511F4010:01CF3C4B]
X-TM-AS-Product-Ver: SMEX-
X-TM-AS-Result: No--20.661200-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Subject: Re: [manet-dlep-rg] London meet up?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Mar 2014 10:27:34 -0000

Hi All,

Here is my updated list of TODOs that became DONEs (I reckon we should get the output of our meeting on the main WG list while there is still lots of post meeting activity)

Stan has committed to updating the session initiation description to place the
TCP server in the modem, so the initial part of the protocol is:  Modem
broadcasts UDP Hello packets containing version, ident and TCP
address/port.  Router TCP connects, session initiation occurs via the new TCP

Credit windowing will stay in the document, but will be clearly marked as an
optional part of the protocol.  There was some concern raised over the clarity
of the current text which will need to be address before last call.

Vendor extensions will be defined using a new Data Item, containing a OUI
(or something from an existing registry) and space for a payload.  There will
need to be some guidance verbiage to characterise what is a valid vendor
extension and what is not.

There was clarification of what both ends of a DLEP session must do on
receipt of an unrecognized signal and data item.  For a data item, the receiver
MUST ignore the data item, for a signal the recipient MUST send an error
status signal and terminate the TCP connection.

There will be no facility in DLEP v1 for vendor extended signals.  Any extra
signals will require an uplift of the verion of the protocol and require a new

There will be no such thing as a Peer Characteristic Request.  This will prevent
abuse and misuse of the DLEP protocol to act as a configuration mechanism.

The latency and EFT metrics were agreed to be fundamentally the same metric,
whether EFT is used to measure the latency or some other algorithm, and so EFT
will be dropped from the draft, leaving latency, with some text covering the use
of EFT for defining latency.  Also, it was decided that latency should be defined as a
32-bit positive number of microseconds.

There was further discussion concerning multiple QoS flows with seperate
metrics across a single link.  This was agreed to be pushed out to another
draft after DLEP v1, after some analysis that the proposed approach
(hierarchical data items) will not break existing DLEP v1 implementations.  Stan
agreed to double check that the text specified 16bit length values for all TLVs
(data and signals).

There was discussion about enumerating error codes, and potential error
text.  The status signal MUST include an error code, 0 being success, others to
be enumerated after close analysis of the protocol, plus and optional free
text field to carry loggable information, capped at 80 bytes, utf8 encoded.

There was discussion of confidence values for metrics, and this was rejected
as a core DLEP mechanism, and the suggestion was to use an extension data
item TLV instead.

In light of achieving their goal of listing the outstanding points that needed
to be resolved before DLEP can make progress to WG last-call, and actually
achieving suitable consensus to resolve the outstanding issues to the
satisfaction of one of the authors present, the DT decided to not apply for a
continuation of their charter, and to instead announce "Mission Complete"

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, part of the Airbus Defence and Space division. Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. Registered in England and Wales under company number 04191036