Main Menu

Project Life Cycle

cNIS_1.0-2.0_requirements_analysis-0.42.doc

Common Network Information Service

Requirements Analysis


Table of contents

1.               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

2.               Overall description               6

2.1               Geant2 activities involved               6

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               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

3.               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

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               A19: Obtaining FrameRelay topology for a cNIS Domain               28

3.8               ATM               29

3.8.1               A18: Obtaining ATM topology for a cNIS Domain               29

3.9               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.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

4.               External interfaces               36

4.1               User interface               36

4.2               Communication interfaces               36

4.3               Software interfaces               36

5.               Non-functional requirements               36

5.1               B1: Security requirements               36

5.1.1               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


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:

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 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 multi-gigabit-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 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 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:

       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)?

       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

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 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 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

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:

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.

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.

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.

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).

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?

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.

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:

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.

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 );

       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

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

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 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

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

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

       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:

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.

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-3-Report_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

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

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:

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.

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.
Authentication operation is carried out on the message layer (SOAP) and it is handled by the SOAP implementation stack.

EduGain integration causes, that t here 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

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