Subject: [manet] New DLEP reference implementation?

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 16:01:35 +0000

As far as I know, the only open-source reference implementation of DLEP is the code Cisco kindly published on SourceForge some 4 years ago.  The implementation was dlep-draft-00 (or perhaps earlier), and is therefore probably misleading to anyone searching for references.

Has the time come for us to release a new reference implementation of DLEP-05+, and do people think it would be useful?

Over breakfast, I made a rough mental sketch of how I would do a reference implementation:

GPL license - This is not meant to be used, so stick 'difficult' license on it.
POSIX platform.
Command line only, no GUI required.
Run in either 'modem mode' or 'router mode'
Demonstrate basic session initialization, maintenance and termination, nothing fancy.
Write it in C. (It's what embedded guys use, and it's the lowest common denominator)
Use libuv (socket multiplexor from node.js)
Log signal events to stdout, along with the associated data-items.
Don't try and do anything fancy or fast, it's 'howto' code.
Stick it on GitHub, because I prefer it to SF.
Document with doxygen, and try to make it easy to read.

I'm not sure yet how to run in 'modem mode', as it might need some kind of interactive console.

Now, I *might* be able to find some cycles to put a skeleton project together, but I would need some cycles from the rest of you!  Does anyone have any keen students/engineers in need of a short project?

Obviously it would have to be done as a 'clean-room' implementation, as I know a few of us have DLEP-ish implementations in commercial products, and we would have to ensure all the men in suits are happy.

It also occurs to me, given John's InterOp announcement, that having a reference implementation would be handy.

Any comments?  Good?  Bad?  Don't care?

Rick

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 18:13:36 +0200

> Document with doxygen, and try to make it easy to read.

This looks pretty similar to my plans when DLEP-06 (which feels close
to DLEP-WGLC) comes out...

But a reference implementation will always be useful to test
against... some errors are hard to find when you always test against
your own code.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 23 Jul 2014 16:53:27 +0000

>> GPL license - This is not meant to be used, so stick 'difficult' license on it.

I would have an issue with GPL license. The purpose of a reference implementation *is* to be used, either in whole or in part. IMHO, the GPL license is too restrictive. That's the reason we went with the MIT license. 

Regards,
Stan

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 23 Jul 2014 10:13:01 -0700

> kind of interactive console.

Rick,

If you're so exploring, look at things from what the group has been
calling 'modem' end of things.  Some IEEE 802 language shift is in
order:

Base Station (BS, what Brian is calling hub) and Subscriber Station.
Somewhat more precise language than 'modem'.  

Brian's satcom problem is a case where all SS can see BS but we make no
assumptions about any SS being able to see each other.  This is why
Brian is using 'hub/spoke' terminology.  It is that; no mesh.   
     _The_ layer 2 protocol that implements such is IEEE 802.16.  You
need a bit of literacy vis .16 to do the job (and it may be easier than
you think).

There are about four dozen MAC messages in 802.16 that are not
communicated through to layer 3.  They're carefully outlined in the
standard (in fact the bulk of the page count).  Of these, the most
useful (and perhaps only one you need) is the UL-Map message (upload
map).  The UL-Map message is included in the BS broadcast stream each
frame and it maps out the timeslices for that frame -- each SS transmit
assignment (and where the maintenance window for new subscribers
lies).  

    For orientation (section 6.3, my copy is 2004 standard): "Each SS
shall have a 48-bit universal MAC address, as defined in IEEE Std 802 ®
-2001. This address uniquely defines the SS from within the set of all
possible vendors and equipment types. It is used during the initial
ranging process to establish the appropriate connections for an SS. It
is also used as part of the authentication process by which the BS and
SS each verify the identity of the other.

"Connections are identified by a 16-bit CID. At SS initialization, two
pairs of management connections
(uplink and downlink) shall be established between the SS and the BS and
a third pair of management
connections may be optionally generated."  

     I'd suggest that you can wiretap the CID information or otherwise
squeeze the CID data from the station -- its pretty much readily
available.

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 17:33:10 +0000

Rex,

Are you suggesting that we modify our entire tdma access control?  I can't imagine there would be a benefit to that. The physical layer is not at issue in my design - it's strictily the radio-routing link I'm trying to understand/design/optimize for my use case - given I have a much bigger scale problem (thousands of nodes), no mesh, multicast and vlans too worry about.  Perhaps I misunderstand your point, and if so I apologize, but I don't see any advantage to prying open the whole radio control plane. That is very mature for more than a decade now.

If this is what you mean, could you please clarify why that would be advantageous to consider?

Thanks,
brian

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Rex Buddenberg
Sent: Wednesday, July 23, 2014 1:13 PM
To: Rick Taylor
Cc: [email-masked]
Subject: Re: [manet] New DLEP reference implementation?

Rick,

If you're so exploring, look at things from what the group has been calling 'modem' end of things.  Some IEEE 802 language shift is in
order:

Brian's satcom problem is a case where all SS can see BS but we make no assumptions about any SS being able to see each other.  This is why
Brian is using 'hub/spoke' terminology.  It is that; no mesh.   
     _The_ layer 2 protocol that implements such is IEEE 802.16.  You need a bit of literacy vis .16 to do the job (and it may be easier than you think).

There are about four dozen MAC messages in 802.16 that are not communicated through to layer 3.  They're carefully outlined in the standard (in fact the bulk of the page count).  Of these, the most useful (and perhaps only one you need) is the UL-Map message (upload map).  The UL-Map message is included in the BS broadcast stream each frame and it maps out the timeslices for that frame -- each SS transmit assignment (and where the maintenance window for new subscribers lies).  

    For orientation (section 6.3, my copy is 2004 standard): "Each SS shall have a 48-bit universal MAC address, as defined in IEEE Std 802 (r) -2001. This address uniquely defines the SS from within the set of all possible vendors and equipment types. It is used during the initial ranging process to establish the appropriate connections for an SS. It is also used as part of the authentication process by which the BS and SS each verify the identity of the other.

"Connections are identified by a 16-bit CID. At SS initialization, two pairs of management connections (uplink and downlink) shall be established between the SS and the BS and a third pair of management connections may be optionally generated."  

     I'd suggest that you can wiretap the CID information or otherwise squeeze the CID data from the station -- its pretty much readily available.

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 17:35:38 +0000

Rick,

Perhaps I can help with radio parts -- I'll have to work on this anyway to play nice at  the interop....

Brian

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: Wednesday, July 23, 2014 12:02 PM
To: [email-masked]
Subject: [manet] New DLEP reference implementation?

Write it in C. (It's what embedded guys use, and it's the lowest common denominator) Use libuv (socket multiplexor from node.js) Log signal events to stdout, along with the associated data-items.

Rick

---

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 17:32:13 +0000

>I would have an issue with GPL license. The purpose of a reference implementation *is* to be used, either in whole or in part. IMHO, the >GPL license is too restrictive. That's the reason we went with the MIT license.

My intention in using the GPL license was to effectively prevent people using the reference implementation for anything more than interop testing and examining how one might go about writing a DLEP router or radio.

If people are willing to put the effort into a more usable implementation, then BSD/MIT is probably the right way to go, but it depends on what the code author's intention for the code is.

Personally, it makes no difference to me, as long as I'm not stating that the code is fit for a purpose...

Rick

---

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 17:41:33 +0000

Rex,

I'm with Brian on this one, in DLEP terms what you discuss is definitely 'radio magic', and the intention of a reference implementation is to demonstrate via code how one might go about implementing DLEP for a router or radio.  The details of the radio is definitely out of scope; I don't want to get caught up in a TDMA/CDMA/whatever emulator.

My musings about a console interface to the DLEP code in radio mode is more along the lines of:

>New Link Radio 3 to Radio 2
Radio 3 is now linked to radio by link 7.
>Link 7 CDR 2300, Up
Link 7 now up, CDR: 2300Kbps.
DLEP Destination_Up signals sent to: Radio 3, Radio 2.
>Quit
Goodbye... 

Does that clarify?

Rick

---

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 17:44:24 +0000

Thank you Brian, that's a very kind offer.

I don't however want to get too far into the details of what the 'router' and 'radio' parts of the DLEP ref impl does, so I want to abstract them as much as possible, but all help gratefully received!

Damn, this idea of mine is gaining traction, I better flesh out my design a little more... ;)

Rick
________________________________________
From: Snyder, Brian [[email-masked]]
Sent: 23 July 2014 18:35
To: Rick Taylor; [email-masked]
Subject: RE: New DLEP reference implementation?

Rick,

Brian

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: Wednesday, July 23, 2014 12:02 PM
To: [email-masked]
Subject: [manet] New DLEP reference implementation?

Rick

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 23 Jul 2014 11:17:41 -0700

Rick, Brian,

Working the interface between layer 2 and layer 3 is always, er,
interesting.  One of the things I was suggesting was use of IEEE 802's
agreed language for layer 2 artifacts (e.g. BS and SS instead of
'modem').  This is a social problem getting a couple of different
engineering communities talking accurately.  
     I probably was a little overextending this by delving into the
specific MAC parts of 802.16 ... back some of that up.

'Radio magic'.  Here we have another case of multiple communities
communicating awkwardly (I have the scars*).  802.16 was derived from
DOCSIS.  The working group essentially used the layer 2 MAC from DOCSIS
and bolted on a radio interface instead of cable.  So I'd have a hard
time saying anything that I'd waved at you earlier 'radio magic'.  'MAC
magic' perhaps.

*if you want a sample, track down the 101 different uses of the term
'waveform'.  

Brian, I would be interested in more information about  
> our entire tdma access control
Most satcom programs have been somewhat proprietary about such
information.  

Hopefully shedding light and not so much heat.

b

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 18:35:15 +0000

Rex,

I would have check with the suits about sharing anything like that. I'm not sure what the status is, I'm guessing (even mostly sure) its considered proprietary.  Regardless though, it's a different discussion that doesn't have anything to do with DLEP or MANET in particular.

Thanks,
Brian

-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 2:18 PM
To: Rick Taylor
Cc: Snyder, Brian; [email-masked]
Subject: Re: [manet] New DLEP reference implementation?

Rick, Brian,

Working the interface between layer 2 and layer 3 is always, er, interesting.  One of the things I was suggesting was use of IEEE 802's agreed language for layer 2 artifacts (e.g. BS and SS instead of 'modem').  This is a social problem getting a couple of different engineering communities talking accurately.  
     I probably was a little overextending this by delving into the specific MAC parts of 802.16 ... back some of that up.

'Radio magic'.  Here we have another case of multiple communities communicating awkwardly (I have the scars*).  802.16 was derived from DOCSIS.  The working group essentially used the layer 2 MAC from DOCSIS and bolted on a radio interface instead of cable.  So I'd have a hard time saying anything that I'd waved at you earlier 'radio magic'.  'MAC magic' perhaps.

*if you want a sample, track down the 101 different uses of the term 'waveform'.  

> our entire tdma access control
Most satcom programs have been somewhat proprietary about such information.  

b