Towards a Unified Architecture for Resilience, Survivability and Autonomic Fault-Management for Self-managing Networks

Abstract

The emergence of self-managing networks can be seen as an enabler for increased dependability, reliability and robustness of the network layer. All these features are significant for the services and applications relying on the network infrastructure. This paper explores the links between traditional Fault-Management functions belonging to the management plane and the fundamental network functions for Resilience and Survivability embedded inside the protocol modules of a node/device. This results in an architectural framework that allows nodes/devices to implement the converging aspects of Fault-Management (now becoming autonomic), Resilience and Survivability in a self-managing network. The components and adaptation mechanisms of the proposed framework will make the network layer more robust and application/service aware. Thus, the dependability, reliability, and adaptability of the upper layer services and applications are expected to increase.

A hybrid management substrate structure for adaptive network resource management

“…the cooperative, selfish, punishment and mixed behaviors. Communication models between network entities to support management tasks have also been considered in [7] in the context of autonomic networks. In this work, the interaction between the decision elements relies on a hierarchical structure in which the decisions taken by each decision element are orchestrated by one or 978-1-4799-0913-1/14/$31.00 c 2014 IEEE more "arbiter" elements that are in charge of detecting potential overlapping or contracting actions and configurations.…”

Managing the future internet through intelligent in-network substrates

“…In the example, source nodes n1 and n2 both contribute to the load of link l [5][6] , (Figure 3(a)) which becomes the most utilized link in the network. If both ingress nodes react by performing reconfigurations locally, more traffic will be routed towards link l [3][4] (as alternative paths to reach their original destinations) which can then become overloaded (Figure 3(b)). To avoid such inconsistent decisions, only one source node is allowed to perform splitting adjustments at any time in an iterative way until no further improvement can be achieved.…”

An Empirical Evaluation of a Shim6 Implementation

“…Our primary goal in this work was to get a baseline performance metric for an existing Shim6 implementation, and then to integrate Shim6 into the overall EFIPSANS architecture [11]. While Shim6 is already somewhat autonomous, in that it can detect and recover from link failures, we augmented LinShim6 with functionality to allow third party code to directly inform the Shim6 implementation which locators it should use.…”