Equipos que la conforman

Discovery simulation script

The role of the discovery simulation script is to initialize the topology model and C-BGP instance, import the previously generated discovery setup available as an XML file, execute the chosen discovery algorithm (classic traceroute or Doubletree) and finally provide post-execution information about its performance. The script is launched using the specification of the AS topology and the XML discovery files:

./performDiscovery [options] <as_topology_file> <xml_discovery_file>

The main options that can be specified at the script call are:

• Router-level topology (-r) file

• Disable Doubletree (-t) perform classic traceroute discovery execution

• Number of path length evaluations (-h) for Doubletree initial hop

• Doubletree probability (-p) of hitting a destination on the first probe

• Bloom filter capacity (-c)

• Bloom filter error rate (-e)

The script starts off by initializing the topology model, as explained previously, and imports

the XML discovery setup into a data structure representing the global discovery system’s state.

The script then sets up a C-BGP instance with the help of the tools.pm module which

typically implements low-level subroutines used for tasks such as number format conversions, file information extraction, initializing, setting up and checking the state of the C-BGP instance. Once the instance is running and has been initialized with the specified AS-level or optional router-level topology, the script launches the execution of the classic traceroute or Doubletree

algorithm to the algorithms.pmmodule. Once the discovery is over, the script is in charge of

computing performance results as further described in Section 4.2.3. Discovery algorithms module

The discovery algorithms’ module contains the implementations of possible discovery schemes.

The module has three main subroutines,traceroute,compute hopsanddoubletree, to which

are passed the global discovery state and the topology model.

The classical discovery traceroute subroutine cycles through the set of clusters present in

the discovery hash. If a cluster has a common destination set, one prefix of /16 length8

per destination is propagated into the simulated network and traceroute requests from all the cluster’s sources are then sent to the C-BGP instance. If no common destination set is available, the subroutine first cycles on the sources and then on their individual destination sets.

If the C-BGP instance’s response has a successful status, each address in the route, apart from the source address, is considered to have successfully responded to a probe and has thus been discovered. In addition, each link leading to a responding interface is also considered to have been successfully discovered.

Note that the router topology graph is actually vertex-counted and edge-counted meaning the

graph will count the number of times each node or link has been added to it. This can be used to efficiently keep track of not only discovered interfaces and links, but also of the number of times they were individually probed. This is why, once an interface successfully responds to a probe during a discovery scheme, it is added again to the topology model, as well as the link leading to it. Thus, once a discovery scheme is over, identifying nodes and links with a count larger than 1 yields the discovered interfaces and links.

The compute hops subroutine relative to the Doubletree algorithm is in charge of evaluating

8_{If the destination router’s IP address is A.B.C.D, the announced prefix will be A.B.0.0/16. If needed, please} refer back to Section 2.1.2.

the initial hop for each source in the discovery setup. It does so by selecting a specified number of random destinations, from the source’s available common or individual set. It then performs their traceroutes and uses the discovered path lengths to compute their cumulative distribution.

Choosing the initial hop count to ensure that there is the probabilityp of hitting a destination

on the first probe is then straightforward.

The Doubletree subroutine doubletree has a similar structure to the classical one, cycling

through clusters, then either through its common destination set if present, or else through its sources. Ideally individual interface probes should then be performed, unfortunately C-BGP does not provide this feature. Classic traceroute requests are thus performed and the difference lies in the way they are handled by the subroutine.

In order to perform forward and backward probing, the global discovery state contains one global

setF per cluster and their sources’ localB sets. By default these are respectively implemented

as a Bloom filter and hashes, although global sets can also be stored as hashes if specified. Forward and backward schemes then take place by considering that an interface is responding at a specific hop count if it exists at that same index value in the response route. Note that, when an interface is not responding and its hop value is larger than 1, then it is halved. Within the context of the C-BGP environment, the only reason such a case might appear is if the current hop is beyond the current destination.