3.1. Placement of the controller

Figure 3.1 illustrates the different scenarios for the placement of the controller in a software network environment.

In Figure 3.1, we see three main scenarios. The first is highly centralized around an SDN controller. The control data are fed back automatically to that center. The second solution is to use intermediary machines at local or regional levels. These machines could be SBCs (Session Border Controllers) – a term which tends to be used in operator networks – or NACs (Network Access Controllers), corresponding to the solution favored by companies. In this scenario, the solution sends the control data to local or regional datacenters. Finally, the last example of architecture consists of positioning the control as close as possible to the user in femto-Clouds. The advantages are clearly the very short response time, the agility of the solution because of the possibility of changing the virtual machines used in the femto-datacenters and the addition of a form of network intelligence very close to the user. The disadvantage here is that the solution involves widespread distribution of the information, with all the complications that this can entail to perform controls, which, obviously, will not take place locally.

The three main solutions described above can be combined, with two levels or even all three levels, acting simultaneously, certain virtual machines may be migrated to the femto-datacenter, whilst others remain in a central or regional datacenter.

If we examine the first scenario, it represents a highly centralized system on a large Cloud with several high-capacity datacenters. These datacenters are usually situated a long way from the periphery. This solution, which has been put forward, amongst others, in the context of C-RAN, is a revolution in the world of networks. Indeed, all the computations are performed in a powerful Cloud, with the decisions being centralized. This solution requires enormous datacenters, usually situated far from the periphery. This case is illustrated in Figure 3.2, in the form of a centralized C-RAN. We shall look at this proposed solution in greater detail in Chapter 4, but right now we are going to examine a few of the fundamental issues.

The revolutionary aspect is Cloud access network, which is concentrated in an optical network known as RoF (Radio over Fiber). The local loop, in this case, is formed of greatly-simplified antennas which do not process the signal, but merely forward electromagnetic signals to the center over an optical fiber. The signals reach a datacenter with virtual machines to process the radio signals. It should be noted that this solution enables us, with a single antenna, to process almost any type of signals received on that unique antenna: Wi-Fi, 3G/4G/5G and Bluetooth, which is a significant innovation for the future.

The datacenter, be it large or small, can then receive all the virtual machines necessary for the computing of the applications. This solution requires a physical star-shaped network using optical fiber technology, where there are no longer any concentration- or control devices. There are no intermediary boxes or computing machines. The signal is sent to the central datacenter exactly as it is. In other words, there is no longer a network, i.e. no messages, no packets, no frames – just a succession of radio signals.

In terms of cost, the centralized C-RAN system is certainly one of the most affordable solutions on the market, because all the intermediary machines are eliminated. However, this solution exhibits the disadvantage of being centralized, and therefore requires all the usual precautions for centralized environments to be exercised. For example, the amount of resources in the different datacenters needs to be doubled or even tripled. Another problem is the response time for simple or local actions, such as inter-cell handover. If we assume there is a distance of 300 km between the periphery and the center, the propagation time there and back represents around 2 ms. In addition to this propagation time, we also need to allow for the time taken to run the control algorithms, and therefore reaction times of around 5 ms. Most control applications can cope with values like these. However, they are too long for simple actions and, above all, they are too costly in terms of overall data rate.

The solution represented by the centralized C-RAN architecture is certainly interesting, but there is a danger that it will be rejected in developed countries whose infrastructure is ripe for a decentralization of the datacenter. On the other hand, for developing countries where there is very little infrastructure, the C-RAN represents a good opportunity to gain direct access to 5G environments at a low cost.

This centralization may be compensated by a slight distribution on the periphery, in which case we see the emergence of small Clouds (known as Cloudlets) situated near to the relay antennas. This solution is shown in Figure 3.3.

The second solution for the placement of the controllers is to build them into regional Clouds. In this case, the controllers are situated at the level of the company, or the DSLAM (Data Subscriber Line Access Module), in a telecommunication network. Here, the controllers only manage networks of limited size. This solution requires interfaces between controllers (westbound interface for heterogeneous controllers and eastbound interface for identical controllers). In addition, this solution does not eliminate the local loop, which therefore resumes its original duties. It merely handles the connection, which is done in signal mode, with framing and packeting being done in the Cloudlet. We shall revisit this solution, which is popular in developed regions, later on.

The control system is partially distributed, and coordination is needed between the different controllers for all communications between two different sub-networks. The eastbound and westbound interfaces become particularly important in this context. Figure 3.4 presents this architecture, wherein the controllers are encapsulated in regional datacenters.

Looking again at Figure 3.3, it seems to suggest that Cloudlets are available even nearer to the user than regional or local centers. Cloudlets are situated in the access antennas. This represents another solution which we shall examine in detail in this chapter: that of femto-Clouds.

The third scenario, which best represents a smart edge, involves total decentralization to femto-Clouds. Those femto-Clouds are associated with femto-datacenters located very close to the clients, i.e. in the access points or in boxes situated in the user’s area. The immediate advantage of femto-Clouds is the extremely short response time to run a control algorithm, and therefore the ability to carry out operations in real time. However, this requires devices with significant amounts of resources – and many of them. Given the reduction in the price of hardware, this solution is increasingly gaining favor in many services offered by manufacturers. In addition, there is a need to install boxes to accommodate the femtocells, and it is possible to take advantage of this to enlist a little local power, running virtual machines to establish connections and perform local computation in those boxes. In this case, we speak of Metamorphic Networks, or MNets: the network metamorphosizes depending on the client who is connecting.

In Figure 3.5, we have illustrated an MNet configuration with an MNetBox (Metamorphic Network Box) from VirtuOR (a start-up of University Pierre et Marie Curie). The developments undertaken by VirtuOR, amongst others, pertain to this new generation of metamorphic networks, where each client is allocated his/her own network. The network appears differently for each client, because it metamorphosizes depending on the client connected. The MNetBox is, in fact, a femto-datacenter in which the clients’ virtual machines are located, to handle the networking applications (Networking Apps). These networking Apps include all network-level applications that may be found in the literature and in Clouds, such as IP-PBX, routers, switches, SIP servers, firewalls, etc., in particular the virtual machines created by NFV (Network Function Virtualization) standardization, such as DPI (Deep Packet Inspection), computing of NAT, BRAS, etc.

3.2. Virtual access points

A femto-Cloud may support diverse virtual machines – particularly virtual Wi-Fi access points. The client has a choice as to which access point he/she will use: it may be their office access point, their operator’s access point, their home access point or indeed any other access point with its own individual characteristics. The box may contain a large number of virtual access points – all different from one another, and of course, isolated. The exact number depends on the power of the femto-datacenter and on the number of potential users. The data rate received by each user is dependent upon the number of virtual access points, the number of users on each virtual Wi-Fi access point and the Wi-Fi technology used. The virtual access points share the physical antenna, using a token-based technique, for example. Obviously, the capacity of each virtual access point is contingent upon the number of tokens, and is therefore not as powerful as a non-shared access point. However, in light of the rise in Wi-Fi power, as we shall see in Chapter 6 on 5G, each virtual access point can have sufficient capacity. In particular, the use of the IEEE 802.11ac standard means that each virtual access point is able to achieve sufficient data rates for all conventional applications, and even some less-than-conventional ones.

Undeniably, there are some flaws with virtual Wi-Fi access points! Each virtual Wi-Fi access point has its own signaling frames. If the number of virtual Wi-Fi access points is high, then the overhead expenditure is great.

The access point described here is a virtual Wi-Fi access point, but it can perfectly well be a virtual Node-B, i.e. the device which manages the physical antenna for a mobile network. In this case, the box may be considered as an HNB (Home Node-B) or an MNB (Metro Node-B), extended with significant capacities to receive virtual computation machines.

More generally, all wireless access techniques can be virtualized, and thus facilitate personal connections. Depending on the hardware that can be replaced by software, major advances can be implemented to work toward multi-technology access solutions.

In Figure 3.6, we show the context of virtual access points, which is one of the fundaments of the “smart edge” environment. Indeed, for users to connect, we need to put antennas in place, and we can exploit those antennas to do all the local computation needed for access control. In this context, a large portion of the network’s intelligence is on the periphery. The difficulty is in handling communications between users situated in different sub-networks, because we need to coordinate the networking elements which are used for the end-to-end communications. Communications through the eastbound and westbound interfaces are crucial for SDN solutions, to interconnect the femto-datacenters.

Figure 3.6 shows an example of a femto-Cloud, serving two virtual access points, capable of connecting two clients using different network operators. Each client has, in the box, his/her own virtual Wi-Fi access point or dedicated HNB to connect to the network. The two clients do not know one another and they each have their own personalized access point. Plainly, other virtual machines can be placed in the box to manage a particular interface or perform a specific signal computation operation.

More generally, operators are beginning to look at the possibility of rolling out their own virtual access point so as to take position in places where their clients may be. For example, a lecture hall which has a femto-datacenter could connect all the clients of the operator X after migration of a virtual access point X into the femto-datacenter. The virtual access points belong to the network X and are managed directly by the operator X. If the physical access point breaks down, the responsibility for its repair lies with the infrastructure operator, e.g. the owner of the lecture hall. There are various business plans to provision a femto-datacenter, ranging from renting resources to install a virtual machine to charging by the amount of time and capacity used.

3.3. Software LANs

Looking again at the examples from the previous section, it is possible to describe a software LAN. This is a local-area network formed of different femto-datacenters in which the virtual machines can be stored in memory to create these software LANs. Numerous virtual machines such as routers, switches, firewalls or application machines can be transported to the femto-datacenters from a central Cloud or a local server. The decision to leave a machine in the central or regional Cloud or to transport it to one of the femto-datacenters depends on the characteristics of the application and on the evaluation of the traffic that it could generate.

Figure 3.7 illustrates a scenario for a company that has several boxes to create software LANs. In this case, to begin with, the company’s Wi-Fi access points need to be transported to all of the boxes, or else we need to select a number of virtual access points corresponding to logical networks which, themselves, will be constructed to serve specific applications, such as VoIP, IPTV, bank access, messaging, file transfer, professional application, etc. The software networks are established by the virtual machines that run in the boxes. It is also possible to add a completely isolated network for visitors to the company. This allows guests and visitors to connect to the Internet, using the company’s network, with no risk of an attack.

The software networks can use all different protocols from one another, including IPv4, IPv6, MPLS, Ethernet, SDN, etc. It is necessary to choose the protocol which best suits the application for which the data are being sent over the network.

The connections between the boxes may be hardwired or wireless, using protocols corresponding to the type of network chosen by the user. This may be OLSR, AODV, TRILL, or indeed any other protocol developed in this field.

Software LANs open up new possibilities, such as the installation of SDN Wi-Fi access points. Indeed, by combining a virtual Wi-Fi access point and an SDN switch such as Open vSwitch, it is possible to send Open Flow commands from a controller to the Wi-Fi access point. It is also possible, of course, to install an SDN controller such as Open Daylight, Open Contrail or Flood Light in one of the boxes to control the other boxes making up the software network. In this scenario, as in the previous ones, certain virtual machines may remain in the central or regional datacenters, depending on their size and their rate of use.

Although it is predicted that SDN using central networks will become dominant, an ever-growing number of networking individuals are calling for the implementation of SDN in the periphery, because this way the control mechanism is much simpler, the cost is much lower than WAN (Wide Area Network) solutions offered by device manufacturers and the system is just as agile.

Figure 3.8 shows that the control virtual machines may be located in datacenters situated at different levels. The controllers are virtualized in datacenters present at the central or regional level, but can also be found in the femto-datacenters situated on the periphery. Indeed, the Wi-Fi access points (Nodes-B or e-Nodes-B) require hardware, and must be close to the user. These boxes also facilitate the easier introduction of 5G, which we shall look at in more detail in Chapter 6. Indeed, the Internet of Things requires new interfaces that are well suited to the “things” in question. These interfaces can be handled by specially-designed virtual machines.

3.4. Automation of the implementation of software networks

An important point in the advent of the new generation of software networks, whether in terms of the core network or the LAN, relates to automation for the establishment, management and control of personalized networks designed in the context of software networks, which may be SDNs or use legacy architectures, or indeed a mix of the two, given that each software network is entirely independent of the others. With this in mind, as indicated by Figure 3.9, we need to add an auto-piloting system to the general architecture. The basic domains to be piloted are the servers, storage facilities and networks, but we also need to add security and management elements, which have become absolutely indispensable for the proper operation of a complete system.

The piloting system may be referred to by a number of different names, such as “orchestrator”, “governor” or “high-level pilot”, to indicate that this element directs the controllers which are situated in the control layer. This piloting system feeds the underlying layer with the best possible information, and the control layer makes the decisions on the basis of the information received from the pilot.

The piloting system may be centralized, which is generally the case with centralized Cloud architectures, or totally distributed to the controllers, or, as is most often the case in a conventional situation, a mixture between centralized and distributed organization. At present, numerous developments are being made in this field, with virtual machines that act as intelligent agents.

3.5. Intelligence in networks

Intelligence is a much-used term in computer science, which simply means the ability to communicate, to reason and to make decisions. Up until the start of the 2000s, intelligence in networks was very low. The concepts of intelligent networks, dating from the start of the 1990s, introduce a primary intelligence, whose role is to automatically adapt the network components to the users’ demands, but without reasoning, merely based and predefined rules. The next section is devoted to this view of intelligence in networks. It also introduces autonomic networks, which replaced programmable networks or active networks. An autonomic network is one which is capable of configuring itself, and wherein the nodes may become autonomous in case of failure or cutoff in communications.

Since the beginning of the 2000s, true intelligence – i.e. reasoning-based intelligence – has been offered by certain network components, which are able to make decisions pertaining to control or management. The devices which make those decisions stem from the domain of artificial intelligence and smart objects. In particular, multiagent systems have been around for a long time, able to handle security and failures.

Intelligent agents offer the first category of tools whose introduction on a large scale could modify management and control environments, making them more autonomous and more reactive.

We shall now examine the reasons for this power, and then the way in which we construct multi-agent systems.

3.6. Management of a complex environment

As networks have become increasingly complex, the management and control of these environments has become necessary for a variety of reasons, which we shall now go on to examine. Network environments are becoming increasingly dynamic, as we have seen. Numerous and varied applications are interwoven, making it difficult to control the resources. The statistical gain – i.e. what we gain by treating the data packets statistically – in packet-transfer networks is undeniable, but, if the data flows too far exceed the network’s capacities, a meltdown of performance is inevitable.

Network environments are, by nature, distributed, although the trend is toward centralization, which makes it complicated to control and manage them. In addition, enormous scale necessitates even closer control. Sizing is a complex problem to grasp, and we can state that there are no truly effective tools available in this domain, in that the parameters that need to be taken into account in a complex network environment are difficult to fully appreciate. We have a choice between data rate, response time, degree of usage of the line couplers and of the central units, bit error rate, packet error rate, repeat rate and failure rate. In addition, the values of the mean, the variance and sometimes the higher-order moments need to be taken into consideration in order to gain a real idea of the performances.

The engineering of network design involves two main aspects: the qualitative and the quantitative. The qualitative aspect often corresponds to operational security, in the sense that it is possible to prove that the system is stable or that there is no state in which the network ceases to work. The quantitative aspect refers to the values of the parameters listed in the previous paragraph, with the aim of quantitative analysis being to show that these values are reasonable for normal operation of the network.

Security is an important function, to which intelligence may contribute. Today, a certain degree of standardization enables us to have a clearer view of the problems, and a few major classes of security have been defined, corresponding to needs clearly expressed by the users. We can easily imagine the contribution made by intelligent tools in the world of security, to discover anomalies, analyze them, give a diagnosis, propose a solution and resolve the problem.

Management is also a domain where intelligent agents could play a leading role. When a network is running, it needs administration – i.e. we need to be able to control all the operations that take place in the network, from breakdowns and accounting to security, performance management and username management.

Various specific administrative domains already use intelligent components – in particular, the following:

• – configuration management;
• – security management;
• – fault management;
• – performance management;
• – accounting management.

Intelligence of the agents may stem from different areas. The most usual model stems from the domain of distributed artificial intelligence, or DAI.

Artificial intelligence means that a device can take the place of a human being to perform a task. DAI is equivalent to a society of autonomous agents, working together to achieve an overall objective. There are numerous reasons to turn to DAI – notably the following:

• – integration of different points of view. When the data become more specific, inconsistencies may occur in the rule base. The ways in which knowledge is expressed are different depending on whether we are addressing the user, the developer or the technician. Also, two experts who have the same expertise will not always come to the same conclusion. The different points of view are also often contradictory: one might attach a great deal of significance to the costs, and therefore favor a less expensive system, whilst another would choose to develop the publicity, and thus opt for a dearer system. The use of DAI helps to achieve a compromise between different options, by negotiation;
• – representativeness of the real world. In general, it always tends to be a group of experts, with different qualifications and specialties, who work together to realize a set goal. In addition, whilst it seems easy to understand and therefore to model the behavior of individuals (all of their exchanges) thanks to the numerous sociological studies that are available, the way in which the human brain works, and the reasoning process, are less well understood.

For these reasons, the application of distributed artificial intelligence is gradually becoming a reality in the context of network management.

3.7. Multi-agent systems

An agent is an autonomous entity, capable of communicating with other agents, and of perceiving and representing its own environment. A collection of these agents, interacting with one another, forms a multi-agent system. We classify such systems according to numerous criteria, such as the size of the agents, the number of them interacting, the mechanisms and the types of communication, behavior, organization and control of each agent, the representation of the environment, etc.

Based on these criteria, we distinguish two main categories of multi-agent systems:

• – systems of cognitive agents;
• – systems of reactive agents.

Cognitive agents have an explicit representation of the environment and of the other agents. They are able to take account of their past, and operate with a social means of organization. Systems using this type of agent will have only a small number of agents. Several levels of complexity can be envisaged:

• – processes in which the actors implement communication directives;
• – communicative modules, which use specialized communication protocols (requests, commands);
• – cooperative agents, which work with the concepts of skill, mutual representation and task allocation;
• – intentional agents, which use notions of intention, commitment and partial plans;
• – negotiating agents, which carry out conflict-resolution by negotiation;
• – organized agents, which act in accordance with regulation and social laws.

The agents communicate with one another using a specific language. This is intentional communication, which essentially comprises two types: communication by information-sharing and communication by message-sending.

Communication between agents takes place by information-sharing when the solution to the problem is centralized in a global data structure, shared by all the agents. This structure initially contains the data of the problem, and is enriched over the course of its resolution until the solution is reached. It constitutes the only means of communication between the agents.

This type of communication is often spoken of as the blackboard model, discussed in detail in numerous publications. The agents deposit and read a piece of information in a shared data zone – the blackboard – as illustrated by Figure 3.10.

A blackboard system comprises the following three basic elements:

• – the blackboard, in which all the elements involved during the resolution are stored. This data structure is shared by the agents and is organized hierarchically, which enables us to considerer the solution at various different levels of detail;
• – the agents, which generate and store their data in the blackboard. They are independent modules, referred to as “knowledge sources”. Their role is to cooperate to solve a given problem. The knowledge sources are independent, as they are not aware of one another’s existence, and merely react to the events of the blackboard being changed;
• – a control device, which ensures that the system operates in accordance with a certain strategy. Its role, amongst other things, is to resolve conflicts of access to the blackboard between the agents, which may intervene without having been triggered. Indeed, in the absence of centralized control, the knowledge sources react in an opportunistic manner – i.e. they react as best they can. This control device itself functions in accordance with the blackboard model.

Blackboards have the advantage of providing structure and an automatic method (divisions and hierarchy) in the way in which we approach a field of knowledge. They also exhibit the advantage of organizing sets of rules in systems with production rules. However, their lack of local memory means that they are not able to truly function as multi-agent systems. As a general rule, multi-agent systems use a blackboard for each agent.

Multi-agent systems based on message communication are characterized by total distribution of the knowledge, the partial results and the methods used to achieve a result (see Figure 3.11). Certain actor languages offer an accurate incarnation of this type of system. Communication can take place either on a point-to-point basis or by broadcast.

Such a system is built around two components:

• – local computation: quite unlike blackboard-based systems, the knowledge is no longer concentrated in the same space, but instead is compartmentalized and distributed between the different agents. An agent can only manipulate its own local knowledge base, send messages to other agents that it knows (its “acquaintances”) and create new agents. At any given time, the agents do not have an overall vision of the system, and only have a local point of view regarding the elements;
• – message forwarding: when an agent sends a message, it specifies which agent the response to the message should be sent. It may indeed be the agent which sent the original message, but it may just as well be another agent, specially created for the circumstance.

The agents have a more or less precise knowledge of the other agents in the system. They must be aware of and represent the abilities of those agents, and the tasks being performed at any given moment, the intentions and commitments of the agents. This aspect of matters raises the problem of the representation of this type of knowledge, and also of its updating.

The principle of task allocation constitutes one of the essential points relating to multi-cognitive-agent systems. A problem is composed of a certain number of tasks, performed by agents which bring together all of the partial solutions to obtain the overall solution (see Figure 3.12).

To successfully allocate the tasks, we need to know the skills of each of the agents, decompose a problem into sub-problems, distribute the solving activities to the appropriate agents and, as required, redistribute those activities dynamically.

Task allocation models can be classified into two categories:

• – centralized allocation: in this modular approach, an agent breaks down a problem into sub-problems and distributes those sub-problems to other agents, which are subordinate to the original agent. In this case, the actions are consistent, but there is a problem of reliability and extensibility. In addition, an agent is entirely dedicated to the distribution of tasks. Thus, the system is not used to the full extent of its capabilities;
• – decentralized, or distributed, allocation: each agent is capable of breaking up its own problem into sub-problems and thus distributing the tasks associated therewith. All the agents carry the same weight in the decision-making process. This type of allocation is appropriate for applications which already have a distributed structure. The reliability and the possibility of extension are better than with the previous model, but it is more difficult to maintain consistency.

Three types of methods may be employed to decompose a problem:

• – static: with each agent knowing the skills of the other agents, the sub-problems can be attributed to the best-qualified agents;
• – dynamic: the agents work together to distribute the sub-problems in the most effective way possible;
• – mixed: each agent is aware of the skills of the other agents, but this knowledge is periodically updated.

The autonomy of the agents is founded on the concept of intentionality. We can differentiate intention in an action from the intention to commit an action in the future. In the latter case, we have a standing goal. In order for an agent to have the intention to perform an action, that agent must believe that the action is possible, envisage committing to performing it, estimate that if certain conditions are fulfilled then the action can successfully be carried out, and finally, not attempt to bring about all of the consequences. However, we may well wonder what happens when the action has been carried out by another agent, when an agent has two intentions in the conditions in which an agent can give up on its intention.

3.8. Reactive agent systems

A reactive agent does not have an explicit representation of its environment, and cannot take account of its past. The way in which it operates is simple, following a set of pre-programmed stimulus/response-type decisions. The system’s organization is biological, and the number of agents present in such a system is very high. Communication is non-intentional. For example, the agents leave traces of their presence, or signals, which can be perceived by other agents. We then speak of environmental communication.

This type of agent results from the following postulate: the interaction of a large number of simple agents can emerge from complex organizations.

We can consider various levels of complexity for a reactive agent:

• – stimulus/response: simple reactions to the environment;
• – coordination of elementary actions: inhibition mechanisms, relations between elementary actions;
• – reactive cooperation: mechanisms of recruitment between agents, aggregation of elementary agents;
• – reproduction: mechanisms of reproduction of reactive agents;
• – organization of reactive agents.

Eco-resolution is a problem-solving technique based on the use of reactive agents. Here, problem-solving is considered to be the result of a set of interactions. This view stands in opposition to those adopted in conventional approaches to problem-solving, such as space state exploration, which poses problems of combinatorial explosion.

The distributed problem-solving approach is based on a radically-different idea: that of the appearance of configurations as stable or steady states of a dynamic system, whose evolution is due to interactions stemming from the behaviors of small, fairly simple agents.

In conventional systems, all the data are contained in the statement, with the system bound to find how to pass from the initial configuration to the final state. On the contrary, with the phenomenon of eco-resolution, the determination is purely local. The agents are characterized by behaviors of satisfaction, attack and retreat. The problem itself is defined by a population of autonomous agents, all seeking satisfaction. The final result is the consequence of a non-deterministic interaction. The model defines the combination of behaviors.

In conclusion to this section, we can argue that the study of learning, real-time operations or distribution, corresponds to a need in the area of network management. However, it is the last point which seems to hold the greatest interest, in that multi-agent systems, in a manner of speaking, constitute a generalization of the techniques of expert systems. Thus, they provide added value to conventional AI systems by offering a new type of architecture, involving communication as well as internal reasoning. The aspects of opening and distribution make them interesting for a network management system.

As regards the real-time aspect, the approach adopted by AI seems less clear. Nevertheless, it is a crucial step in the design of a network administration system. Indeed, the response times (to a failure, for example) must be as short as possible, although this criterion is not as important here as it is in decision-support or command-support systems.

Learning remains the Achilles’ heel of knowledge-based systems. As long as these systems are unable to improve, expand and refine their knowledge on the basis of their own experience, they will be dependent upon the goodwill and availability of experts and the quality of a manual update.

3.9. Active networks

Active networks are similar to other packet- and frame-transfer networks. The basic unit transferred in these networks is the packet. The role of the nodes is to examine the different fields in the packet, which are placed in accordance with a very rigid predefined system. In particular, the address field determines the output port. The different fields in the packet are interpreted by a virtual machine. We can consider that this virtual machine is a packet interface, which is typically called a “network API”, or “NAPI” (Network Application Programming Interface). For an IP network, the IP API is the language defined by the syntax and semantics of the IP header. In typical networks, virtual machines are fixed and the language used is basic.

With regard to active networks, we can say that the nodes provide a programmable NAPI. If we consider that, in an IP network, the header of the packet provides the input to the virtual machine, we can define an active network as one in which the nodes possess a virtual machine that executes the code contained in the packet headers.

Numerous categories of active networks can be defined on the basis of the following attributes:

• – expressive power of the language, which determines the degree with which the network will be able to be programmed. The language can range from simple orders to very highly-evolved languages. The simpler the language, the shorter the computation time. Conversely, the more powerful the language, the greater the degree of customizability that can be implemented;
• – possibility of defining a stable state on the basis of the previous messages in the same stream, so as to increase the rate of execution without having to redefine a state of the virtual machine;
• – granularity of control, which enables us to modify the behavior of a node for all packets that pass through it, regardless of the stream to which that data packet belongs, or, at the other extreme, to modify the node’s behavior only for the particular packet being processed at the time. All intermediary cases may be found – in particular, common behavior on the same stream or on the same set of streams;
• – means of giving programming orders: it is possible to consider that the orders are given to the active nodes by specific packets – e.g. signaling packets – rather than being indicated in a more or less highly-evolved language in the packet header;
• – architecture of the nodes, to examine the level of this architecture at which the commands come into play or, in other words, the level at which the programming interface is situated. The architecture can influence the choices of software and hardware. In particular, they can use reconfigurable processors, at higher or lower conceptual levels.

The functions of the nodes of active networks are shared between the runtime environment and the node’s operating system. Figure 3.13 illustrates such an architecture of an active network.

It is possible to send commands to the runtime environment using an encapsulation protocol, called ANEP (Active Network Encapsulation Protocol). The header of an ANEP packet contains a field identifying the type of packet. Several runtime environments may be present in an active node; the address of the node requires an additional address.

The existing interfaces include:

• – the interface of access to the runtime environment;
• – the interface between the runtime environment and the node’s operating system;
• – the interface of access to the node’s operating system.

3.10. Programmable networks

Programmable networks form part of active networks, whose role is to develop a set of software abstractions of the network resources, so that we can access these resources by their abstraction.

The objective of these networks is to render the nodes programmable so as to adapt them to the user demands and the required services. The programming commands, which may be sent either through a signaling network or by user packets containing control programs, can attack the nodes at different levels of abstraction. The IEEE has set up a working group with the purpose of standardizing these interfaces.

3.11. Autonomous networks

The concept of an active and programmable network is gradually being supplanted by that of an autonomous network. An autonomous network is a network which does not need a management center or control center to make its decisions. Thus, an autonomous network is a network that can decide for itself how it will behave. This is a concept which was introduced for NGNs (Next-Generation Networks), whose aim is to replace all existing networks by a single IP network, thus integrating all communication media.

An autonomous network must be capable of managing itself, detecting problems, repairing itself and controlling itself when no communication is possible.

The network elements themselves must participate in the construction of an autonomous network with diverse properties, such as resource optimization, context awareness and automatic organization of security. The objective is to understand how to learn which are the right decisions to make, what influence the different elements of the network have and, more generally, how to optimize the network’s behavior. The tools to create this type of autonomous system are drawn from multi-agent systems, which we discussed above.

Self-organization of an IP network first requires an overall view of the network and an understanding of the consequences of any event that happens in the network. Then, the network must be capable of reacting to that event.

Autonomous networks can be designed on the basis of networks other than IP for very specific objectives, such as networks with critical missions or interplanetary networks, wherein the control center takes so long to communicate with the probes that it becomes impossible to make decisions in real time.

3.12. Autonomic networks

Now we come to autonomic networks which, by definition, are autonomous and spontaneous networks. They are the networks which we defined earlier, but with an added property of spontaneity – i.e. they are real-time systems: the process is capable of reacting autonomously and within an acceptable time-lag.

Figure 3.14 offers an initial illustration of the definition of autonomic networks.

Autonomic networks are capable of self-configuring to adapt dynamically to any changes in the environment, of self-optimizing to ensure their operational efficiency is always optimal, self-repairing to ensure it is highly reliable, and self-protecting to ensure the security of the resources and information passing through it.

To perform these different functions, autonomic networks must have a certain number of attributes:

• – self-awareness;
• – environment awareness;
• – self-monitoring;
• – self-adjusting.

To achieve these objectives, we need to change the architecture of the networks. Thus, autonomic networks offer a new form of architecture with four planes, where a knowledge plane is added to the usual three: the data plane, the control plane and the management plane. The difference with the SDN architecture stems from the division of the control plane into two sub-planes – the knowledge plane and the control plane itself. The management plane is also an additional plane in this architecture, but it is integrated into the virtualization plane where each software network has its own management plane.

Figure 3.15 illustrates the new architecture of autonomic networks. The purpose of the knowledge plane is to collect all of the knowledge in the network and, for each point in that network, obtain a fairly universal view. The difference with the SDN architecture, here, is that the knowledge is centralized at a single point rather than distributed to each point.

The purpose of the Knowledge Plane is to run the control algorithms found in the Control Plane, which controls the Data Plane, which corresponds to the first four layers of the conventional network architecture. The Management Plane is responsible for the administration of the other three layers.

The objective of the knowledge plane is to render the network more intelligent by enabling it to understand its own behavior, which gives rise to a new generation of protocols. Up until now, every control algorithm (routing, quality of service, security, reliability, etc.) has had to go looking for the elements it needed, by itself. For example, a routing algorithm such as OSPF looks for the state of the upstream and downstream links to the input and output points of the network. This information can be exploited by other algorithms, such as an algorithm monitoring QoS, congestion or indeed admission to the network. Using a knowledge plane, this information is found in that plane, and each control algorithm can go in search of it as and when needed.

In time, the standardized protocols should be altered to take account of this knowledge plane. Another advantage of the knowledge plane is the possibility of using information, for a control algorithm, which would not have been able to be taken into account by the normal algorithm.

3.13. Situated view

Evidently, it is important not to make the network too cumbersome, so as to be able to transport knowledge of all kinds, and in vast quantities. With this in mind, there are two possibilities: either to centralize the knowledge, as the SDN architecture does, or to distribute it as widely as possible, making just enough knowledge available, at each point, for decisions to be able to be taken. The distributed solution comes from the situated view technique.

“Situated views” come from the world of artificial intelligence and indicate the integration of pieces of knowledge that are situated in a given view. Thus, we can define a situated view by the number of hops necessary to find the information – e.g. one or two hops, etc.

Figure 3.16 shows a one-hop situated view.

The one-hop situated view exhibits the advantage of being very easily scalable, because the transport of the knowledge is limited. This does not mean that the knowledge cannot diffuse through the network, because a point that receives a piece of knowledge integrates it into its own knowledge base and forwards it on to its neighbors. This knowledge, however, is less fresh than if the situated view were a little larger.

Thus, it is necessary to optimize the situated view depending on the knowledge needed by the control algorithms. With this in mind, we need to answer the questions: which, where and why? “Which” refers to the knowledge necessary to optimize an algorithm; “where” relates to the span of the situated view; and “when” indicates the refreshes needed for that knowledge to be usable. On the basis of these different parameters, it is possible to generate situated views that are a little more complex than the simple one-hop definition, including the information of links and all the seconds.

Until 2008, networks were remarkably static, and a network engineer often needed to be present to deal with things when a problem arose. In the case of very large networks, tens of network engineers could be needed to perform maintenance and deal with the diverse problems that emerged.

The objective of self-adjusting networks is to offer automated piloting of the network by a program capable of managing the control algorithms in a coordinated manner, and thereby optimize the network’s operation.

At the start of the 2000s, an initial attempt was made, consisting of using programmable networks and active networks. The research was not entirely conclusive, for reasons of security and cost. A new generation was launched in 2005, with the autonomic networks we have just presented.

3.14. Conclusion

The Cloud requires centralization, with its huge datacenters capable of handling enormous masses of data and of computing forwarding tables for a very high number of data streams. Unfortunately, this solution is not entirely satisfactory, because the reaction times are long, and reliability and security pose numerous problems, which considerably increase as the networks become more complex. This is the reason for the advent of distributed solutions using far smaller datacenters, much nearer to the users. However, this type of architecture requires a greater degree of intelligence to coordinate the set of controllers.

Slowly but surely, intelligence is being included in networks. This intelligence covers communication, reasoning and decision-making. Multi-agent systems provide the mainstay of this intelligence, which is able to make control- or management decisions when required. We are only at the very beginning of the story, but intelligence has already been omnipresent for a number of years at time of writing.

This intelligence can be exercised from huge interconnected datacenters. In this case, it is centralized for the management and control of a sub-network. The interconnection of those sub-networks requires a greater degree of distribution. When the networks are controlled by datacenters of all sizes, the intelligence will need to be very widely distributed.

Whilst intelligence serves to control the networks, it also has other impacts. In particular, security is one of the main beneficiaries of this intelligence. For example, an intelligent component, such as a neural network, is capable of analyzing what a person enters on a keyboard and shutting down communication if that input is not recognized.

Intelligence in networks, therefore, is a vast field for R&D, which should lead to the implementation of a much greater intelligence in all domains relating to telecommunications. Another underlying vision is that of the reduction of the costs in terms of specialized personnel for surveillance, maintenance and, more generally, all the operations necessary for the survival of a network. It should become possible to reduce the number of engineers and technicians in the networking field by 50-80%, and thereby make substantial savings. However, it should be noted that new professions will emerge, with architects and high-level engineers associated with the domain of networks.