This section gives an overview of C-BGP's architecture. A sketch of the architecture is shown in Figure 1. The architecture is articulated around 3 main conceptual layers: a scheduling layer, an IP simulation layer and a BGP simulation layer.

Figure 1: C-BGP's architecture.

The Scheduling Layer is the central part of the routing solver. It contains a sequence of pending events that represent messages scheduled for delivery to particular network nodes. The scheduler enqueues new events when a node sends a message to another one. These messages are later dequeued and delivered to the corresponding node.

The IP Simulation Layer contains several components. The first component is a representation of the IP-layer topology of the modeled network. This is basically a data structure that holds a graph of nodes and links. The second component of IP Simulation Layer is a static IGP model. This model is responsible for computing the intradomain routes of each IGP domain, based on the knowledge of the complete domain topology. The intradomain routes are stored within a routing table along with static routes (configured manually). Finally, the third component of the IP Simulation Layer is an IP router model which is responsible for delivering messages to the BGP layer if the message is destined locally or for forwarding the message to another node if the message is destined for a remote destination.

The BGP Simulation Layer also contains several components. The first component is the BGP layer's configuration. This includes the graph of BGP sessions as well as the configuration of the various BGP routers in the modelled network. The second component of the BGP Simulation Layer is the BGP routing model. This model contains the BGP decision process as well as the route filters. The BGP routing model intensively relies on a set of routing tables which contains the BGP routes known by each BGP router as well as the best routes currently selected by each router. The BGP model implemented in C-BGP is not hindered by the transmission of BGP messages over simulated TCP connections as in packet-level simulators such as SSFNet or J-Sim. In addition, C-BGP does not model session establishment and timers (MRAI, dampening).

In addition to these components, C-BGP contains an Application Programming Interface (API) that allows to configure the solver and to extract its results. The API is used to provide a user-interface through a Command-Line Interface (CLI), interaction with Perl/Python scripts and interaction with Java programs through a Java Native Interface (JNI). In order to ease the setup of large simulations, C-BGP also supports various well-known file formats. For example, it is able to load AS-level interdomain topologies such as the ones produced by Subramanian et al (University of Berkeley). It is also able to read BGP routing table dumps in MRT format. This can be used to inject real BGP routing tables into the C-BGP model. Finally, C-BGP can write the results of its computation as well as the BGP messages exchanged during the simulation in MRT or CISCO-like (show ip bgp) format. In this manner, existing scripts that crunch real-world MRT data can be easily adapted to work on the C-BGP output.