Network Resource Modeling

Overview

In the M2 milestone, ZipTie introduces an extensible network resource model for describing network devices, their physical structure, and their configuration. Network equipment providers and advanced network engineers and designers will be able to completely model the structure and the configuration of network devices and the components from which they are constructed. As opposed to a least common denominator model that applies to every device, the end result is a rich resource model that encourages fully developed descriptions of both the physical and logical configuration for network devices through the use of an extensible model. Coupled with ZipTie's open plugin architecture and collection of common network management tools, resource specific tools can be easily added to help report and manage the entirety of a network's devices.

Modeling Background

The term model is very overused in computing and as a result, confuses many conversations due to the various definitions. Sometimes the term model refers to a facsimile or reproduction, most likely not to scale, of a real object or system. An example is a plastic model airplane. In another example using this definition, a model would refer to an instantiated object hierarchy defined to represent an existing, “real”, network device.

In other uses, the term model refers to the structure or the rules that make up another system. Sometimes this is called a meta-model (a model nonetheless). A schema is frequently called a model (or meta-model) as it is a representation of how data is organized in a document or database (sometimes people call a schema a data model). Similarly, people use the term model to represent a domain specific ontology.

In the case of ZipTie, we are using the term model to refer to a meta-model that describes a network resource's physical and logical configuration. In particular, we have chosen to use XML Schema as the modeling "language" to describe this schema. The reasons are long and varied, but it boils down to a few main reasons. SML defines resource modeling as the model of all resources, which comprise a "service". For ZipTie, we formally define the model as any resources that comprise the configuration or inform configuration. By this definition, ZipTie's Network Resource model is config centric.

Fast Formal Facts about SML

From Wikipedia

The Service Modeling Language (SML) provides a rich set of constructs for creating models of complex IT services and systems. These models typically include information about configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and so on. Models provide value in several important ways.

1. Models focus on capturing all invariant aspects of a service/system that must be maintained for the service/system to be functional. They capture as much detail as is necessary, and no more.
2. Models are units of communication and collaboration between designers, implementers, operators, and users; and can easily be shared, tracked, and revision controlled. This is important because complex services are often built and maintained by a variety of people playing different roles.
3. Models drive modularity, Re-use, and standardization. Most real-world complex services and systems are composed of sufficiently complex parts. Re-use and standardization of services/systems and their parts is a key factor in reducing overall production and operation cost and in increasing reliability.
4. Models represent a powerful mechanism for validating changes before applying the changes to a service/system. Also, when changes happen in a running service/system, they can be validated against the intended state described in the model. The actual service/system and its model together enable a self-healing service/system – the ultimate objective. Models of a service/system must necessarily stay decoupled from the live service/system to create the control loop.
5. Models enable increased automation of management tasks. Automation facilities exposed by the majority of IT services/systems today could be driven by software – not people – for reliable initial realization of a service/system as well as for ongoing lifecycle management.

A model in SML is realized as a set of interrelated XML documents. The XML documents contain information about the parts of an IT service, as well as the constraints that each part must satisfy for the IT service to function properly. Constraints are captured in two ways:

1. Schemas – these are constraints on the structure and content of the documents in a model. SML uses a profile of XML Schema 1.0 as the schema language. SML also defines a set of extensions to XML Schema to support inter-document references.
2. Rules – are Boolean expressions that constrain the structure and content of documents in a model. SML uses a profile of Schematron and XPath 1.0 for rules.

Once a model is defined, one of the important operations on the model is to establish its validity. This involves checking whether all data in a model satisfies the schemas and rules declared.

The SML specification focuses primarily on defining the profile of XML Schema and Schematron used by SML, as well as the process of model validation.

XML Schema and Resource Modeling

ZipTie has taken an XML schema based approach, which is SML compliant. XML Schema is a means and the 'end' for ZipTie. Many standards end up tangled in thier technology choice and do not focus on solving the problems. Here are the practical set of reasons which drove the choice of XML Schema:

• XML Schema is understood by many people and there are tools (including in Eclipse) that support the development of XML Schema documents (XSDs), constructing instances of these documents, and the parsing and processing of the instances.
• For better or worse, XML Schema was chosen by the ietf committee as the means to describe network configuration in Netconf (see rfc 4741 for details).
• XML Schema (plus Schematron) is the basis for the emerging Service Modeling Language (SML) being pushed by computing and networking companies such as IBM, BEA, BMC, CA, Cisco, Dell, EMC, HP, Intel, Microsoft, and Sun. Resources described in XML Schema are easily incorporated into a larger SML model.
• ZipTie leverages code that already supports XSDs, although in a less extensible manner.
• Many tools support some form of XML as an import/export format for integration and interoperability purposes.

Model Organization

A resource model of a network device consists of a single XSD that utilizes some core and common elements from ZipTie. Each model must provide a network resource document that conforms (in this case, extends) to the ZipTie NetworkResourceDocument^? type. A device's network resource document can include configuration files, a description of the device's physical platform, cards inserted into the device, and any configuration elements in ZipTie's common model or types introduced specifically for the device by its manufacturer or a network engineer. The device adapter is responsible for providing an instance of this XSD when a backup request is initiated.

The following Wiki pages describe the ZipTie resource model types that all device models are built upon.

• Tutorial on how to create extensible device models using XSDs
• A walkthrough the core and common model in ziptypes.xsd