Network Management Page 1
XMLNetMan Introduction...

Project Contents

[Page 1]
The Project and Aims
Conceptual Overview
System Structure

Page 2
Service Constructs
Variables
Constructs Libraries
Function Calls

Page 3
Introduction
Rule Specification
Pre-Processor Output
Example Restrictions

Page 4
Specification
Implementation
Limitation Detection

Page 5
Simulation
Documentation
Examples
Prototypes





 Network Management using Abstracted XML Specifications

 Project Introduction

Establishing and managing network infrastructures between distributed nodes can be time consuming and risk prone. Such a statement is often re-enforced by the incorporation of new technologies, the merging of existing systems and the rotation of subsystems. However, the functional requirements of these enterprises remain constant, even though implementation specifics may differ greatly.

The driving force behind this project is to investigate the addition of an extra level of abstraction between the operation and implementation of such nodes within distributed environments. Such an abstraction has the advantage of being sufficiently withdrawn from specific node level details to allow subsystems to be interchanged, whilst maintaining the required behaviour. Utilising these high level descriptions, being specified in a generic syntax, a scope for simulation is introduced. Automated analysis could attempt to model the interactions between nodes and subsystems, leading onto validation of security, performance and scalability.

The abstracted descriptions of the services should not be simply a static description of the rules, but include functionality to enable more complex interactions. It will allow dependencies to be created between configuration segments, so that where necessary, the description of one service can be automatically generated taking into account the configuration of other nodes and components.

See my project brief here.

 Overall Goals

  • Provide a method of allowing users to gather and display structural details about nodes and links on their local area network.
  • Allow the specification of network services and configuration for each required node on the network. The actual behaviour will be generalised so that it reflects the various different implementations and versions of that service available on different platforms.
  • Store the state of the network layout and the service descriptions of each node to a series of XML files. These give an abstracted description of the system as a whole, allowing it to be restored and analysed at a later date.
  • The XML node descriptions can then be parsed and converted into sets of configuration files specific to the required operating system and service types.
Goto Top
Downloads

Read more in the prototypes section of this document, or grab the whole package using the following link.

Grab Source







Information

This is my Third Year project, part of my four year Software Engineering degree at the University of Southampton

The project started October 2001, and will end early May 2002.


 Conceptual Overview

Consider the management of network nodes within a local area network. Typically within such an environment, different implementations of subsystems are used, mainly for reasons of security, performance and fit for purpose. Such implementations may differ by being based on varying operating systems, or using a different 'off the shelf' solution. Due to this, there is commonly a mismatch between the processes undertaken to manage such solutions.

The goal is to insert a level of abstraction between the configuration files and the desired protocol behaviour. With this, translations can be constructed describing the process of mapping between the standardised abstracted description and lower level configuration files. Utilising these descriptions and translations, nodes can be effectively interchanged, whist still maintaining the desired behaviour of the subsystem.

 Scope

The project covers many aspects relating to network service management. Detailed abstracted descriptions of common network services must be created to act as the core of the system, with the ability to convert to and from the base level configuration files. Network analysis and simulation can be carried out to establish the underlying layout, and this will involve low-level inspection of the network itself. The actual abstracted configurations themselves should include added functionality to aid the management of the system, such as being able to include rules defined within a common library.

Once a detailed description of nodes and their services has been created, the possibility of simulation is introduced. Taking the firewall example, using the XML description and a simulator, the system could run through the rule set. During this process, analysis could be made to establish the sequence of packets that could pass through the firewall. Assuming the abstracted description is rich enough, and the translations to end level implementation maps all functionality required, the firewall configurations generated should behaves as the simulator originally suggested.

For more details on the scope for simulation see this section.

Goto Top




Useful Stuff

Find out more about XML and XSL at http://www.w3c.org.

These are the two main technologies I am using in my project.


XML v1 Second Edition
XSL Transformations v1

For parsing XML, and doing the XSL translations I'm using the Xerces and Xalan applications from Apache















Documentation

I will be doing various bits of formal documentation during the project.

Initial Project Brief

Mid Project Progress Report

Paper for BIS 2002

The above paper was written by myself and my project supervisor, and has been submitted as a work-in-progress report.

The paper has been accepted and will be presented at the Business Information Systems Conference 2002 (BIS 2002), Mobile E-business.

More Documentation on Page 5


















Slyware Logo

 System Structure

One of the main aims of this project is to provide a generic back end processor, to manage and generate the translations. I wanted to be able to hold all the services and translations within one system, and hence be able to interchange and add new services/translations with the minimum of effort. Ideally, a user should be able to add a new translation from service to implementation without having to change any code. With such a system in place, the whole configuration of a network could be centrally managed. If simulation could be performed to a sufficient level, this would provide a very powerful tool.

A conceptual overview of the system
  1. Initially the configuration of the services is entered into the system using a GUI editor.
  2. A set of XML documents can be generated, describing the desired behaviour of all services within a node.
  3. There is a possibility of carrying out simulation and analysis on the configurations. This may lead to improvements in the overall conceptual design, hence feeding back into stage 1.
  4. With the desired node descriptions, we wish to test whether there are any restrictions in the conversion process to implementation level configurations.
  5. Implementation level configuration files can be generated using the service translations, and be fed directly into running nodes.
  6. With all the XML descriptions of the nodes together, it provides a rich source of data about the whole enterprise, which can be fed into other applications.

The system to be implemented within the scope of this project will provide the functionality to read in abstracted configurations, modify them and store back to XML. In addition to this, the system should provide a level of advanced behaviour prior to configuration generation, such as variables, constructs and function calls (see page 2).

The system will then be able to generate implementation level configuration files using the translations specified for each service type. To aid the manipulation of the data, a GUI editor will be created. This will allow all services and nodes to be configured, and translations executed.

 System Components

A LAN will be represented by a series of networks or subnets. Each subnet can contain many nodes, and will have it's own subnet mask and global variables. Nodes can be connected by links. These links are specified at an abstracted level, hence they do not necessarily represent physical links.

Each node within the network is represented by a single XML file. This file contains an initial section describing that node, such as interfaces, assigned IP addresses and so forth. Within each node there are a series of Service descriptions, which are the abstracted specifications themselves.

Each Service description is validated by it's own XML schema. The actual description is designed to be as generic as possible, hence giving details that will cover a wide range of implementations. For example, a service description of a firewall could be created. This would specify the construct of rules and the options that could apply to them. A series of translations would then be constructed, which would specify how to convert a rule of the abstracted service configuration into IPFW rules for FreeBSD, and another one for IP Filter and so on. The idea is that with detailed translations, you could generate firewall rules for IPFW, and then automatically generate rules for IP Filter, without having to make any changes to the original XML description. Upon application of these two configurations, they should behave the same.

The next element of the system is the translations. These describe how to convert from an abstracted service description to a specific implementation of that service. Using the previous example, there would be a translation from Firewall service to IP Filter. The actual translation is specified using an XSL, XML stylesheet. These give the mappings from elements within the system to actual implementation level configuration elements. Along with the XSL file will be another XML wrapper file. This provides general information about the translation, such as limitations and any other details that cannot be expressed in the XSL file itself.

 Object Structure

Overview of the object relationships

As previously mentioned, I wanted the system to be able to expand to allow new services and translations easily. For this reason I spent a large amount of time getting the object structure able to provide this level of expandability.

Each element within the system is responsible for it's own XML parsing, and XML generation. Such behaviour is inherited from the NetworkElement class, which is the parent to most entities within the system. This defines some basic operations performed to parse and generate XML data. Using such approach ensures that all entity functionality is encapsulated within a single object, hence allowing other objects within the system to reference it generically. On initial parsing, for example, when a Firewall description is located in the node XML file, a new FirewallService object can be created, and further XML parsing passed onto it.

All Service translations are held within a central repository. They can be loaded dynamically, from the source XML and XSL descriptions. When configuration files need to be generated, a reference of a specific translation is passed to the service, and its end level configurations can be generated on the fly.

Goto Top

Page 1  2  3  4  5  >>