Subject: [manet] DLEP extensions and capabilities

From: Rick Taylor <[email-masked]>
Date: Fri, 8 Sep 2017 10:09:35 +0000

Hi All,

I've been mulling over how one might implement an extension that allows
a DLEP peer to advertise its capabilities, as desired by Stan and
Henning.  I'll stick to local capabilities for now, to scope the
problem a little.

So, an obvious way to do this would be to create an Extension 'Local
Caps'.  This extension would define a new Data Item, that lists the
capabilities, each defined by a number in a new IANA registry.  This
Data Item is used during Session Init to announce capability.

However, this looks remarkably like the extension mechanism itself. 
Would it perhaps be more sensible to register device capabilities as
extensions in their own right, i.e. in the IANA DLEP Extension
Registry.  So a modem that supports 'on-demand' data rates, would
advertise an 'On demand' extension, and a router that can do something
sensible with 'On demand' data rates also advertises support.  If the
modem detects that it's talking to a router that doesn't understand
'On-demand' then it could announce an artifical data rate as CDR
instead of 0.

I see the extensions-only mechanism as having some advantages:

1) It allows basic negotiation of capabilities and the ability to do
something useful with the capability.

2) It doesn't require another IANA registry

3) It builds on existing core DLEP functionality that MUST be supported
already.

4) It requires a (short) document describing exactly what each
capability means, and how to handle it.

Downsides could include a consuming extension number space.

Thoughts?

Rick

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Sep 2017 13:08:46 +0200

> Henning.  I'll stick to local capabilities for now, to scope the
Good idea...

lets stick to RADIO/interface specific local capabilities first...

there might also be neighbor specific capabilities, but lets delay
this discussion.

> 'On-demand' then it could announce an artifical data rate as CDR

This feels a little bit as a dirty trick... especially because it
needs to circumvent the "supported by both sides" mechanism of the
DLEP protocol because we are using the extensions differently.

If there is a "need unicast to determine MCS" attribute/capability of
the radio, it makes no sense for the router to announce it... the
normal mechanism for extensions would say "don't use it, router did
not report it".

Henning