Time has come for OpenNaaS to interact with networks. Users are willing to configure links and network protocols (e.g: RIP, OSPF) using a network approach, so network support should be added to OpenNaaS. Within this context, a question has raised in the development team: How do we describe a network and its topology? There are several options here, but we’ve decided to take NDL to build a network model that suits our needs.
In this post, you may find information about what NDL is, what makes it interesting for OpenNaaS, and what are the benefits and payload to adapt a tool like OpenNaaS to NDL.
This ontology is able to describe state and capabilities of multi-layer networks, using a technology independent model. NDL may represent a network as a graph with nodes representing either devices or whole domains, but it provides a much richer schema which allows the description of devices, interfaces, domains, adaptations and more. The inclusion of adaptations allows explicit descriptions of multi-layer networks, including hybrid networks that combine technology such as Ethernet, SONET (Synchronous Optical Network) and WDM (Wavelength Division Multiplexing) in the same infrastructure.
NDL schema consists in a set of core schemas that can be used to describe networks topology and behaviour. Each supported technology is described in a different schema (the so called technology schemas) in order to maintain core independence from particular technologies. No need to say that new technology schemas may be created to extend the model if needed.
Just to have a quick view of an NDL model, core schemas are summarized in the picture below:
NDL schemas are described using the Resource Description Framework (RDF) syntax. These schemas are based mainly in three technologies: graphs, ITU-T G.805 functional elements, and GMPLS labels. The use of this flexible and extensible syntax may help to integrate NDL based models with other independent data models of other fields, when necessary.
As it has been seen, NDL provides a syntax to describe multi-layer and multi-domain networks, with independence of the technology used inside the network and its components. NDL syntax is RDF based and it is being used in multiple projects, many of them in the Netherlands (e.g: SARA and SURFNet) but also in the international organization GLIF.
NDL adoption motivation:
NDL is an interesting tool but it’s not the only one out there. The election of it for OpenNaaS network model is motivated by OpenNaaS context, together with user direct requirements.
As introduced here, OpenNaaS is a network management framework under development which is willing to provide an abstraction of networks and their components. Pluggable drivers may be implemented to support desired technologies, vendor specific equipment, etc.
A standardized network model is required for integration and cooperation with other existing software tools. There are other software component in DANA that may take advantage of a tool like OpenNaaS, specially if it is designed with flexibility and extensibility in mind. For these applications to easily integrate with OpenNaaS, a somewhat standardized and extensible network model should be used. Furthermore, there are other tools OpenNaaS may need to integrate or cooperate with. Several institutions may have advanced provisioning systems to manage their networks, and may not be willing to give OpenNaaS direct access to their network devices. Designing OpenNaaS to ease the cooperation with such advanced systems is key to offer connectivity services through non-directly administrated domains. A standardized model may help to reach those cooperation, reducing the amount of technical effort needed.
As a direct requirement, adopted model should be able to represent all needed data to implement OpenNaaS features. OpenNaaS aims to manage multi-layered and multi-protocol networks offering the user a technology independent view of them. Some of those networks may have multiple domains, each of one may be under a completely different administrative domain, with its rules and procedures. Provisioning bandwidth on demand (BoD) over these networks is a must for OpenNaaS, as it becomes the most required feature for its end users.
Hence, required model should be able to represent multi-layer and multi-domain networks and offering an abstraction of concrete technologies. It should also offer facilities to provide BoD. And, finally, should have an eye to standardization to ease integration and cooperation between OpenNaaS and other surrounding projects.
NDL has been compared with other network models, and has finally been chosen the one for OpenNaaS. CIM, IDCP and VXDL have been included in the comparison, among with other topology models. Finally NDL has been taken as the first option and, hence, adopted.
By adopting NDL, the development team aims to reduce the design effort and take advantage of existing tools to interact with it. Main advantage of it comes from re-using other people work and expertise by adopting solutions build after years of research and integrating them to our ones. On the other hand, NDL forces the definition of a new serialization scheme in order to transform NDL descriptions using RDF-XML to managed Java objects. That would be a task for the development team to work in. Finally, there is an opened question that only time may answer. It is the impact that may have to OpenNaaS the fact of NDL schemas not being definitive. Right now, we consider NDL mature enough to match our imminent needs, although we’ll consider to migrate to future NDL versions whenever they appear.
First results will be available in few months, and feedback will come from our users. Will see if it likes! Development team is cheerful with it!!
- ITU-T Recommendation G.805: Generic functional architecture of transport networks, Tech. rep., International Telecommunication Union (March 2000). http://www.itu.int/rec/T-REC-G.805
- [SA2.T5] GÉANT3, “Inter-domain topology model standardization”. Jordi Jofre, Eleni Trouva. (July 2010)