Common Network Information Service
Requirements Analysis
Table of contents
1.
2.
INTRODUCTION .................................................................................................................... 5
1.1
Purpose ....................................................................................................................... 5
1.2
Intended audience ....................................................................................................... 5
1.3
Motivation .................................................................................................................. 5
1.4
Vision ......................................................................................................................... 5
1.5
Scope .......................................................................................................................... 5
1.6
References .................................................................................................................. 5
OVERALL DESCRIPTION ....................................................................................................... 6
2.1
2.1.1
SA3: AMPS ..................................................................................................................................... 6
2.1.2
JRA1: Visualization and measurements points finding tools .......................................................... 6
2.1.3
JRA3: Bandwidth on demand (BoD) .............................................................................................. 7
2.1.4
JRA4 WI3: Cross Border Fibres Development ............................................................................... 7
2.2
User classes and characteristics.................................................................................. 8
2.2.1
cNIS Administrator ......................................................................................................................... 8
2.2.2
cNIS Application Developer ........................................................................................................... 8
2.2.3
cNIS Application ............................................................................................................................. 8
2.3
3.
Geant2 activities involved .......................................................................................... 6
Assumptions and dependencies .................................................................................. 8
2.3.1
Unix systems are preferred .............................................................................................................. 8
2.3.2
Read-only access to topology information for cNIS Applications .................................................. 8
2.3.3
Topology modifications using the cNIS Management Applications (cMA) ................................... 9
2.3.4
Network elements naming ............................................................................................................... 9
USE CASES ........................................................................................................................... 9
3.1
Software ................................................................................................................... 10
3.1.1
A1: Installation of cNIS base software .......................................................................................... 10
3.1.2
A5: Initial setup of cNIS ............................................................................................................... 11
3.1.3
A43: Extending network discovery functions with new features .................................................. 11
3.2
Common ................................................................................................................... 12
3.2.1
A21: Defining relationships between interfaces ............................................................................ 12
3.2.2
A22: Defining allowed relationships between interfaces .............................................................. 12
3.2.3
A32: Defining relationships between links ................................................................................... 13
3.2.4
A35: Defining relationships between layers which do not terminate on the same device ............. 13
3.2.5
A13: Inspecting audit trail information related to topology updates ............................................. 14
3.2.6
A16: Searching for specific topology elements ............................................................................. 14
3.2.7
A14: Customized topology data constraint checking rules ........................................................... 14
3.2.8
A17: Automatic supplementing the existing topology with new data ........................................... 15
3.2.9
A27: Modifying topology data through an API ............................................................................ 15
2
3.2.10
A30: Obtaining a network topology in the NDL format........................................................... 15
3.2.11
A15: Registering for periodic updates about topology changes ............................................... 16
3.2.12
A44: Holding an historical record of the actual topology......................................................... 16
3.2.13
A45: Managing historical designed topology ........................................................................... 17
3.3
IP .............................................................................................................................. 17
3.3.1
A2: Initial population of the IP network topology ........................................................................ 17
3.3.2
A7: Daily maintenance of the IP network topology ...................................................................... 19
3.3.3
A3: Manual editing of IP network topology information .............................................................. 21
3.3.4
A24: SA3 Pathfinding ................................................................................................................... 22
3.3.5
A4: Obtaining current IP topology information for a cNIS Domain ............................................. 22
3.3.6
A8: Obtaining a list of IP topology changes over a period of time ............................................... 23
3.3.7
A9: Obtaining historical IP topology information for a cNIS Domain ......................................... 24
3.4
SDH .......................................................................................................................... 24
3.4.1
A11: Obtaining SDH topology for a cNIS Domain ...................................................................... 24
3.4.2
A40: Manual editing of SDH topology information ..................................................................... 25
3.4.3
A41: Initial population of the SDH topology ................................................................................ 25
3.4.4
A48: Adaptation Ethernet-over-SDH ............................................................................................ 25
3.5
Ethernet .................................................................................................................... 26
3.5.1
A12: Obtaining Ethernet topology for a cNIS Domain ................................................................. 26
3.5.2
A39: Manual editing of Ethernet topology information ................................................................ 27
3.5.3
A42: Initial population of the Ethernet topology........................................................................... 27
3.6
OTH .......................................................................................................................... 27
3.6.1
A45: Ethernet/SDH signal transport over OTN ............................................................................ 27
3.6.2
A46: Analysing System Failure .................................................................................................... 28
3.7
Frame Relay ............................................................................................................. 28
3.7.1
3.8
A19: Obtaining FrameRelay topology for a cNIS Domain ........................................................... 28
ATM ......................................................................................................................... 29
3.8.1
3.9
A18: Obtaining ATM topology for a cNIS Domain ...................................................................... 29
MPLS ....................................................................................................................... 29
3.9.1
A28: Defining MPLS label switching information ....................................................................... 29
3.9.2
A29: Obtaining MPLS label switching information ...................................................................... 29
3.10
Inter-domain ............................................................................................................. 29
3.10.1
A20: Obtaining a pointer to the adjacent cNIS instance ........................................................... 29
3.10.2
A47: Establishing E2E Link for a cNIS Domain ...................................................................... 30
3.10.3
A10: Obtaining current E2E Link Topology for a cNIS Domain ............................................. 31
3.11
Application specific.................................................................................................. 32
3.11.1
A36: Defining stitching parameters .......................................................................................... 32
3.11.2
A37: Obtaining partitioned topology for a cNIS domain ......................................................... 33
3.11.3
A49: Network topology partitioning ........................................................................................ 34
3
4.
5.
3.11.4
A31: Obtaining pruned topology for a cNIS Domain ............................................................... 34
3.11.5
A34: Defining dynamic parameters for network topology elements ........................................ 35
3.11.6
A38: Checking existing Autobahn path .................................................................................... 35
3.11.7
A23: Obtaining information about neighbouring nodes ........................................................... 35
EXTERNAL INTERFACES ..................................................................................................... 36
4.1
User interface ........................................................................................................... 36
4.2
Communication interfaces........................................................................................ 36
4.3
Software interfaces ................................................................................................... 36
NON-FUNCTIONAL REQUIREMENTS .................................................................................... 36
5.1
5.1.1
B1: Security requirements ........................................................................................ 36
EduGain integration ...................................................................................................................... 37
5.2
B2: Migration to cNIS .............................................................................................. 38
5.3
B3: Service monitoring ............................................................................................ 38
5.4
B4: Maintaining the historical data .......................................................................... 38
5.5
B6: Persistence of the network discovery results ..................................................... 39
5.6
B5: Service registration ............................................................................................ 39
6.
GLOSSARY......................................................................................................................... 39
7.
OPEN ISSUES ...................................................................................................................... 39
4
1. Introduction
1.1 Purpose
The aim of this document is to present the requirements concerning the Common Network
Information Service (cNIS). It describes the motivation for building cNIS, its vision, scope,
the use cases arising from the cNIS-based applications and the services cNIS will offer.
1.2 Intended audience
This document is dedicated for a wide audience, including administrators of cNIS instances,
developers of cNIS-based applications from all involved GN2 activities, cNIS programmers
and testers, authors of cNIS documentation.
1.3 Motivation
Many of the applications developed within GN2 need network topology information in order
to function. Typically this is done, manually or automatically, by querying network nodes
(normally routers) and storing the responses in a suitable database. After the initial load of the
database, regular maintenance is needed to ensure that the database properly reflects the real
network.
Presently, there exist several GN2 topology databases designed and created independently for
different GN2 activities, which can cause many problems. First of all, having multiple
topology databases increases the load on network nodes and on the network administrators
who are to maintain the databases. More importantly, different modes of updating the
topology databases (manual, semi-automatic, automatic) can cause severe data
inconsistencies. Yet another problem is that when one topology database gets extended with a
new type of information (e.g. new field in the description of a router), activities using the
other databases will not be able to access the new data, unless they update their databases
accordingly.
One way of addressing the above problems is creating and deploying a common database,
accessible for all GN2 activities requiring network topology information.
1.4 Vision
The aim of the Common Network Information Service (cNIS) is to provide a unified
repository of all relevant network information about a single domain’s network infrastructure,
which client applications will be able to use in place of their internal topology information
storages. A cNIS instance is deployed, administered and owned by one cNIS Domain (see
chapter 6 for explanations of the acronyms used throughout this document).
1.5 Scope
cNIS is meant to model the infrequently-changing network topology. For this reason, storing,
retrieval and analysis of real-time networking data (e.g. measurement results, utilization),
which is handled by dedicated databases of the specific GN2 tools, is beyond the scope of
cNIS. Similarly, advanced visualization of the contents of the topology database, which is
implemented by separate GN2 tools, is not in the scope of cNIS.
1.6 References
This document references four other cNIS specification documents:
5
1. cNIS Export Interface Description, which specifies the interfaces through which the
cNIS data can be accessed by the applications.
2. cNIS Schema Specification, which describes in detail the cNIS database model
3. cNIS Software and Architectural Design, which covers all aspects related with cNIS
architecture and software model
4. cNIS Security Notes, which deals with security issues.
2. Overall description
2.1 Geant2 activities involved
Several GN2 activities have expressed interest in the cNIS including SA3, JRA1, JRA3 and
JRA4 WI3. Below we briefly describe the applications developed within these activities with
emphasis placed their possible relationships and requirements for cNIS.
2.1.1 SA3: AMPS
SA-3 activity is concerned with End-to-End Quality of Service (E2E QoS). In brief, the main
components of SA3 are:

The Advance Multi-domain Provisioning System (AMPS) that allows users to request
a given class of service for IP, end-to-end

A distributed performance monitoring system which is able to determine if service
guarantees are being met, and can be used to diagnose performance problems
A virtual organization, called the Performance Enhancement and Response Team (PERT),
which can be called upon by NRENs and perhaps other specific organizations, to help
troubleshoot network problems and to give specialist advice on performance issues. The
PERT will be permanently staffed during the working day, and uses its own Trouble Ticket
system and Knowledgebase to manage problems and disseminate information.
Collaboration of SA3 applications with cNIS
The main SA3 application that will use cNIS services is the Advance Multi-domain
Provisioning System (AMPS). Its Inter-Domain Service will query cNIS to obtain information
about the IP network topology of the local domain and find shortest paths between pairs of
interfaces in that network. The Intra-Domain Service will use cNIS to determine if the local
domain contains a node with given IP address and obtain pointers to cNIS services deployed
for adjacent domains.
2.1.2 JRA1: Visualization and measurements points finding tools
GN2-JRA1 is an activity that aims at finding a solution to monitoring network performance in
a multi-domain infrastructure. In order to achieve this goal over a wider environment, a
collaboration called perfSONAR has been setup with other important network entities of the
research and education community.
The main goal of GN2-JRA1 is to provide groups of users with the performance data they
require. To achieve this, the activity will develop and deliver a multi-domain network
performance measurement system which will allow retrieval of monitoring information from
multiple domains using a pre-defined format (GGF NM-WG schema). It will also develop
new visualization tools which make use of multi-domain data, including:

A multi-domain weather map for NRENs and/or for projects that want to perform data
6
transfer over the networks

A generalized looking-glass tool which can provide transparent access to monitoring
information from several networks for the NOCs.

A tool allowing the retrieval of monitoring information along a path.
Collaboration of JRA1 applications with cNIS
The main group of JRA1 applications that will use cNIS services is the perfSONAR
visualization tools, including the CNM tool and PerfsonarUI. They will access the cNIS to get
information about the topology of the network to be visualized, including lists of nodes,
interfaces and links between them. Additional JRA1-specific data, such as measurement
results, will be fetched from dedicated Measurement Archives (MA). For the presentation
purposes, the visualization applications will need to correlate the cNIS-acquired topology data
with the measurement results based on some common attribute (e.g. the IP address of a
network node).
2.1.3 JRA3: Bandwidth on demand (BoD)
The JRA3 activity is working towards a design and implementation of a multinomial
Bandwidth on Demand service. In order to automate the provisioning of such services, JRA3
has defined two entities to be deployed in each domain: Inter Domain Manager (IDM) and
Domain Manager (DM). IDM is involved with the intra-domain signalling and is unaware of
the internals of the network. The IDM’s operations are based upon an abstract representation
of the underlying topology that includes information on available resources in terms of
available bandwidth without technology-specific details. Domain Manager (DM) interacts
with the network elements or network management system to actually implement the service.
This implies that the DM needs to know the internals of the network and the technologies
(e.g. SDH or Ethernet) used.
JRA3 application suite, which was named initially as BoD, obtained a new name AutoBahn.
The terms BoD Domain Manager and AutoBahn Domain Manager, which are used in this
document, indicate the same software.
Collaboration of JRA3 applications with cNIS
The JRA3 software component that will interact with cNIS will be the Domain Manager
(DM). The DM, whose responsibility is intra-domain path finding, will contact cNIS to obtain
a detailed technology-specific topology of the cNIS domain.
2.1.4 JRA4 WI3: Cross Border Fibres Development
The JRA4 WI3 working group aims at the coordinated evaluation of the use of so-called
Cross-Border Fibre (CBF) for the provision of international connectivity between two (or
more) neighbouring NRENs. Task 3 of the working group studies what kinds of management
and monitoring tools need to be developed to aid the monitoring and trouble-shooting of CBF
lambdas and goes on to undertake some of the necessary development work.
The End-to-End (E2E) Monitoring System is being developed to monitor E2E links that
traverse multiple administrative domains. E2E Links in this context are dedicated multigigabit-connections which are realized at layer 2, e.g. using SDH/SONET or Ethernet. The
system collects actual monitoring information about the state of already established E2E
links. At NREN side, a perSONAR compliant Web Service – either a Measurement Point
(MP) or Measurement Archive (MA) – gathers measurement data from the devices and
transforms the data to an abstracted, hardware-independent representation. The E2E
7
Monitoring will then aggregate the data and display a weathermap-like visualization showing
the status of the E2E links. The E2E Monitoring System is used e.g. for the monitoring of the
link provided for the LHC (Long-haul communications) network.
Collaboration of JRA4 WI3 applications with cNIS
The E2E Monitoring System will use cNIS services to get information about E2E links
currently provided. The following kinds will be required for each network domain:

TopologyPoints, basically POPs (Points of Presence)

MonitoredLinks, which are parts of E2E links. Each Monitored Link connects two
TopologyPoints. Physically, a Monitored Link is realized by several interconnected
optical channel (OCH) trails
The measurement data are collected independently of cNIS via the dedicated E2E MP/MA
services. The correlation between the topology information from cNIS and the measurement
data from the E2E MP/MA shall be done using TopologyPoint IDs.
2.2 User classes and characteristics
The cNIS shall target two main groups of users: cNIS Administrators and cNIS Application
Developers. Special kinds of users are also cNIS Applications.
2.2.1 cNIS Administrator
cNIS Administrator is a person responsible for deploying, initializing and maintaining a cNIS
instance run for an administrative domain. The cNIS Administrator’s tasks will include:
installing and configuring cNIS instance, initial population of the cNIS IP topology database
using one of the available initialisation schemes, periodical maintenance of the topology
database using the cNIS Management Application, handling semi-automatic topology change
notifications.
There will be usually one cNIS administrator per administrative domain.
2.2.2 cNIS Application Developer
cNIS Application Developer is a person responsible for developing GN2 and other
applications interacting with cNIS to get topology-related data. cNIS Application Developer’s
tasks will also include a migration the currently existing applications from internal topology
databases to cNIS.
2.2.3 cNIS Application
cNIS application is a special kind of user that represents a piece of GN2 software (e.g. JRA1
CNM tool or SA3 AMPS) that interacts with cNIS to get topology information through one of
the interfaces specified in the cNIS Export Interface Description document.
2.3 Assumptions and dependencies
2.3.1 Unix systems are preferred
cNIS deployment and operation shall be optimised for UNIX platforms.
2.3.2 Read-only access to topology information for cNIS Applications
All cNIS applications will have read-only access to the topology database, while the topology
data modifications will be done only by the cNIS Administrators using the dedicated cNIS
8
Management Application (please see chapter 4.1 for details). Therefore, concurrency issues
stemming from simultaneous updates will not need to be addressed immediately.
The read-only access to topology information does not, however, exclude a future scenario
where a cNIS Application registers with cNIS to be notified of e.g. a certain class of topology
changes. Although this scenario results in a “write” operation being triggered by a cNIS
Application, the “write” operation does not influence the topology information
2.3.3 Topology modifications using the cNIS Management Applications (cMA)
All modifications of the cNIS topology information, including initial population, daily and
emergency maintenance, will be carried out by cNIS Administrators using the cNIS
Management Application (cMA). cMA shall provide an interactive user interface for all the
above “write” operations (please see e.g. the A2 - 3.3.1, A3 - 3.3.3, A5 - 3.1.2 and A7 - 3.3.2
use cases in Chapter 3).
There is however a necessity to assume, that future release of cNIS will expose an API for
some clients to update the database (see the A27 - 3.2.9 use case). Therefore to avoid design
decisions that will make concurrent updating more difficult, this premise will be taken into
account since the first release of cNIS.
2.3.4 Network elements naming
There is a need to establish a common unique naming scheme for major elements of the
network topology (e.g. nodes, interfaces, etc). GN2 applications (e.g. JRA3 BoD) will
responsible for mapping object identifiers to real equipment, which stays under their control.
The unambiguous naming convention will make it possible to correlate the data between cNIS
and local databases, which are used to store application-specific information (e.g.
configuration data).
IPv6 is one option for the unique identification of nodes/interfaces/others. There are, however
other possibilities, and as such it is intended to determine the requirements of each application
with regards to naming/numbering.
A single cNIS instance, which is deployed on a selected domain, must be uniquely identified.
This requirement concerns GN2 applications, which traverse multiple administrative domains
(e.g. JRA4 E2E) and demand to select the appropriate cNIS instance unambiguously. A
central service directory (registry) seems to me the most viable and convenient way to realize
this assumption (see B5 - 5.5)
3. Use cases
This section present a detailed list of cNIS use cases, prepared on the basis of the
requirements specified by several Geant2 activities. They conform generally to various needs
of the GN2 applications, which native network databases will be replaced by cNIS.
There is however, a bunch of use cases, which are common for all applications. They are
intended to enhance the overall schema functionality, flexibility and the ability to fulfil the
future conditions.
Each use case is marked by a shortcut “A plus a number”. The purpose of this marker is to
simplify the reference to a specific use case from the external documents (e.g. cNIS Software
and architectural design). The marker does not have any relationship with the use case content
or its title.
All use cases are divided into several groups:
9

Software – use cases which are not bound directly with the network topology
elements, but present software-specific operations;

Common - use cases which refer in general to all network technologies supported
by cNIS;

IP – use cases specific for the IP layer;

Frame Relay - use cases specific for the Frame Relay layer;

ATM - use cases specific for the ATM layer;

MPLS - use cases specific for the MPLS layer;

Ethernet – use cases specific for the Ethernet layer;

SDH – use cases specific for the SDH layer;

OTH – use cases specific for the OTH (Optical Transport Hierarchy) technology;

Inter-domain - use cases, which refer to the inter-domain links management;

Application specific - use cases, which are specific for a selected activity (cNIS
application);
3.1 Software
3.1.1 A1: Installation of cNIS base software
Source: Common requirements
Actors: cNIS Administrators
Description:
A cNIS Administrator downloads the cNIS distribution package in order to install cNIS for
his or her domain…
Procedure:
1. The administrator downloads the cNIS distribution package from the URL provided
on the GN2 website.
2. The administrator extracts the contents of the distribution archive to a local file system
Further steps to appear here.
Exceptions:
1. The operating environment on which cNIS was to be installed does not contain one of
the required software components (e.g. a Java Runtime Environment). The installation
script informs the administrator about the missing components and terminates.
More exceptions to appear here.
Priority: High
Frequency of use: Once per one cNIS installation
Release: 1.0
Notes:

Integration with popular Linux distribution mechanisms (e.g. Debian API)?
10

cNIS shall be delivered to end clients as technology-specific software. It indicates
that a client may determine what kind of network topology information (IP,
Ethernet or SDH) he/she wants to collect and manage in cNIS. This assumptions
can be realized in two ways::
o by delivering several cNIS instances, each dedicated to manage a specific
set of technologies, e.g. cNIS IP, cNIS IP+Ethernet, cNIS
IP+Ethernet+SDH
o by allowing to choose (during installation process), which network
technologies will be handled by a cNIS instance.
3.1.2 A5: Initial setup of cNIS
Source: Common requirements
Actors: cNIS Administrators
Description:
After a successful installation of cNIS base software, the cNIS Administrator needs to define
some basic information, including the list of cNIS Management Application (cMA) users and
their authentication methods, e-mail addressed for sending daily maintenance alerts etc.
Procedure:
1. The cNIS Administrator authorizes with the cNIS Management Application (cMA)
2. If the initial setup has not yet been performed, cMA shall automatically present the
Administrator with options enabling to provide the following information:
a. A list of cMA users, for each user including the following information:
i. login name
ii. authentication information
iii. Real name
iv. Institution and department name
v. E-mail address
vi. Phone number
b. E-mail addresses for sending daily topology maintenance information and
alerts
c. Define a set of physical locations to which various elements of the topology
will be assigned
d. Define a list of cNIS Application identifiers (JRA5 “components”) that are
allowed to use cNIS services
Priority: High
Frequency of use: Once per one cNIS installation
Release: 1.0
3.1.3 A43: Extending network discovery functions with new features
Source: Y4 kick-off meeting in Poznan: 2007.09.24-26
11
Actors: cNIS Administrator
Description:
CNIS service administrator may want to extend CNIS network discovery capabilities, e.g.
discovery of devices of particular vendor. The extension could be applied as a plug-in for the
base cNIS software. CNIS v1 has been delivered with support of some Juniper and Cisco
routers. It should be able to expand the set of supported devices and technologies.
This use case is applicable not only for IP layer discovery, but it has more general meaning. It
indicates that cNIS should provide a programming framework allowing independent
developers to implement their own extension to network discovery functionality. It will
contribute to deliver new capabilities for cNIS relating with vendor and technology specific
options.
Priority: High
Release: 1.1
3.2 Common
3.2.1 A21: Defining relationships between interfaces
Source: Common requirements (Anand Patil)
Actors: cNIS Administrator
Description:
In order to correctly handle e.g. tunnelling, some cNIS applications may need explicit
information about relationships between interfaces on the same or different layers. cNIS shall
enable the cNIS Administrator to establish (using the cMA) a parent-child relationship
between two interfaces. cNIS shall return information about the relationships between
interfaces in response to topology queries (see use cases A4 - 3.3.5, A11 - 3.4.1, A12 - 3.5.1,
A18 - 3.8.1, A19 - 3.7.1, A29 - 3.9.2, A10 - 3.10.3).
Specification
The basic approach assumes that every instance of an IP address has its own unique interface.
This should not be the case. It is possible (and not uncommon) for a logical interface to have
more than one IP address. Similarly, a physical interface may have more than on logical
interface, and this is often the case for Gigabit Ethernet. For example, GEANT2 Junipers,
physical interface ge-0/0/0 has multiple logical interfaces named ge-0/0/0.10, .20, .30
Priority: Medium
Frequency of use: Once a day (typically after discovering or adding manually an interface)
Release: 2.0 (?)
3.2.2 A22: Defining allowed relationships between interfaces
Source: Common requirements (Anand Patil)
Actors: cNIS Administrator
Description:
In order allow a greater degree of flexibility in defining relationships between interfaces,
cNIS shall enable the cNIS Administrator to define what kinds of relationships between
interfaces are allowed (e.g. IP interface can be a parent of another IP interface, but an SDH
12
interface cannot be a parent of an IP interface). The allowed interface relationship types shall
be configurable using the cMA.
Priority: Medium
Frequency of use: Several times per cNIS installation lifetime
Release: 2.0 (?)
3.2.3 A32: Defining relationships between links
Source: Common requirements (requested by GARR)
Actors: cNIS Administrator
Description:
Some cNIS applications (e.g. Network Management System) may need explicit information
that a link, which goes from point A to point B on one layer, may be composed of multiple
segments below. For example, in MPLS networking, a Label Switched Path (LSP) is a path
through an MPLS network, which consists of several parts determined by the Label Edge
Routers and Label Switching Routers. Similarly, one IP link can be made of three SDH links,
which is next composed of several lambdas, and which is build finally on top of a fibre.
cNIS software shall correlate the relationships between links, no matter if it is a logical or
physical links, e.g. IP (1)--- (n) SDH (1) --- (m) Lambda (l) ---- (l) fibre. Additionally cNIS
administrator shall have an opportunity to allow or prohibit certain combinations between
specific links (in a form of business rules), e.g. IP link can be composed of several Ethernet
segments. This operations shall be performed using the cMA.
Additional information
cNIS should allow to model any layering technologies. However, the combinations between
the selected technologies may be either not realizable from a technical point of view or do not
occur in the network design of the organization that manages the cNIS instance. Therefore,
the cNIS instance will use an additional matrix to prohibit certain combinations. The
representation and modelling of technological combinations that is possible and relevant for
L1 and L2 technologies is one of the responsibilities of the JRA3 and JRA1 activity.
Priority: Medium
Frequency of use: Once a day (typically after discovering or adding manually a link)
Notes: This scenario does not cover the situation, when underlying link does not terminate on
the same device. This specific scenario, which was defined during the meeting in Munich
(2007.07.25-26) is described in a separate use case (see 3.2.4).
3.2.4 A35: Defining relationships between layers which do not terminate on
the same device
Source: JRA3 requirements (requested during the meeting in Munich: 2007.07.25-26)
Actors: cNIS Administrator
Description:
Use case A32 (3.2.3) defines a correlation between links, i.e. that a link, which goes from
point A to point B on one layer, may be composed of multiple segments below. But this
scenario does not cover all possible associations between network layers, which cNIS should
deal with. In some specific circumstances, a link established on one layer must be mapped to
another link on lower layer, which can be ‘shorter’ when we compare the corresponding
13
entities on both layers. Simply put, it concerns the scenario when underlying link does not
terminate on the same devices.
Specification
Let’s consider the following situation:
[IP iface] --------------------------------------- IP link -----------------------------------------[IP iface]
[ETH dev] -------A-------- [ETH dev] -------B-------[ETH dev] -------C-------[ETH dev]
In such a case, end devices of the link B are not the same devices, which terminates the IP
link. At the same time, IP link constitutes a higher layer for link B.
Priority: Medium
Frequency of use: Once a day (typically after discovering or adding manually a link)
This use cases constitutes a complex issue and needs a comprehensive investigation.
3.2.5 A13: Inspecting audit trail information related to topology updates
Source: Common requirements
Actors: cNIS Administrator
Description:
When diagnosing and fixing problems with cNIS-based applications, the cNIS Administrator
may need to inspect what changes have been done to the to the topology database and when.
Towards that end, cNIS shall enable the administrator to view a log of changes applied to a
specific network element (e.g. a node or interface) or the network topology as a whole. cNIS
shall enable the administrator to browse logs of changes that we made in a specified period of
time (between two dates, before given date, after given date).
Priority: High
Frequency of use: Once per several cMA sessions
Release: 1.0
3.2.6 A16: Searching for specific topology elements
Source: Common requirements
Actors: cNIS Administrator
Description:
To diagnose a specific problem or change a specific piece of topology information, the cNIS
Administrator may need to search for certain topology elements based on some set of
properties (e.g. search for an IP node (router) based on the IP address of one of its interfaces).
Priority: High
Frequency of use: Several times per one cMA session
Release: 1.1
3.2.7 A14: Customized topology data constraint checking rules
Source: Common requirements
Actors: cNIS Administrator
14
Description:
As it is impossible to perform comprehensive network topology consistency checking on the
database schema level, cNIS should allow the Administrator to run consistency checks on the
application level. An example constraint could be the following: “an IP network must connect
at least 2 IP interfaces”. Consistency checks can be run manually (on demand) or periodically.
In both cases the Administrator shall be presented with a list of problems, for some of which
cNIS could suggest possible solutions (e.g. deleting a network containing less than 2
interfaces).
Priority: Low
Frequency of use: Once per several cMA sessions
Release: 2.0 (?)
3.2.8 A17: Automatic supplementing the existing topology with new data
Source: Common requirements
Actors: cNIS Administrator
Description:
In case of certain properties of the network topology elements (e.g. routing cost), the cNIS
Administrator may want to automatically update only the values of these properties without
performing full discovery of the network topology. Therefore, cNIS shall enable automatic
updating (e.g. based on SNMP/SSH access) of selected properties of the network element,
leaving the topology unchanged.
Priority: Low
Frequency of use: Once per several cNIS application sessions
3.2.9 A27: Modifying topology data through an API
Source: Andreas Hanemann (JRA1), Angelos Lenis (JRA3)
Actors: cNIS Applications
Description:
At some point cNIS Application may require an API for modifying topology data, e.g. in
order to enable users that are not local domain administrator to update certain parts of the
topology database.
When preparing for implementation of this use case the following problems should be
addressed: how to ensure that data consistency is preserved (normally, cNIS Administrator
would be notified that a topology modification would break consistency), concurrency
problems, transactional properties.
Priority: Low
Frequency of use: Several times per one cMA session
3.2.10 A30: Obtaining a network topology in the NDL format
Source: Andreas Hannemann (JRA1), Angelos Lenis (indirectly through the GRNET)
Actors: cNIS Applications
Description:
15
The Network Description Language (NDL) is build upon the Resource Description Format
and provides linking capabilities to produce a distributed Topology Knowledge Base. The
advantage of the TKB is that it provides easily accessible knowledge that the management
and control planes can build upon.
NDL offers a set of classes and properties to create descriptions of physical networks. cNIS
shall make the topology data available to the cNIS Applications in the NDL format.
Additionally cNIS shall provide pointers (URLs) to other cNISes.
Priority: Low
Frequency of use:
Notes: Andreas Hannemann will keep an eye on the NDL development and will provide
feedback on that if necessary
3.2.11 A15: Registering for periodic updates about topology changes
Source: JRA1 (Andreas Hanemann), JRA3 (?)
Actors: cNIS Applications
Description:
In the future, some applications may prefer to find out about topology changes not by polling
cNIS for changes but rather having cNIS periodically inform them about the changes. cNIS
shall enable such interaction style by allowing applications to register for updates and specify
the frequency of the updates. cNIS shall notify each registered application of the topology
changes that happened since the last time the application was notified.
Priority: Low
Frequency of use: Once per several cNIS application sessions
3.2.12 A44: Holding an historical record of the actual topology
Source: Toby Rodwell
Actors: cNIS Administrator
Description:
cNIS shall keep track of all transitions of the actual topology, regardless of whether they are
"accepted" by cNIS administrator. It means, that every time, when network discovery is run,
cNIS saves a snapshot of the actual topology. So cNIS administrator can later ask the question
"What was the actual topology at time T?"
Scenario
cNIS distinguishes two modes of database synchronization:
a. cNIS administrator runs the network discovery and as a result he obtains a comparison
between the network topology stored in the database (steady state) and the actual topology.
As a result cNIS administrator is able to commit/reject found changes (this scenario conforms
to A7 for the IP network topology, see 3.3.2)
The procedure above enables cNIS administrator to keep the "steady state" (aka "design"
topology) up to date.
b. cNIS administrator compares the steady state with a selected snapshot of the actual state in
the past. He is able to review the differences and/or commit the found changes.
16
In this way cNIS administrator may get know how the current steady state differs from an
actual state in the past.
Priority: Medium
Frequency of use:
Release: 1.5
3.2.13 A45: Managing historical designed topology
Source: Toby Rodwell
Actors: cNIS Administrator
Description:
cNIS shall enable an access to information what was the designed topology at time T.
Additionally cNIS shall allow to flashback network database, which means to look in the past
and “rewind” the
designed topology to
a selected
point
of time.
Scenario
cNIS administrator compares the current steady state with a selected steady state in the past
(specifying a date, for example YYYY-MM-DD). He is able to review the differences and/or
commit the found changes, that is restore the designed topology to the selected point of time.
The specification may be extended in future with another scenarios, e.g. comparison between
a selected design state in the past and a snapshot of the actual state
Additional information
This use case extends A44 (see 3.2.12)
Priority: Medium
Frequency of use:
Release: 1.5
3.3 IP
3.3.1 A2: Initial population of the IP network topology
Source: Common requirements
Actors: cNIS Administrators
Description:
After a successful installation and initial set up of the cNIS base software, the cNIS
Administrator needs to populate the IP network topology database with information gathered
from the domain for which cNIS is deployed. In order to promote wide adoption of cNIS, it is
desirable to make the population process as effortless as possible.
Based on varying access policies and the already available topology databases, the following
initial population scenarios are possible:
1. SNMP and/or SSH access: population with topology information automatically
inferred from various kinds of data gathered from nodes (e.g. lists of interfaces,
routing tables) using the SNMP and/or SSH protocols. The most important advantage
of this method is that it only requires the cNIS Administrator to provide a limited
amount of initial data (such as IP addresses of a number of routers, SSH access details
etc.). One possible problem in this scenario is that the automatically discovered
topology may need to be manually inspected and, possibly, corrected.
17
2. XML file: population with topology data read from an XML file in a specified format.
The advantage of this method is that it does not require the cNIS Administrator to
allow cNIS to access the nodes through the SNMP and/or SSH protocols. The most
important drawback of this method is that it will require the cNIS Administrator to
convert/export the already existing topology database into the XML format accepted
by cNIS.
3. Manual entering of the topology data using the cNIS Management Application,
which is the most laborious fall-back scenario in case there is no existing topology
access and the domain’s policy forbids SNMP and SSH discovery.
4. Connecting to an existing database: population with topology data retrieved from an
existing topology database. This scenario, although theoretically possible, seems
barely practical. It would require the cNIS Administrator do define a mapping
between the schema of the existing database and the cNIS database schema, which, in
turn, would imply that the cNIS Administrator has enough resources and experience to
understand both schemas and make sure that the data imported to the cNIS database
meets all consistency criteria required by the cNIS core software.
Procedure:
1. The cNIS Administrator authorizes with the cNIS Management Application (cMA)
2. If the IP network topology database has not yet been populated, the cMA shall
automatically present the cNIS Administrator with a choice of initial population
options:
e. SNMP and/or SSH automatic topology discovery
f. XML-file based initialization
g. Manual entry of topology elements
3. If the Administrator chooses the automatic topology discovery, cMA shall request the
Administrator to provide all data that is required to start the discovery process (initial
set of routers’ IP addresses, SSH access details). After all required data has been
provided, cMA shall initiate the discovery process. (proceed to step 6)
4. If the Administrator chooses the XML file based initialization, cMA shall request the
Administrator to upload the XML file containing the topology information. After the
file has been successfully uploaded, cMA shall parse the file to extract the topology
information.
5. If the Administrator chooses the manual entry of topology elements, cMA shall enable
the Administrator to start defining topology elements (see A3 - 3.3.3). (end of
procedure)
6. cMA shall display a preview of what topology information has been discovered (or
parsed from the XML file) with an option to insert that information to the database or
repeat the discovery (or XML file parsing) step.
7. When the Administrator decides to insert the discovered topology data to the database,
cMA shall confirm the successful initial population of the database and enable the
Administrator to perform manual corrections to the topology (see A3 - 3.3.3).
Exceptions:
1. The IP network topology database has already been populated. In this case cMA shall
disable/hide the initial population functionality.
18
2. Initial data provided for the automatic topology discovery process is incomplete. In
this case cMA will attempt to perform the discovery based on the incomplete data (e.g.
if SSH access data is missing, the discovery can still proceed based on the SNMP
protocol) and display appropriate warnings. If the provided data is not enough to
perform any kind of automatic population, cMA shall prompt the Administrator for
the missing data and offer the XML file based and manual topology initialization
options.
3. The automatic topology discovery process fails. cMA shall display a preview of the
collected topology information (if any) along with a message informing about the
failure. cMA shall present the Administrator with an option to insert that information
to the database or repeat the discovery step
4. Errors occur while parsing the provided XML file containing network topology
information. cMA shall display a preview of the parsed topology information (if any)
along with a message informing about the failure. cMA shall present the
Administrator with an option to insert that information to the database or the XML file
parsing step
Priority: High
Frequency of use: Once per one cNIS installation
Release: 1.0
Notes:
The IP network topology initialisation shall be performed independently of the (possibly)
existing topology data for other layers. If there is a need to establish relationships between the
IP topology and other layers, the cNIS Administrator can do it manually using functions
implementing use case A21: Defining relationships between interfaces.
3.3.2 A7: Daily maintenance of the IP network topology
Source: Common requirements
Actors: cNIS Administrators
Description:
One task of the cNIS Administrator is to ensure that the contents of the cNIS IP network
topology database is synchronised with the real state of the network. cNIS shall support a
semi-automatic daily maintenance of the IP topology, whereby the cNIS Administrator gets
notified of the detected topology changes by e-mail and has the opportunity to inspect the
changes and transfer some of them to the cNIS topology database.
Procedure:
1. At specified intervals (e.g. once a day) cNIS shall perform the automatic IP network
topology discovery procedure using the SNMP/SSH method (see A2 - 3.3.1).
2. If the discovered topology differs from the topology data currently stored in the
database, cNIS shall send a notification e-mail to the addresses configured during the
initial set up (see A5 - 3.1.2). The e-mail shall instruct the Administrator how to
inspect and transfer the changes to the cNIS database (e.g. by providing a link to the
appropriate function in the cNIS Management Application).
19
3. When the Administrator follows the link provided in the notification e-mail, cNIS
shall present the administrator with a list of detected topology changes. The list shall
contain:
a. A list of removed nodes (i.e. present in the databases, but not present in the
real topology)
b. A list of added nodes (i.e. present in the real topology, but not present in the
database), along with the interfaces of the node
c. A list of added interfaces
d. A list of removed interfaces
e. A list of added networks
f. A list of removed networks
g. A list of links added to a network
h. A list of links removed from a network
4. cNIS shall give the Administrator an option to select which of the changes should be
transferred to the database. cNIS shall also ensure that the Administrators’ choices do
not lead to database inconsistencies (e.g. by requesting to add a link between an
existing and a new node without adding the new node).
5. When the Administrator decides to commit the chosen changes, cNIS shall apply the
changes to the topology database.
Priority: High
Frequency of use: Once a day
Release: 1.0
Exceptions:
1. If automatic discovery of IP network topology (using SNMP/SSH) is not possible,
functions associated with this use case should be disabled.
Notes:
Every time the cMA presents the cNIS Administrator with a list of detected topology changes,
the changes shall be computed between the current contents of the topology database and the
currently discovered topology. In other words, cNIS shall not store any uncommitted topology
data, and therefore shall not support e.g. daily maintenance based on data discovered in the
past.
Optionally, during the daily maintenance the Administrator may want to update only certain
properties of the topology elements (e.g. routing cost or propagation delay), skipping the
topology discovery step.
Questions:
1. How about networks that consisted of a multipoint link, but some interfaces were
removed from that network so that it is now a network with a p2p link. Is this situation
at all possible? Shall cNIS dynamically convert between p2p links and multipoint
links?
20
3.3.3 A3: Manual editing of IP network topology information
Source: Common requirements
Actors: cNIS Administrators
Description:
In order to keep the IP network topology database up-to-date, the cNIS Administrator may
need to manually edit the properties of certain IP network elements. The need for manual
editing may be needed to introduce corrections to the automatically discovered topology or
when the automatic topology discovery is not possible at all.
Procedure:
1. The cNIS Administrator authorizes with the cNIS Management Application (cMA)
and chooses the manual IP network topology editing function.
2. cNIS shall enable the Administrator to perform the following actions:
a. Define a new IP node (router) along with its interfaces
b. Modify a router’s properties, including adding/removing the router’s interfaces
c. Remove a router entirely
d. Define a new IP network along with the assignment of interfaces to be
connected to that network
e. Modify a network’s properties, including adding/removing interfaces
connected to that network
f. Remove a network entirely
3. Upon execution of each of the above modifications, cNIS shall check the impact of the
modification on the database consistency. If the consistency is going to be broken,
cNIS shall display a warning message and disallow committing the modified data.
Priority: High
Frequency of use: Once a day
Release: 1.0
Exceptions:
1. When committing the IP topology modification, the following inconsistencies can
occur:
a. Removing (or changing start/end date of) a router whose interfaces are
connected to some network. The administrator should first remove (or change
start/end date of) all links engaging the router’s interfaces and only then
attempt to remove the router. Alternatively, cNIS may offer a cascaded
removal (or start/end date change) option, which would automatically/with
confirmation remove (or change start/end date of) all links and networks
connected to the router being removed (or edited).
b. Removing (or changing start/end date of) an interface which is connected to
some network. The administrator should first remove (or change start/end date
of) all links engaging the interface. Similarly, cNIS may offer a cascaded
interface removal (or start/end date change) option.
21
c. The address prefix of an interface being added to a network is not equal to the
address prefix of the network. In this case cNIS shall display a warning
message and allow the operation.
3.3.4 A24: SA3 Pathfinding
Source: SA3 requirements
Actors: cNIS Applications
Description:
SA3 AMPS (Advance Multi-domain Provisioning System) and its Intra- and Inter-Domain
Services need the following pathfinding functionality:
1. Egress finding
For a specified destination IP address, cNIS shall return a list of boundary routers in
the local domain which are gateways to the specified destination IP address.
2. Next domain finding
For a specified destination IP address, cNIS shall return
a. a pointer to the cNIS instance handling the next domain (relative to the local
domain) on the route to the specified destination node
b. an external identifier of the ingress node in the next domain that lies on the
route to the specified destination IP address
See also use case A22 - 3.2.2.
3. Path finding
For a specified pair of start and end interfaces in a local domain, cNIS shall determine
the shortest path between these two interfaces.
Priority: High
Frequency of use: Several times per cNIS Application session
Release: 1.0
Questions:
As the characteristic of cNIS is more database-oriented, should functionality described in
points 1 and 2 (which relies on trace route rather than the topology database) be part of cNIS.
Maybe these two items should be still implemented by the original pathfinder, leaving point 3
(which can be implemented based only on local topology data) for cNIS?
3.3.5 A4: Obtaining current IP topology information for a cNIS Domain
Source: JRA1 requirements (Andreas Hanemann)
Actors: cNIS Applications
Description:
Many GN2 applications, such as the JRA1 CNM tool, require access to information about the
current IP topology for the whole cNIS domain, e.g. for visualisation purposes.
Procedure:
22
1. A cNIS Application (e.g. the CNM tool) contacts cNIS to obtain current information
about the IP topology for the whole cNIS Domain.
2. cNIS shall return the following information through the interfaces defined in the cNIS
Export Interface Description document:

A list of nodes (routers) in the cNIS Domain. For each node from the list, the
following information shall be returned:
o Human-readable name of the node
o Free-text description of the node
o IP address for management and fetching statistics
o Geographical location of the node
o A list of the node’s interfaces

A list of all interfaces belonging to the listed nodes. For each interface from the
list, the following information shall be returned:
o The IP address of the interface
o Human-readable name (ifalias) of the interface

A list of all peer-to-peer links existing between all listed interfaces.
Priority: High
Frequency of use: Many times per cNIS Application session
Release: 1.0
3.3.6 A8: Obtaining a list of IP topology changes over a period of time
Source: JRA1 requirements (Andreas Hanemann)
Actors: cNIS Applications
Description:
Some visualisation tools (e.g. the CNM tool) provide utilities that support manual updating of
IP topology maps. The update process requires access to a list of IP topology changes that
happened over a specified period of time, e.g. since some specified date till now.
Procedure:
1. A cNIS Application (e.g. the CNM tool) contacts cNIS to obtain information about the
changes in IP topology that happened between the specified start and end timestamps.
2. cNIS shall return the following information:

A list of nodes added/removed during the specified period

A list of interfaces added/removed during the specified period

A list of peer-to-peer links added/removed during the specified period
Exceptions:
1. Start timestamp is greater (later) than the end timestamp: cNIS shall respond with an
error message saying that the start timestamp must not be greater than the end
timestamp.
23
2. End timestamp is in the future: cNIS shall respond with information about the
topology changes that happened since the start timestamp up to the current topology
database state.
Priority: High
Frequency of use: Once per several cNIS Application sessions
Release: 2.0 (?)
Notes:
The listing of changes shall be done in a cumulative way, i.e. if during the specified period a
topology element gets first added and then removed, information about these two
complementary changes shall not be returned.
3.3.7 A9: Obtaining historical IP topology information for a cNIS Domain
Source: JRA1 requirements (Andreas Hanemann)
Actors: cNIS Applications
Description:
Many GN2 applications, such as the JRA1 CNM tool, require access to information about
how the cNIS domain IP topology looked like at a specified point of time in the past.
Procedure:
1. A cNIS Application (e.g. the CNM tool) contacts cNIS to obtain information about the
IP topology of a cNIS Domain that existed at the specified timestamp.
2. cNIS shall return information about the topology that existed at the specified
timestamp. The information that shall be returned is specified in use case A4:
Obtaining current IP topology information for a cNIS Domain.
Exceptions:
1. The specified timestamp is outside the range of topology timestamps available in the
database: cNIS shall respond with an error message saying that the start timestamp
must be in the range of timestamps available in the database.
Priority: High
Frequency of use: Many times per cNIS Application session
Release: 1.5
3.4 SDH
3.4.1 A11: Obtaining SDH topology for a cNIS Domain
Source: JRA3 requirements
Actors: cNIS Applications (AutoBahn)
Description:
The AutoBahn Domain Manager requires information about the SDH part of the network
topology. cNIS provides raw physical SDH topology (not abstracted) according to some
filtering criteria:

flag = full topology or AutoBahn topology only (see 3.11.1);
24

pruning conditions, e.g. VC-4 links with timeslot=33 and payload=1000 (see 3.11.4).
Priority: Medium
Frequency of use: Many times per cNIS Application session
Release: 1.5
3.4.2 A40: Manual editing of SDH topology information
Source: Common requirements (Y4 kick-off meeting in Poznan: 2007.09.24-26)
Actors: cNIS Administrators
Description:
In order to keep the SDH network topology database up-to-date, the cNIS Administrator may
need to manually edit the properties of certain SDH network elements. Manual editing may be
needed to introduce corrections or complete an automatically discovered topology, or when
the automatic topology discovery is not possible at all.
Priority: Medium
Frequency of use: once a day
Release: 1.5
3.4.3 A41: Initial population of the SDH topology
Source: Common requirements, kick-off meeting in Poznan: 2007.09.24-26
Actors: cNIS Administrators
Description:
After a successful installation and initial set up of the cNIS base software, the cNIS
Administrator needs to populate the SDH topology database. In order to promote wide
adoption of cNIS, it is desirable to make the population process as effortless as possible.
Therefore, the SDH topology database population shall proceed in a way similar to the
population of IP database (see A2 - 3.3.1).
Specification
SDH network topology database is populated from an external XML file, which contains a
topology retrieved from network devices. The XML schema will be specified later.
Priority: Medium
Frequency of use: Once per one cNIS installation
Release: 1.5
Notes:
The SDH topology initialisation shall be performed independently of the (possibly) existing
topology data for other layers. If there is a need to establish relationships between the SDH
topology and other layers, the cNIS Administrator can do it manually using functions
implementing use case A21: Defining relationships between interfaces.
3.4.4 A48: Adaptation Ethernet-over-SDH
Source: JRA3 requirements (cNIS task force meeting: 2007.11.06)
Actors: cNIS Administrators
25
Description:
Ethernet is a very common way to implement a network infrastructure for LAN-based
applications. The big issue is how to handle Ethernet traffic on very long distances.
Depending on the cost, distance, bandwidth, and traffic management requirements of the
WAN/MAN application, several metro approaches may be used to transport Ethernet data
traffic. These include direct mapping of Ethernet over wavelengths (EoW), Ethernet over
Sonet/SDH (EoS), optical Ethernet (i.e. native Ethernet over fiber for long haul,
1000BaseLX), or implementing an Ethernet in the first mile (EFM) solution over copper or
fiber.
Specification:
Two NRENs want to create a virtual private network based on Ethernet technology. The VPN
is constructed with use of inter-domain SDH link (transport network) connecting two Ethernet
domains. For each involved Ethernet domain the cNIS administrator defines a mapping
between a local Ethernet port and an SDH port of the inter-domain link (which will transport
the Ethernet signal). The local Ethernet ports are egresses of the Ethernet domains.
Another option is to connect two independent local Ethernet domains with local SDH link.
Then only one cNIS Administrator is involved. The mapping is between egresses (Eth ports)
of Ethernet domains and SDH ports (enpoints of the SDH link).
The mapping between the ports is called "adaptation". Adaptation issue has been touched by
NDL (Network Description Languafe) project, more information can be found here:
http://www.science.uva.nl/research/sne/ndl/?c=20-Technology-Schemas.
Priority: Medium
Notes:
How the adaptation will be done: automatically or manually (most probably) by the cNIS
Administrator?
Frequency of use:
Release: 2.0 (?)
3.5 Ethernet
3.5.1 A12: Obtaining Ethernet topology for a cNIS Domain
Source: JRA3 requirements
Actors: cNIS Applications (AutoBahn)
Description:
The AutoBahn Domain Manager requires information about the Ethernet part of the network
topology. cNIS shall provide raw physical topology (not abstracted) according to some
filtering criteria:

flag = full topology or AutoBahn topology only (see 3.11.1);

pruning conditions: e.g. links over 1 GB (see 3.11.4).
Priority: Medium
Frequency of use: Many times per cNIS Application session
Release: 1.5
26
3.5.2 A39: Manual editing of Ethernet topology information
Source: Common requirements (Y4 kick-off meeting in Poznan: 2007.09.24-26)
Actors: cNIS Administrators
Description:
In order to keep the Ethernet network topology database up-to-date, the cNIS Administrator
may need to manually edit the properties of certain Ethernet network elements. Manual
editing may be needed to introduce corrections or complete an automatically discovered
topology, or when the automatic topology discovery is not possible at all.
Priority: High
Frequency of use: once a day
Release: 1.1
3.5.3 A42: Initial population of the Ethernet topology
Source: Common requirements, Kick-off meeting in Poznan: 2007.09.24-26
Actors: cNIS Administrators
Description:
After a successful installation and initial set up of the cNIS base software, the cNIS
Administrator needs to populate the Ethernet topology database. In order to promote wide
adoption of cNIS, it is desirable to make the population process as effortless as possible.
Therefore, the Ethernet topology database population shall proceed in a way similar to the
population of IP database (see A2 - 3.3.1).
Frequency of use: Once per one cNIS installation
Specification
The discovery of the Ethernet network topology is handled by an independent software
component, in accordance with the functionality provided the cNIS adaptation layer (see
3.1.3).
Priority: High
Notes:
The Ethernet topology initialisation shall be performed independently of the (possibly)
existing topology data for other layers. If there is a need to establish relationships between the
Ethernet topology and other layers, the cNIS Administrator can do it manually using functions
implementing use case A21: Defining relationships between interfaces.
Release: 1.1
3.6 OTH
3.6.1 A45: Ethernet/SDH signal transport over OTN
Source: Common requirements, cNIS task force meeting: 2007.11.06, Anand Patil
Actors: ?
Description:
OTN (Optical Transport Network) with proposed ITU G.709 standard is a WAN (Wide Area
Network) technology providing a transport of variety of signals over fiber links with use of
27
DWDM (Dense Wavelength-division Multiplexing). G.709 defines the optical transport
hierarchy of the OTN, the functionality of its overhead in support of multiwavelength optical
networks and frame structures, bit rates and formats for mapping client signals.
OTN consists of several parts , which are often referred to as layers:

Optical Transport Section (OTS),

Optical Multiplex Section (OMS),

Optical Channel (OCh),

Optical Transport Unit (OTU),

Optical Data Unit (ODU),

Optical Channel Payload Unit (OPU).
more description to appear here
Notes:
Is it possible to discover OTN topology automatically (probably not)?
Frequency of use:
Priority: Low
3.6.2 A46: Analysing System Failure
Source: Common requirements (cNIS task force meeting: 2007.11.06, Anand Patil)
Actors: cNIS Administrators
Description:
OTH provides a physical transport for many different signals (e.g. SDH or Ethernet) and is
referred to physical layer of the network topology. cNIS shall correlate this layer with all
layer above (see A21, A32) in order to determine which systems/sub-systems (physical nodes,
interfaces and/or links) are affected when fiber cuts
Specification
As an input a report of the fiber damage is provided by cNIS administrator or in an automatic
manner. A possibility to take advantage of the second option needs to be investigated
however (at present cNIS is assumed to store only static data, not dynamically changed).
cNIS matches OTH information to a specific system/sub-system (link, interface or node) and
marks the appropriate system/sub-system as down/degraded.
Priority: Low
Frequency of use:
Notes
How cNIS should respond when connection on the failure fiber will be restored? Repeat the
whole procedure and mark the system/sub-systems as up?
3.7 Frame Relay
3.7.1 A19: Obtaining FrameRelay topology for a cNIS Domain
Source: JRA3 requirements
28
Actors: cNIS Applications
Description:
Priority: Low
Frequency of use:
3.8 ATM
3.8.1 A18: Obtaining ATM topology for a cNIS Domain
Source: JRA3 requirements
Actors: cNIS Applications
Description:
Priority: Low
Frequency of use:
3.9 MPLS
3.9.1 A28: Defining MPLS label switching information
Source: Common requirements (Anand Patil)
Actors: cNIS Administrator
Description:
cNIS shall enable the Administrator to use the cMA to define MPLS label switching
information for each node.
Priority: Low
Frequency of use:
Note: Garr participants are directly involved in the design of the MPLS functionality
3.9.2 A29: Obtaining MPLS label switching information
Source: Common requirements (Anand Patil)
Actors: cNIS Applications
Description:
cNIS shall enable the cNIS Applications to obtain MPLS label switching information for a
network node.
Priority: Low
Frequency of use:
Notes: Garr participants are directly involved in the design of the MPLS functionality
3.10 Inter-domain
3.10.1 A20: Obtaining a pointer to the adjacent cNIS instance
Source: Common requirements
Actors: cNIS Applications
29
Description:
In order to aggregate topology information across multiple domains, cNIS applications will
need pointers (e.g. URLs) to cNIS instances deployed for the domains that are adjacent to the
current cNIS Domain.
Procedure:
1. A cNIS Application contacts cNIS to obtain a pointer to the cNIS instance deployed
for the domain that is connected to the local domain through given interface. The cNIS
application must provide an identifier of the interface in the local domain for which
the adjacent cNIS pointer shall be retrieved.
2. cNIS shall return a pointer (e.g. an URL) to the cNIS instance that handles the
adjacent domain as well as the external identifier of the interface in the adjacent
domain to which the local interface is linked.
Exceptions:
1. Given interface identifier does not correspond to any interface in the local cNIS
instance. cNIS shall respond with an error message.
2. The interface corresponding to given identifier is not linked to any adjacent domains.
cNIS shall respond with empty pointer and external interface identifier.
Priority: High
Notes:
Entry of the pointers to cNIS instances deployed for adjacent domains and external interface
identifiers shall be performed by the cNIS Administrator using the cMA.
3.10.2 A47: Establishing E2E Link for a cNIS Domain
Source: JRA4 requirements (Matthias K. Hamm)
Actors: cNIS Administrators
Description:
E2E Links are defined as optical connections realized using layer 1 and 2 technologies like
Ethernet or SDH/SONET over fibre. E2E Links connect endpoints in organisations which
may be located in different countries and cross networks of different network domains. E2E
Links are composed of Domain Links (DL) -- representing intra-domain segments of the links
-- and Inter Domain Links (IDL) -- representing segments crossing administrative borders.
The common denominator for DL and IDL is Monitored Link (ML). cNIS shall store the
information about all ML a domain has the administrative responsibility for, regardless if DL
or IDL.
Procedure
1. cNIS administrator defines all "local" Topology Points owned by the domain and
involved in providing E2E Links. The following data is needed:

Topology Point ID (in the format "DomainID"-"Local Id", e.g. "PSNC-POZ")

Name

Country

City
30

Institution

Latitude

Longitude.
2. cNIS administrator establishes a monitored link providing:

E2E link ID (global name): The E2E link ID is composed as a combination of
the two globally unique acronyms of the organisations at the Endpoints in
lexicographical order, the project ID and an additional numerical index (three
digits with leading zeros) to distinguish between multiple E2E links of the
same project (e.g. LRZ-SARA-DEISA-001).

Local name: a locally unique ID of a Monitored Link

Link type: cNIS administrator sets the link type from the three given values:
Domain Link, Inter-domain Link and Interdomain Link Partial Info
o 'Domain Link has two local topology points
o Inter-domain link has one local and one foreign topology point

The monitored link is delimited by two topology points:
o Start topology point: cNIS administrator chooses a topology point from
the list of previously defined data and sets its role as Demarcation Point
or Endpoint
o End topology point: cNIS administrator chooses a topology point from
the list of previously defined data and sets its role as Demarcation Point
or Endpoint
E2E link is an abstract link, which may be implemented in various ways with different
physical properties (e.g. wavelength or WDM type etc.) and based on multiple physical
connections. cNIS administrator is able to define which physical links create the monitored
link and set the proper order for them.
References
E2E Link Monitoring System Design,
http://wiki.geant2.net/bin/view/JRA4/DmsDocE2ELinkDataModel
E2E Link Monitoring System Design and User Documentation,
http://wiki.perfsonar.net/jra1-wiki/images/1/1e/GN2-JRA4-06-010v230.pdf
Notes
All IDs are case-insensitive.
Priority: High
Frequency of use: Once every several cMA sessions
Release: 1.1
3.10.3 A10: Obtaining current E2E Link Topology for a cNIS Domain
Source: JRA4 requirements (Matthias K. Hamm)
Actors: cNIS Applications
Description:
31
The E2E (End-to-End) Monitoring System requires access to information about the current
E2E Link topology for the whole cNIS domain, e.g. for visualisation purposes.
Procedure:
1. The E2E Monitoring System contacts cNIS to obtain current information about the
E2E Link topology for the whole cNIS Domain.
2. cNIS shall return the following information through the interfaces defined in the cNIS
Export Interface Description document:

A list of all TopologyPoints belonging to the cNIS Domain. For each
TopologyPoint from the list, the following information shall be returned:
o ID
o Name
o Country
o City
o Institution
o Latitude
o Longitude

A list of all MonitoredLinks the cNIS has the monitoring responsibility for. For
each link from the list, the following information shall be returned:
o Monitored link ID
o IDs of the 2 involved TopologyPoints
o Validity (e.g.. time of a link being set into production)
o For each TopologyPoint: Role of the TopologyPoint for the particular E2E
Link (An E2E Link is a logical connection between two Endpoints and
consists of 1 or more MonitoredLinks), which can be either Demarcation
Point or Endpoint
o LocalName
Priority: Medium
Frequency of use: Periodically, every 5 minutes for each domain
Release: 1.1
3.11 Application specific
3.11.1 A36: Defining stitching parameters
Source: JRA3 requirements (requested during the meeting in Munich: 2007.07.25-26)
Actors: cNIS Administrators
Description:
Stitching is the process by which intra-domain paths are connected in tandem to create an
end-2-end path. Stitching requires matching of parameters on adjacent paths. Paths may have
physically adjacency or peering adjacency.
32
Underlying static infrastructure does not need ‘stitching’ whereas technology stitching is
about service provision. From the JRA3-AutoBahn perspective cNIS is more than just static
topology also supports alarm management and path provisioning.
Specification
All stitching parameter (s) have the same attributes (and object) - Name, Value, Dimension
and other (see the reference below for details). Attribute value can be a single value, a list, a
range or a function. Moreover, attribute value can be inherited (due to technology type of
interface or core).
JRA3-AutoBahn gathers all relevant domain parameters in the path from source to destination
domain and the stitching engine runs in the destination domain. There is a minimum set of
stitching parameters, which have been identified to be kept in cNIS. These are: DomainName,
NOC Information, Core Technology Type, Interface Technology Type and Interface Rate (see
the reference below for details).
Priority: Medium
Frequency of use:
Release: 1.5
Notes:
Check the possible dependency between this use case and A34 (see 3.11.5)
AutoBAHN operates, in general, on technology domains. But to simplify the problem 1:1
relationship between administrative and technology domain is assumed.
Reference:
http://wiki.geant2.net/pub/SA3/CnisAgenda20070725/stitching_cNIS.ppt
http://wiki.geant2.net/pub/JRA3/Jra3WorkingArea/GN2-07-066v5-DJ3-5-3Report_on_Testing_of_Technology_Stitching.pdf
3.11.2 A37: Obtaining partitioned topology for a cNIS domain
Source: JRA3 requirement (requested the meeting in Munich: 2007.07.25-26)
Actors: cNIS Applications
Description:
See 3.11.3
Specification
JRA3-AutoBAHN application requires resource partitioning i.e. what resources are allocated
for AutoBAHN use and control. This needs to be generalised to state cNIS should be able to
store resource ownership. For example a request for abstracted topology should only consider
those network elements that AutoBAHN is authorised to use.
NRENs with existing DBs may find hard to make use of topology partitioning if the interface
to be honoured are not high level e.g. give me pruned/abstracted topology.
Priority: Medium
Frequency of use:
Release: 1.5
33
3.11.3 A49: Network topology partitioning
Source: JRA3 requirement (requested the meeting in Munich: 2007.07.25-26, updated by
Radek Krzywania)
Actors: cNIS Applications
Description:
The term ‘topology partitioning’ indicates a process of separating network topology into
several parts according to the ownership attribute. Partitioning precedes the topology pruning
operation (see A31 - 3.11.4), i.e. network topology is partitioned first and a selected part
(network partition) is processed in the next step to retrieve the pruned topology.
Specification
cNIS administrator shall be able to mark in cMA that a particular sub-system is dedicated to
AutoBahn (e.g. a set of VLANs number on a particular device). It indicates to carry out a
binding operation between a sub-system and a specific user or group of users.
Notes:
Partitioning constitutes a low level filtering mechanisms i.e. dividing a whole topology into
several parts. It's not a mechanism of access control (fine-grained authorization).
Priority: Medium
Frequency of use:
Release: 1.5
3.11.4 A31: Obtaining pruned topology for a cNIS Domain
Source: JRA3 requirements (Angelos Lenis, updated by Radek Krzywania)
Actors: cNIS Applications
Description:
JRA3 application requires access to pruned network topology. The trimming operation is
performed on the basis of the one or more entry parameters (given as input on a topology
information query). The value of such parameters for each object should be stored in cNIS.
Although the JRA3 BoD applications will retrieve the layer 2 network data only, but this
functionality is more generic and may be used to obtain pruned topology conforms to all
layers.
Specification
Pruning parameters are attributes of network sub-systems (e.g. interface name or interface
status). The list of these attributes is pre-defined in the system which means it cannot be
modified on demand (during cNIS runtime).
cNIS shall allow the AutoBahn application to make SQL-like queries like "select all links
with parameter1= x and parameter2 < y" or "select all paths between two nodes with desired
parameters".
Example

Delay attribute for a link. An application can query cNIS to retrieve a pruned topology
including only the links with a delay of < 5ms.
Priority: Medium
34
Frequency of use:
Release: 1.5
3.11.5 A34: Defining dynamic parameters for network topology elements
Source: JRA3 requirements (Angelos Lenis, updated by Radek Krzywania)
Actors: cNIS Applications
This requirement is not valid, as topology pruning will be based on fixed number of attributes
(see 3.11.4).
Description:
Some GN2 applications (like JRA3 BoD) need specific parameters describing the particular
network elements (e.g. weight of a link). However since this parameter can be interpreted in
different manner by various applications, cNIS shall deliver a mechanism to define
dynamically specific parameters and bind them with a single application.
Specification
JRA3 application uses the application specific parameters (like routing cost for an IP
interface) to enable topology pruning (see A31 - 3.11.4) for the top level applications.
cNIS performs comparison operations on the parameters’ values. It indicates that the value
must be a number.
Priority: Medium
Frequency of use:
3.11.6 A38: Checking existing Autobahn path
Source: JRA3 requirements (Y4 kick-off meeting in Poznan: 2007.09.24-26, updated by
Radek Krzywania)
Actors: cNIS applications
Description:
Paths are determined by AutoBahn Pathfinder, which queries cNIS whether a path is created.
A path is characterized by various of attributes like nodes, links, links bandwitdth, VLANs
numbers etc.
This requirement assumes that cNIS stores some dynamic information. It is valid until cNIS
starts supporting network topology changes notification.
Specification
To be provided later
Priority: Medium
Frequency of use: every reservation request (once every cNIS session?)
Release: 2.0 (?)
3.11.7 A23: Obtaining information about neighbouring nodes
Source: JRA1 requirements (Andreas Hanemann)
Actors: cNIS Applications
Description:
35
A functionality that would then be required by cNIS is a "get neighbors" functionality. It
means that perfSonar application contacts cNIS to get every neighbor of a node on a specified
level (for instance, for a router all directly connected routers or similar things for Ethernet
nodes).
Procedure
Details will be provided later
Priority: Low
Frequency of use:
Notes: JRA1 to going to discuss internally how the requests should look like (Andreas
Hanemman will provide this information) .
4. External interfaces
4.1 User interface
cNIS shall expose a user interface for cNIS Administrators, called cNIS Management
Application (cMA), which shall support the initialization, manual and semi-automatic
maintenance of the topology database. cMA shall not require installing any additional
software on the client’s workstation, except from a standards-compliant web browser. For the
details about the architecture and integration of cMA with cNIS, please see the cNIS Software
and Architectural Design document.
4.2 Communication interfaces
cNIS shall make the topology data available to the cNIS Applications in such a way as to
minimize the integration effort. Detailed specification of the cNIS access interfaces is
provided in the cNIS Export Interface Description document.
4.3 Software interfaces
In order to minimise the effort involved in transition of the existing GN2 applications to cNIS,
cNIS shall implement a number of software interface specifications developed within GN2,
including: JRA1 Lookup Service, JRA1 Topology Service and JRA5 AA infrastructure.
5. Non-functional requirements
According to a commonly-known definition, non-functional requirements specify criteria that
can be used to judge the operation of a system, rather than specific behaviours. Reliability,
scalability, or cost belongs to the group of typical non-functional requirements.
Similar to the cNIS use cases (see section 3), a single requirement is marked by a shortcut “B
plus a number”. The purpose of this marker is to simplify the reference to a specific
requirement from the external documents (e.g. cNIS Software and architectural design). The
marker does not have any relationship with the requirement content or its title.
5.1 B1: Security requirements
Common Network Information Service is treated as a resource, which is accessed by client
applications. Therefore it is required to design appropriate security mechanisms ensuring that
only those with relevant privileges can access the information stored in cNIS.
36
cNIS distinguishes two scenarios for the user (client)-server interaction. One where acts an
automated client needing to access a resource and one where the resource is accessed by a
human directed client.
The former scenario relates to the external applications (clients, see section 2.2.3), which
connect the cNIS to retrieve the network topology data. This is an interaction in read-only
mode only, although the future release of cNIS may support a read-write communication with
its clients (see section 2.3.2). Moreover, cNIS shall rely on authorization decision made by
the client itself, i.e. cNIS enables all data for the external services and the authorization is
taken on the higher level.
The latter scenario assumes, that the human directed client (the cNIS administrator, see
section 2.2.1) connects the user interface (cNIS Management Application) to perform various
administrative tasks.
cNIS Management Application shall provide two general levels of permissions for cNIS
Administrators: read-only access and read-write access. The former shall not allow any
modifications to be made to the topology and cNIS general data and hence can be granted to a
wide variety of users, not necessarily limited to local domain staff. The latter permissions
level shall allow modification of any topology element. and it will most likely be granted only
to local domain administrators and NOC staff.
In order to perform special administrative tasks which includes managing cNIS general data
(e.g. list of users) the third access level is needed. This level, called administrative one, allows
to perform read/write operations and additionally carry out system-related activities (e.g.
users management, location management)
To obtain more information about the cNIS AA solutions please review the document “cNIS
security notes”.
5.1.1 EduGain integration
EduGain constitutes an Authentication and Authorization Infrastructure (AAI) able to support
seamless, and location independent, access to application services, and to provide
authentication and authorization services to GN2 applications. cNIS shall integrate with
EduGain to base authorization procedures on this infrastructure.
EduGain exposes several profiles to external applications, cNIS shall take advantage of two of
them:

web profile – cNIS administrator invokes cMA login page and his/her request is
automatically redirected to the EduGain service, i.e. 'Where are you from' - web page
(WAYF). Once user’s home location is chosen he/she is taken to his/her home domain
identity provider (e.g. GIdP) to log in. Upon successful authentication cNIS
administrator is redirected back the original resource but this time with appropriate
assertions and attributes in the request. cMA checks the assertion and allows to go
through and access the protected resource
Authentication operation is carried out on the transport level and it is handled by the
application container (e.g. Tomcat filters). It means that cMA is not directly involved
in EduGain interaction.

Web Service profile – when a cNIS application connects the cNIS Web Service
interface, a request is authenticated in EduGain using appropriate security mechanism
(e.g. SAML). When success, cNIS retrieves as a response user specific data from
EduGain, otherwise request processing is cancelled and an error message is thrown.
37
Authentication operation is carried out on the message layer (SOAP) and it is handled
by the SOAP implementation stack.
EduGain integration causes, that there is no user management either as authorisation is based
upon the attributes get back from eduGAIN..
As cMA is meant for domain users only it may not need to link to eduGAIN at all. The danger
being that some other domain can give itself admin rights. What needs to be eduGAIN
enabled are the web service interfaces and no UI is required for that. The other solution is to
have a possibility to select an appropriate security mechanism for cMA - internal AA or
eduGAIN AA.
5.2 B2: Migration to cNIS
As the cNIS applications that are already implemented (e.g. SA3 AMPS, JRA1 CNM tool)
use their own topology databases, it is desirable to support a possibly smooth transition from
the internal topology databases to the cNIS for these applications. Towards that end, in
addition to the primary data access interface through which all kinds of topology data will be
available, cNIS shall offer a number of temporary interfaces offering limited functionality for
the existing applications. It is expected that when new functionality is added to cNIS, it shall
be available in the primary format, but not in the temporary interfaces. The ultimate goal
would be to eventually migrate all the applications to the primary interface and discontinue
support for the temporary interfaces.
For more information about the cNIS interfaces, please see the cNIS Export Interface
Description document.
5.3 B3: Service monitoring
The cNIS service should provide following methods for monitoring its state:

“ping” – it’s done by network infrastructure;

HTTP request-response simple interaction – remote application sends HTTP request to
cNIS to find out, if it’s still working. cNIS sends back response reporting all is OK.

Web-service simple interaction – remote application invokes remote method of cNIS.
cNIS sends back “OK” message as a method return value.
This functionality is directed to the monitoring applications, which check in a regular fashion
if cNIS is up and running.
To be updated with Smokeping environment support
5.4 B4: Maintaining the historical data
cNIS should allow data archiving after a configurable data retention period. The archiving
should be automatic or manually triggered and it should be possible to reload archived data.
Premises
The volume of historical data depends more upon the probability of change as compared to
the number of years of data kept. In a given network with low probability of change 3 years of
historical data may be less than 1 year of historical data in another network with high
probability of change.
Data Retention Policy
38
Data retention policy should be based upon business needs rather than purely on application
efficiency issues. It shall be a configurable parameter, which individual domains set to its own
needs. And default value for this parameter can be 1 year
Archiving interval specifies how often the procedure which archives data is launched (for
example once a month, a year). This value is configurable and it equals data retention period
by default.
5.5 B6: Persistence of the network discovery results
Administrator may want to see last network discovery results any time. The results of the
network discovery process should be always available and resistant to the cNIS service
shutdown or restart.
In order to meet this requirement the output data have to be stored into a non-volatile memory
(e.g. hard disk).
5.6 B5: Service registration
cNIS needs a unified service directory in order to be located by its clients. Moreover, the
central repository guarantees the uniqueness of the multiple cNIS instances, which may be
deployed in separate domains. The external applications, which operate on multiple
administrative domains (e.g. JRA4 End-to-End (E2E) Monitoring System, see section 2.1.4),
demand to discover and select the appropriate cNIS service from the registry. Taking into
account the unambiguous naming convention for cNIS nodes (see 2.3.4) it is possible to
correlate the data between various cNIS instances and thus compose a multi-domain link,
which is made of a set of single-domain and inter-domain links (see A47 - 3.10.2)
The JRA1 Lookup Service (LS) is the component which will act as a central directory service.
Further description to appear here.
6. Glossary
cMA
cNIS Management Application (cMA) will enable the cNIS Administrator to initialize,
maintain and update the topology database.
cNIS Domain
The administrative domain for which cNIS is deployed and managed. cNIS Domain can
consist of many technology domains, e.g. SDH or Ethernet domains.
IP Topology
Topology of the IP (ISO/OSI Layer 3) network elements in the cNIS Domain.
7. Open issues
A dynamic list of open issues and questions
39