My day job is working in various aspects of IP networking. A few months ago I came across the idea of OpenFlow and some ideas have been bubbling in the back of my head since then. More recently I’ve been investigating ways to implement high performance routers at a low cost and have revisited OpenFlow and what it can do.
OpenFlow is a component of Software Defined Networking, which could very well be the future of how large networks work. Presently routers and switches have their data plane (the traffic passing through them) and their control plane (where to send the traffic passing through them) tightly integrated. Software Defined Networking involves a separate machine running the control plane, and one “controller” can be responsible for a number of different data planes. OpenFlow is an API (application programming interface) which defines how the controller talks to the data plane.
All this has got me thinking about how much current protocols at layer 2 (the switching layer) suck. There are:
- Discovery protocols for finding what you’re connected to (CDP, LLDP)
- Protocols for checking that links are working correctly (BFD, Ethernet Loopback)
- Protocols for checking that traffic cannot loop (STP, MRP, G.8032v2)
Which of these protocols are available to used depends on which manufacturers equipment you have bought and which firmware level it is at. The discovery protocols broadcast potentially sensitive information about your network so must only be turned on for ports which connect to your own equipment.
So I was thinking, with an open control plane it should be possible to design something better and test it.
A loop management protocol by its nature needs to know if links are working, so there is scope to combine two protocols into one there.
A high level overview of a protocol that covered all of this in one would be something like:
- Provider Switch 1 floods discovery packets out of all its ports, signed with the Provider’s management domain key
- Customer Switch 1 replies to the discovery packet saying “I’m alive and not in your management domain – here are the details I make public”
- Provider Switch 1 replies to Customer Switch 1 with the details it makes public.
- Provider Switch 2 replies to the discovery packet saying “I’m alive and in your management domain – here are my encrypted details”
- Provider Switch 1 replies to Provider Switch 2 with its own encrypted details
- Provider Switch 1 reports these findings to the controller.
- Every 20mS (or so,) Provider Switch 1 sends a heartbeat to all connected switches which should reply straight back. Every 30 mins (or so,) Provider Switch 1 refreshes its encrypted details with all connected switches
The controller can then build up its own topology diagram of the network and use these to create appropriate forwarding paths.
What are the advantages of this?
- It allows autodiscovery of your own switches without risking information leaking if a connection is plugged into the wrong port.
- Through the option of “public” details it is possible to perform troubleshooting without giving away commercially sensitive information
- As there is a centralised flow controller, there is no requirement for a complicated loop prevention protocol – the flow controller has knowledge of where the frames are being passed. This means that frames can be passed across the shortest route instead of there only being one “active” switched path through the network.
So… am I right? Utterly wrong? This looks to me like something worth investigating…
Distractions
I’ve not got much work done on fldigi-dv over the past few days.
Mostly that has been because my girlfriend’s 4 year old cat is severely ill and we’ve been rushing back and forwards to the vets making sure we get to see her at every opportunity.
In addition to that, Bruce Perens K6BP has been talking on the codec2 mailing list about the possibility of building mobile and handheld SDR-based radios. This would be great news for people who want to experiment and not be limited to what is presently possible. I’m currently setting up a Yocto development environment so I can play with prototyping that, and hopefully (if I can get hold of one or two) a Raspberry Pi.
I’ll hopefully get back to fldigi-dv over the weekend. I’m close to the point where I should be able to start doing actual, real world, testing. Though it will be on virtual machines and not using RF, but still…
New Git commits
I spent some time last night doing clean-ups and making the changes look more logical
I’ve pushed my outline code for how I think the FDMDV transmitter should work to https://github.com/DanAnkers/fldigi in the dv-preliminary branch. It’s not tested and doesn’t even appear in the menus yet – but it does compile which is nice!
Another status update
I’ve not given any update on my open-source implementation of FDMDV recently.
I’ve pushed a couple of clean-ups to the “SSB mode” to the Github repository, but all of the interesting stuff is not suitable for public consumption yet. To be honest, I’m not even near trying to compile it yet.
I made a good start on the FDMDV transmitter, and then decided that my approach was completely wrong and I should be making far more use of C++ classes and inheritance. After taking a few days’ break from the project I changed my mind and went for following the path of least resistance in order to get something working, and once it’s working I’ll refactor to do it properly and in a more extensible way.
The fact that I’m trying to doing things “properly” with Git is keeping me from just pushing everything I’ve got out into the public. When you’re reading a Git log, you need to see a nice clean descriptions of what a commit is doing rather than “Try again to make it compile” over and over…
If things go my way, I should have code that compiles and transmits encoded voice by the end of the weekend. After that I’ll have lots of “fun” trying to work out which bits of the specs I’ve interpreted wrong – for example there’s a whole bunch of different ways I could have the QPSK modulation incorrect.
Further fldigi-dv update
Status
I’ve fixed a couple of bugs in the code on Github and made a slight improvement too – thanks to Chris KC2RGW for testing.
I’ve made a start on the code to transmit FDMDV, and got the basic shape of it complete. In a few more days I should have a version which compiles, and then it’s on to (a) testing to see if the original FDMDV program can decode things my program sends and (b) trying to wrap my head around how to receive FDMDV.
I’ve pushed some code out there…
I’ve been talking about this DV project for a few days now.
Despite the fact that I’ve not tested it on a proper computer, I decided to push what I’ve done so far out to Github. This implements “SSB” (i.e. copying the signal between the voice soundcard and the rig) with working TX/RX switching. I do plan to do some more code cleanups on this, but if anyone fancies doing some testing with some really early code, then go ahead.
https://github.com/DanAnkers/fldigi/ in the dv-preliminary branch.
fldigi-dv status update
Status
So close now.
Test on a real computer. Clean up code. Retest. Post to Github. That will be the SSB bit done!
fldigi-dv status update
Status
fldigi-dv looks like it’s working for SSB receiving, and working for SSB transmit apart from not being able to switch back to RX.
Aside
I need to change those theme pictures for something more radio-y
“fldigi-dv”
Status
Life got in the way too much today, so I didn’t get too much done on the project that’s currently called “fldigi-dv” – my Digital Voice branch of FLDigi.
I got the configuration dialog working yesterday, then decided today that I’d taken the wrong approach and started again. This evening I’ve filled the new parts of the configuration dialog with useful information. Slow progress, but progress.