# A Multicast Routing Scheme for the Internet: Simulation and Experimentation in Large-Scale Networks
## 4 Experimental Platform
### GCMR Implementation  
Figure 6 depicts the architecture and the different modules of a GCMR-capable node. The Routing Core (RC) and the Routing communication Protocol (RP) modules are the two fundamental components of the routing engine. The former is a collection of processes that a GCMR-capable node must implement in order to perform its functions. The latter module is made up of a set of objects and messages that allow GCMR nodes to communicate with one another.  
The key operations involved in the GCMR procedure are found in the RC module. This module also contains the database (which includes the data for the TIB and the MRIB tables), the neighbours information, the multicast groups created and two interfaces. One interface is to connect the RC module with the RP module. The other interface is to communication this node with an external client (for instance, an application) which can  
Figure 5: Protocols required for multicast: (**a**) conventional scheme: a unicast routing, a multicast routing, and a membership subscription protocol; (**b**) GCMR only requires GCMR.  
request a given GCMR functionality such as creating a new multicast group, joining an existing multicast group, and detaching the node from a multicast group.  
All GCMR operations requiring a communication between nodes are implemented in the RP module. This includes therefore all messages involved in the construction and maintenance of the MDT described in Section 3.2: request R and answer A used during the two stage search process; join J and detach D a node to/from the MDT; and failure detection S to detect and localise a node/link failure. Finally, the RP module is also in charge of the communication with the Zebra daemon through the ZAPI interface in order to request the configuration of the interfaces when a node is added or removed to/from a multicast group.  
As commented previously, Quagga provides a powerful routing engine but does not come with a forwarding engine. Therefore, we implemented a forwarding module called SMC_Client. This module is able to automatically generate requests to add or remove multicast routes and send them to the SMCRoute daemon ([[https://github.com/troglobit/smcroute](https://github.com/troglobit/smcroute)]([https://github.com/troglobit/smcroute](https://github.com/troglobit/smcroute)) accessed on 15 September 2021). The SMCRoute is a tool to manage and monitor multicast routes directly in the UNIX/Linux kernel.  
Finally, the Finite State Machine (FSM) implementation defines the sequence of actions to be followed by the GCMR engine during each MDT computation. Its structure is depicted in Figure 7. Five states are defined:  
* Idle: where GCMR initialises resources and structures;
* Local search: when a node sends a local \(R\) message to its neighbours or receives it from a neighbour;
* Global search: when local search fails, a node moves to the global search;
* Join: when a node receives a \(J\) message and remains in this state as long as a \(D\) message is received. In this case, the detach procedure is executed and the node is removed from MDT and returns to the idle state.  
Figure 6: The GCMR node architecture.  
* Fail: when a node does not receive a \(S\) message from the source, it enters in the fail state and tries to recover it. It returns to the join state if the \(S\) message is received back.