This is Part II of a Two-Part Series; in Part I we discussed the components and attributes of intent-based networking. Here, we’ll detail several use cases in the areas of traffic management and threat mitigation for intent-based networking.
Having established the key components of an intent-based networking system, let’s take a look at some examples of how this approach to networking bears fruit. For each of the services we’ll discuss here, there is generally an associated SLA that must be met.
The integrity of that SLA may be measured by your internal operations, another department within your enterprise, or by a customer. The classes of use cases we will examine are:
External Risk Mitigation
Network Security Hardening
The way traffic management is handled today (Figure 1), sensors on individual network elements (streetlights or switches) send information to a local central office (CO), which backhauls it to a data center (DC).
Figure 1: Traffic Management Today (for Streets or Networks)
This monitoring data is shipped to a NOC, where it is examined and analyzed. The analysis of the data is dependent on the skill set of the personnel at the NOC at that instant of time.
This is a time consuming step, taking anywhere between a few seconds to a few hours, and at times even a few days. Perhaps there is a problem, or maybe (if it’s not an outright critical issue) a small configuration change can help things run more smoothly.
If it’s determined that changes should be made, tickets are opened in the NOC and sent to a team of engineers working in (typically) a different office—either headquarters or a support center. That team determines a corrective action, and sends configuration changes to network elements in the DC, the CO, or perhaps (continuing the “street traffic” analogy) to the “traffic light” (or access point).
However, by this time, the underlying state of the traffic (network or street) may have changed, and the configuration update may have less than the desired effect.
The transportation analogy implied by Figure 1 is very apt here, for you can see that when the changes are not in real time, the remedial action, though correct, is inconsequential or ineffective: changes in the traffic light pattern a couple of hours later will still leave you stuck in the intersection for the interim.
In the pure networking context, examples of why the configuration change might be different based on the state include various anomalies such as:
Now let’s look at network traffic management in the world of intent-based networking (Figure 2).
Figure 2: Traffic Management with Intent Based Automation
There is still backhaul to the DC, yet with service assurance and data collection modules in place, the situation is rapidly assessed based on the data collected, and plans are made based on multi-dimensional attributes (time, place, traffic density) for reconfiguration commands based on the state of the network (or roadways in this pun-filled example).
The service delivery module sends the appropriate to the data center in near-real time, so that when the change is made, it fulfills the intent and also provides the corrective action that is appropriate to the underlying state of the network.
External Risk Mitigation
For an example of external risk mitigation, consider Figure 3. An intruder seeks access to highly classified data.
Figure 3: External Risk Mitigation
Here, there are a variety of network slices running on the infrastructure:
If the intruder forces entry into a facility to gain access to the top-secret (FYEO) network, an external risk alarm is sent to the service assurance module. Since all the facilities and networks are being continuously monitored, the service assurance module determines that the FYEO network needs to be taken offline in the facility that has been compromised.
The service delivery module takes the corrective action on both the compromised facility and the one that needs to now be the border of the FYEO network. The data is now safe.
Related examples could include unauthorized access to corporate assets (such as servers, storage, or the network) either during or after business hours. If this occurs, affected network partitions can quickly be isolated or shut down.
The collection of homes is forming a fog network. The fog end-nodes (inside a home) are more susceptible to a botnet attack, and service providers are less able to enforce security on the end-nodes, leaving the entire service provider network vulnerable. Visibility-aware network elements on this fog network can detect a DDoS attack.
The data collection (monitoring) module, in conjunction with the service assurance module, will:
Take the action to assess the situation and plan what to do
Order the service delivery engine to reconfigure relevant equipment in the DC and in the CO
Traffic can be scrubbed and/or black holed. If this is done in time, the effect of the attack will be at most limited to one CO and the rest of network is unaffected.
The value of this confining an attack of this sort can be seen when you consider the massive 2016 DDoS attack that brought down many web sites worldwide. With this self-healing technology in place, the damage from such an attack is reduced by many orders of magnitude.
Call to Action
Brocade technologies that are pertinent to this topic include: