# Scalable and Reliable Data Center Networks by Combining Source Routing and Automatic Labelling
## 3 The eTorii DCN
### Scalability: Zero-Table Multiple-Path Routing  
Routing in eTorii is grounded on the fact that layer-2 addresses are meaningful, instead of randomly defined by the manufacturer. In other words, eTorii leverages the previously assigned HLMACs, conveyed now in the data frames instead of the original MAC addresses, to efficiently forward traffic. This principle of meaningful MAC addresses is supported by a recent amendment to IEEE Std 802, in which IEEE 802 MAC addresses are defined, published in 2017 [24]. Accordingly, eTorii is founded on a similar approach to source routing [14; 25], as routing information is transported in the packets, allowing a reduction in the routing table sizes. However, the main advantage of eTorii is that it does not require any overhead as it reuses the already existing MAC fields of the frames. As a consequence, eTorii boosts scalability because it tends towards zero-entry tables.  
The routing procedure is defined as follows: When a host, e.g., \(h1\), starts a communication with another, such as \(h41\), it will first send this traffic to its corresponding ToR, which is \(S7\), according to Figure 3. Switch \(S7\) will then be in charge of translating the real MAC address from \(h1\), defined by the manufacturer, into a corresponding meaningful HLMAC, and it will apply the same action to the MAC address of \(h41\), as defined in Torii [9]. For instance, in Figure 3, if \(S7\) assigns the HLMACs with values 2.7.6.1 and 2.4.4.1 to \(h1\) and to \(h41\), respectively, the data packet will follow a path towards the core switch \(S2\) in the topology (traversing \(S7\) and \(S3\)), as it is the switch from which HLMACs with prefix 2 were populated, and then it will go down through port with ID 4 to switch \(S5\), through port with ID 4 to switch \(S9\), and through port with ID 1 until reaching \(h41\). These 4 values (2, 4, 4 and 1) are basically the digits contained the HLMAC assigned to \(h41\), which is carried out in the standard MAC address field of the packet. The first value (the prefix) is leveraged to send the packet up towards the correlated core switch, and the rest of values (the suffix) identify the list of switch ports traversed to reach the destination. For this reason, there is no need of routing tables, except for some entries to save the labels or IDs associated with each port, locally at each switch. These lists of saved IDs are independent of the number of active hosts communicating and might be configure to any size, up to the network administrator; the only implication is that the more labels a switch has, the bigger the amount of multiple alternative paths.  
Each end host has a set of HLMACs, that is, a set of multiple paths to be reached. If, alternatively, \(S7\) assigned a different HLMAC to \(h41\) from the available set, like 1.4.4.1, the procedure would have been similar except for the traversed path, which would go through the core switch \(S1\) first, instead of \(S2\). That is, ToR switches are in charge of selecting the appropriate HLMACs (and hence paths) and, for this reason, they are capable of balancing the load in the network based on diverse criteria, which is an orthogonal aspect to the definition of eTorii, but proves that eTorii grants different behaviours based on this assignment of meaningful addresses.