Business-driven Network Management

Building Autonomic Network Management Solution

• Allow the Business to drive the Services that the Network provides
• Provide all involved constituencies with the information they need
• Separates concerns (technology) but integrate solutions (concepts)
• Enable easy design, development, deployment and runtime maintenace for simple and comlex Autonomic Management Systems
• Develop a blueprint for product development and packaging
• Integrate activities that lead to Autonomic Management Systems

Phase 1 - Technology Neutral

Step 1: Architecture - describes the structure of a system by means of Atoms (building blocks), their external visibility and their relationships.
Step 2: Model - is the representation of a system of atoms (or phenomena, processes) as a simplified abstract view of (complex) realirty, usually focusing on a well-defined aspect

Phase 2 - Transition

Step 3: Design - is the process of originating and developing a plan for product(s), structure(s) and/or component(s) with intention.
Step 4: Development - is the translation of requirements into software (or software components, including activities that results in software products such as new development, modification, reuse, re-engineering and maintenance

Phase 3 - Technology Specific

Step 5: Deployment - comprises all activities that make a software product available for use or transformation of a sfotware product from a packaged form into an operational state.
Step 6: Runtime - covers the duration of execution, from beginning to termination.

Autonomic Management Architecture - FOCALE

Foundation, Observation, Comparision, Action and Learning Environment

• Accommodate Legacy Components
• Provide a means to orchestrate Behaviour of Autonomic Components
• Ensure that all Autonomic Components adjust their Functionality in Unison, according to Policy
• Provide a Means to Reason about the Environment and recommend or take appropriate Actions, so that the underlying Business Goals are not violated and, hopefully, optimised

Basic Autonomic Network Control Loop

Autonomic Manager gathers Vendor-specific data from Managed Resource, analyses date to ensure that the Managed Resource provides appropriate Services and Resources, maintains the Loop and takes Actions to Reconfigure and Re-analyse if necessary
Model-based Translation Layer mediates between the Autonomic Manager and legacy Managed Resources and harmonises the different Languages and Programming Models of today's and tomorrow's heterogeneous Networks

Managing Autonomic Components

Externalise Control Function enables independet Control over the constituent Elements of the Control Loop, thus we move the Autonomic Manager outside the control loop.
Policy Manager translates business requirements into a form that can be used to configure network resources.

Orchestrating Behaviour

Fuse Information Models, Ontologies and Machine Learning and Reasoning Algorithms to enable Semantic Interoperability between Different Models.

Information Model - DEN-ng

Directory Enabled Networks - next generation

• Models Products, Services and Resources and their Relationships
• Uses classification Theory, Patterns and Roles, for example
  - Capabilities (normalised funcationality; device/vendor-independent)
  - Constraints (restrictions on what functionality can be used) and
  - Context (environment in which objects operate and rules apply)
• Uses State Machines to orchestrate Behaviour of Managed Resources
  - Models Lifecycle of Managed Resources (State)
  - Orchestractes Behaviour using context-aware Policies

Benefits

- common Terminology for representing Management Information,
- unified Information both within and between Enterprises,
- bridge between Constituencies, such as Business and Network workers, and
- maintaned Definitions that are understandable by all constituencies.

Abstractions provided by DEN-ng

- Entities vs. the Roles that they take on
- Reusing Patterns independent of Domain (i.e. Product, Service, Resource)
- Capabilities to abstract functionality vs. an individual function or a set of functions
- Physical Resource vs. Logical Resource
- Customer Facing Services vs. Resource Facing Services
- Structural Representation of a Policy Rule vs. Content Definition of a PolicyRule

Fundamental Patterns

Composite-Atomic Pattern builds Hierarchies using Atomic and Composite Subclasses, analogous to File System Structures
Role Pattern separates Concerns by differentiating Characteristics and Behaviour of an Entity, and Functionality that an Entity can assume and allowing for additional roles without structural changes to the model

Design - ADS

Architectural Artifacts for Distributed Systems

• Integrates Management with System Design and Specification
• Offers a Set of Concepts and Tools that help to develop Autonomic Management Systems
• In short, ADS is about an specific Architecture, a Design Model, a number of Domain Specific Languages and Tools for Editing Specifications and generate structured Text (i.e. code)
• Defines three fundamental Artefacts: Element (Unit of Deployment), Contract (Unit of Interoperability) and Policy (Unit of Governance)

Element as the Contractually defined Unit of Deployment

Combination of two distinct Perspectives (abstract) Architectural abstraction (expressing design rules) and Implementation (deployable package)
Composition of Functionality depending on Domains (group Elements for Administration), Facilitiy (coherent Set of functional Capabilities of an Element) and Contracts (Interoperability of Functionality)
Categorised as domain-specific service or general (platform) service
Must be independently manageable or self-managed
requires/provides Facilities, a coherent Set of functional Capabilities in Form of Signatures (Operations and Set of Terminations)

Contracts

Combines Business perspective with Design, Development and Deployment aspects
Defines how Functionality can or must be accesse and documents Obligations and Benefits
Fundamental to understand a Software System, becuse analysis with Contract Specifications and Instantiation can answer important Questions, such as: Is Software Artifact Y similar/comparable/related to Software Artifact X? Are there duplicate Software Artifacts in the Solution/Application? What is the Impact of one Software Artifact on another? What are current Dependencies (directly/indirectly) between Software Architects? What Instances are related to each other ('how', 'why')? What Software Artifacts represent a Compostions? What Software Artifacts are 'composable'?