Topology Service resources

From GEANT2-JRA1 Wiki

Contents 1 Topology Service Design 1.1 Targeted functionality 1.2 Required interactions 1.3 Data Format 1.4 Contributors 1.5 Prototypical implementation 1.6 ToS Role Clarification 1.7 ToS Use Cases 1.8 Open Issues

Topology Service Design

What would a topology service will be useful for?

• Developers of visualisation tools who need to access topology information (for e.g. a map base visualisation tool), are capable to retrieve and display the topology information as the topology information will be presented to them in a well specified format. In addition, thanks to the lookup service, they are able to discover where are the topology service from each domain.
• Large projects haivng distributed sites can visualise the topology of different networks between their site and get a better understanding of the physical topology (which can help them when taking decision about where to ship data or to install equipment).
• Network researchers who are working on traffic engineering and who often need examples of topology would be able to retrieve the information easily.

Targeted functionality

The Topology Service (ToS) is designed to archive network topology information needed for the operation of perfSONAR and its visualisation tools. It should be easy to retrieve topology information for building maps for projects forming an overlay of the network basic infrastructure. The ToS will define a topology information data format to allow for an easy processing of topology information. Besides of the current network topology the ToS should also contain past and future (i.e. planned) network configurations. By registering at the Lookup Service the topology information will become available at an easy to retrieve location.

The ToS will contain layer 3 data in the first place (no MPLS, no IP tunnels). Depending on the progress of the collaboration with JRA3 and JRA4 layer 2 (Ethernet) and layer 1 information may be added lateron.

In addition, it should be possible to find out which is the closest MP to an IP address or a router. The Topology Service has to support the Lookup Service in providing this information.

An open issue is whether routing information should be contained within the Lookup service. This information could include IGP costs, BGP MEDs, communities, BGP filters. However, the amount of routing data and its up-to-dateness are critical for this kind of information. A starting point for this kind on information can be more or less static IP address filters.

Required interactions

The following interactions should be provided for the ToS.

• Update of information: The network administrators need to have the possibility to transfer updates of the network topology to the ToS. Therefore, the data format from each network has to be transformed to be compliant with the ToS data structure. To avoid a lot of maintenance scripts should be written to convent the proprietary topology formats to the ToS format. The aim is that some of these scripts for typical routing protocols are provided by JRA1.
• Register at LS: The ToS needs to have the possibility to register itself at the LS (extend generic register procedure from Maciej). The registry information has to contain information about the capabilities of the ToS, e.g. the topologies of which networks are available. A furher differentiation into L3, L2 information, IPv4/IPv6 may be required in the future if different ToS are set up for these types of data.
• Retrieval of topology information: Clients need to have the possibility to retrieve network topology information. It needs to be discussed which granularity is needed (whole networks, a component and all neighbors, etc).
• Client notification: It might be interesting for clients to register themselves at a ToS and to be informed about changes in the topology automatically.

The NM-WG schema will be extended to transfer these kinds of data. An idea is to extend the GXL Graph Modeling Language which is also based on XML for the exchange of network topologies.

Data Format

The visualisation database schema can be used as starting point for the ToS format as it already contains information about

• network elements (routers, switches, monitoring stations)
• links (including multipoint links)
• interfaces (layer 3, will be extended towards layer 1 and 2 in collaboration with JRA3)

In addition, a previous version of NM-WG already contained some topology information.

Contributors

• DFN Munich (Andreas Hanemann, David Schmitz)
• University of Delaware/Internet2 (Martin Swany)
• RedIRIS (Ulisses Alonso)

Prototypical implementation

The Topology Service is already on the roadmap for the deliverable in May. Therefore, it is proposed to provide some prototypical implementation.

As DFN Munich has already collected some topology information the service could be provided running on the CNM server. Its first functionality could be the complete dump of the topology information into an XML file which is structured according to the NM-WG (topology) schema. Then, some options can be included into the query, e.g. just get the data of a single network. Later it should be possible to transfer new topology information in NMWG format to the Topology Service which then updates its topology database.

ToS Role Clarification

There has been some discussion about understanding the role of the Topology Service. In the GFD it has been roughly specified as a kind of Transformation Service which extracts topology information out of measurements which are contained in Measurement Archives. It then publishes the topology information into MAs or the Lookup Service.

However, it is proposed to make a distinction between the storage of topology information and the topology data extraction. The Topology Service should be seen as an archive which stores the current, past, and maybe in case of planned changes future network topology. The topology can either be entered via extraction scripts from static files in the beginning or later from measurements (e.g. traceroutes) which reveal the topology. For this transformation which accesses a Measurement Archives, extracts topology information, and puts into the Topology Service a specialized Transformation Service should be defined. A proposal for its name is "Topology Extraction Service".

ToS Use Cases

1. Topology visualisation: A user would like to see the topology of his NRENs and other networks. Therefore, a map-based client tool (Nemo, CNM) is accessed which shows the topology information. However, the client tool needs to have the topology information itself and retrieves it on a regular basis from the topology service.
2. Basic information for projects: A large-scale project like EGEE would like to build a visualisation of their own network which is an overlay of the networks being contained in one or more ToS. The projects writes their own client which retrieves basic network topology information from the ToS, enriches it with project-internal information (e.g. about VPN connections) and provides these data to project members.
3. Network optimisation research: A researcher needs example topologies from the real-world in order to perform some experiments. Maybe he would like to simulate the effects of a modified routing algorithm with respect to network utilisation. Therefore, the ToS gives him the topology of several networks in a standard format. The results of the network simulations could not be of interest for using the network, but could also be useful to optimize network topologies. Some experiments with this purpose are interested in havin IGP costs and BGP policies within the ToS.
4. Cross-border collaboration: Two or maybe more networks (NRENs) might want to optimise their network configuration. If they want to do this with repect to an overall optimisation without only assuming a local perspective the standardised ToS format can be a big advantage for them. They can take the topologies of all networks and optimise them (using supporting tools) without having to write different import procedures for different networks. Examples for such situations could be how to optimise the routing in parallel links between Abilene and Geant (and maybe connected networks). Another situation which is more relavant with respect to layer 1/2 is to decide whether a research network should be directly connected to Geant or whehter it is preferable to connect it to a neighboring NREN which is already connected to Geant.
5. Network transparency restrictions: A network would like to make its topology transparent for people, but some restriction are applied. The ToS will offers attributes and support for transparency policies so that the ToS will ease the implementation of these security policies.
6. Finding closest MP: A user would like to perform an active measurement between two locations in the network. Therefore, the "nearest" MPs for the locations are needed. Here, the role of the ToS needs to be further elaborated since "nearest" can be understood differently. Routines could be included into the ToS to find the closed MP by using the hop distance. However, the user might want to consider MPs only along the path. As the routing is supposed to be not contained in the ToS, this cannot be determined purely by the ToS. One possibility would be to provide a path (i.e. a list of locations) to the ToS which determines where MPs are located on the path. It is not clear whether it is necessary to store the information which metrics are provided by which MP within the ToS or whether it is sufficient to have this information in the LS.

Open Issues

• How much routing information is desirable within the ToS? Trade-off between effort for maintaining the amount of possible routing information and benefit.