Exception handling in the field for telecommunications by applying the IF THEN ELSE of SD-WAN

When Ronald Bartels of Fusion first started programming many moons ago it was on a ZX81, and within the first day this became the first lesson:

IF logical expression THEN procedure

ELSE procedure

There was a procedure for when the data matched and a procedure for when it did not. Most programmers now avoid the latter. They programme the data to match and ignore mismatches. Basically error and exception handling goes out the window. The joke about how to fix IT equipment by turning it off and on again is a direct result of this stupidity. Often a decent programme would double in size when all the error handling routines were added. In those days we started with 16KB memory so space was at a premium but we still implemented it.

Handling the exceptions in SD-WAN

Legacy routers and systems deal with exceptions in networking with blissful ignorance. As mentioned previously, they are of the turn it off and on again type. They implement the IF but never bother with the ELSE leaving users with spilled milk.

CIA

Now over to software defined wide area networking (SDWAN) and error handling in more detail, but let us rather call it exception handling because there are three types that can occur namely loss, faults and errors. It is important to distinguish between them as it is fundamentally the basis of the well-known CIA security framework. This is specified as follows:

• C = Confidentiality (where the exceptions are a loss);
• I = Integrity (where the exceptions are errors); and
• A = Availability (where the exceptions are faults).

Loss

Let us start at the first. Loss is usually associated with theft. In our neck of the savannah that is a common occurrence. From the cable on the last mile to the SD-WAN edge itself. And then there is power management. Of course when someone is going to abscond with your edge, the first thing they are going to do unplug the power. A method to monitor the power is a good start. In South Africa loadshedding does damage equipment. Also tropical storms and flood can compromise infrastructure that has to be replaced.

Errors

The next one is errors. Errors can be detected using a higher level protocol scheme which is slow or the SD-WAN hardware can read the error counters directly on the hardware and make a determination. As an example, wireless connections might experience BERs and it would be better to deal with these via queuing or alternative paths than dropped packets. Also during congestion, it would be better to handle traffic in a deterministic manner. The problem when broadband is used is that the throughput to use for QoS calculations is not always consistent. Thus a mechanism that dynamically adjusts the parameters is relevant. This facilities the QoS calculations being closer to the actual link ability instead of a perceived one.

Faults

Finally faults. In an SD-WAN environment there are both uplinks (connection to the carrier) and downlinks (connection to the client). It is crucial that the SD-WAN portal measures the uptime availability of these connections and reports them as separate metrics. We have talked previous about cable break on the carrier side which will lead to faults but the actual probability of faults is high. TLBs fixing water and power faults often dig up and break telecommunications infrastructure. The fibre cables get bend or unplugged. The equipment itself fails so it is crucial to know the status of the downlink as well as downstream networking kit. Here the use of LLDP is crucial.

In conclusion, when building a SD-WAN edge, the philosophy is "Fuck Everything, Do Five Blades." The legacy routers and firewalls started with a single blade and some went dual but none are at the level of SD-WAN.

IF you would like to contribute THEN please comment below ELSE please click the like button. See what we did there?