On the Mathematics of
Data Centre Network Topologies

Data centres are expanding both in terms of their size and their importance as computational platforms for cloud computing, web search, social networking, and so on. There is an increasing demand that data centres incorporate more and more servers but so that overall computational efficiency is not compromised through excessive traffic. A key factor as to the eventual performance of a data centre is the data centre network (DCN); that is, the interconnection fabric of the servers and switches within the data centre. As we strive to incorporate more and more servers, new topologies are being developed so as to cope with the increase in scale and best utilize the additional computational power. It is with topological aspects of DCNs that we are concerned in this paper.

The traditional design of a DCN is switch-centric so that the routing intelligence resides amongst the switches, with the servers behaving only as computational nodes. In switch-centric DCNs, there are no direct server-to-server links; only server-to-switch and switch-to-switch links. Switch-centric DCNs are traditionally tree-like with servers located at the ‘leaves’ of the tree-like structure. Examples include ElasticTree [9], VL2 [8], HyperX [2], Portland [12], and Flattened Butterfly [1], although the dominating switch-centric DCN is Fat-Tree [3]. Whilst it is generally acknowledged that tree-like, switch-centric DCNs have their limitations when it comes to, for example, scalability, due to the size of routing tables at the switches, switch-centric DCNs remain popular and can usually be constructed from commodity hardware. A more recent paradigm, namely the server-centric DCN, has emerged so that deficiencies of the tree-like, switch-centric DCNs might be ameliorated. Server-centric DCNs reflect that the routing intelligence resides within the servers with switches operating only as dumb crossbars. In server-centric DCNs there are only server-to-switch and server-to-server links. However, server-centric DCNs also suffer from deficiencies such as packet relay overheads caused by the need to route packets within the server; moreover, server-centric DCNs have yet to make it into the commercial mainstream (the reader is referred to [10] for an overview of the state of the art as regards DCN architectural design). It is with the construction of switch-centric DCNs that we are concerned here.

It is difficult to design computationally efficient (switch-centric) DCNs so as to incorporate large numbers of servers as there are additional considerations to take into account. For example, switches and (especially) servers in data centres have a limited number of ports with a consequence being that the more servers there are, the greater the average or worst-case link-count between two distinct servers; hence, there is a packet latency overhead to be borne. Also, so as to better support routing, fault-tolerance, and load-balancing, we would prefer that there are numerous alternative paths within the DCN joining any two distinct servers; that is, that there is path diversity. There are many other design parameters to bear in mind relating to, for example, incremental scalability, throughput, cost, oversubscription, energy consumption, latency, and security (see, for example, [15] for an overview). The upshot is that the DCN designer has to simultaneously secure a number of performance characteristics, some of which are competing against each other; this makes the DCN design space difficult to work in.

A recent proposal in [13] advocated the use of combinatorial design theory in order to design switch-centric DCNs; these DCNs have beneficial properties as regards incorporating more servers and possessing path diversity yet it is possible to limit the worst-case link-length of server-to-server shortest paths (and so, ultimately, achieve better control over packet latency in a DCN). The use of combinatorial designs within the study of general interconnection networks is not new and originated in [4] where the targeted networks involved processors communicating via buses (the reader is referred to [5] for a range of applications of combinatorial design theory within computer science). A hypergraph framework was developed in [4] where the hypergraph nodes represent the processors and the hyperedges the buses. Likewise, an analogous framework was developed in [13] but where the hypergraph nodes and edges both represent switches so that the pendant servers ‘hang off’ some of the switches (we present a detailed description of this framework in Section 3.3). In [13], the ubiquitous switch-centric Fat-Tree DCN from [3] was used as a yardstick against which to compare the new DCN designs developed in [13] under the normalization that all DCNs are to have the same worst-case link-length of server-to-server shortest paths, namely $6$, as this equals the worst-case link-length of server-to-server shortest paths in the Fat-Tree DCN. It was shown that more servers can be incorporated within the new DCNs yet, crucially, the resulting DCNs have good path diversity. It is the algebraic properties (relating to symmetry and balance) possessed by transversal designs that enable the constructions and analysis as described in [13]. One slight difficulty with the original and novel approach taken in [13] is that some of the path diversity results derived there are incorrect (as we explain later in Section 4.1).

In this paper we return to the framework of [13] and formulate and prove path diversity results for the switch-centric DCNs constructed using the methods of that paper. As our concern is entirely with topological properties of DCNs, henceforth we abstract our DCNs as undirected graphs where the nodes are to represent servers and switches and the edges point-to-point links. The crux of the construction in [13] is (essentially) to build a bipartite graph using a systematic method, called the $3$-step method, involving a different ‘base’ bipartite graph and a transversal design, and to convert the resulting bipartite graph into switch-centric DCNs (in a variety of ways). After explaining how hypergraphs and transversal designs can all be considered as bipartite graphs in Section 2, in Section 3 we provide a detailed description of the 3-step framework from [13] and explain how the bipartite graphs constructed are converted into switch-centric DCNs. Next, we revisit the results from [13]. In particular, in Section 4 we correct and extend the analysis in [13] and affirm that using the $3$-step method from [13], we can build switch-centric DCNs: with many more servers than the Fat-Tree DCN yet so that, like the Fat-Tree, every server-to-server shortest path has length at most $6$; and so that (assuming some numeric conditions on the base bipartite graph and the transversal design) we can find pairwise link-disjoint paths from all of the servers adjacent to a particular switch to all of the servers adjacent to any other switch. Moreover, we provide an upper bound on the lengths of the paths constructed in terms of the diameter of the base bipartite graph (see Theorem 4). We also deal with a scenario missing from [13] (see part (b) of Theorem 4). As we explain, the general situation is more subtle than was assumed in [13].

The DCN path diversity, as we have described it above, comes about from building bipartite graphs (which are subsequently converted to DCNs) so that given any two distinct nodes, there are numerous node-disjoint paths joining these two nodes; that is, these bipartite graphs have one-to-one path diversity. In Section 5, we go on to show that we can actually build numerous edge-disjoint paths from a source node to different destination nodes in our bipartite graphs; that is, we have one-to-many path diversity. The DCNs obtained from these bipartite graphs are such that (assuming some numeric conditions on the base bipartite graph and the transversal design) we can find pairwise link-disjoint paths from all of the servers adjacent to some switch to any identically-sized collection of servers (irrespective of which switch they are adjacent to). Consequently, we show that our DCNs provide support for additional communication patterns that are prevalent within data centre networks. It should be noted that one-to-many and many-to-many communication patterns are commonplace in data centres; for example in applications involving MapReduce.

This paper is unashamedly theoretical. However, we demonstrate that not only is there interesting combinatorics within the practical world of DCN design but that combinatorial mathematics can potentially contribute to the DCN design space on a practical level. We feel that the mathematical aspects of DCNs have so far remained almost completely unexamined and we advocate a closer theoretical scrutiny of DCNs both as a model of computation and in relation to the vast swathes of research on general interconnection networks. We mention some practical considerations and directions for further research in the Conclusion.

A switch-centric DCN is abstracted as a graph (which we also refer to as a DCN) where the nodes are partitioned into two sets: there are server-nodes; and there are switch-nodes. Of course, the server-nodes correspond to servers in the DCN and the switch-nodes to switches; note that immediately there are practical design limitations imposed by the number of ports in a real switch and the number of NIC ports in a real server (we sometimes talk of the number of ports of a switch-node rather than its degree). Furthermore, in switch-centric DCNs there are no links joining one server-node directly to another server-node (because all routing within a switch-centric DCN falls within the purview of the switches). Of concern to us in this paper will be incorporating a comparatively large number of server-nodes within our DCNs but so that the maximum length of a shortest path joining any two server-nodes, that is, the diameter of the DCN, is kept within a given bound, where the length of such a path is the number of distinct links on the path. Essentially, we will be comparing DCNs as to how many server-nodes they incorporate but when their diameters are normalized.

However, DCNs must also possess other properties to make them usable within a data centre context. For example, they also need to: be scalable and incrementally scalable (that is, have the capacity to cope with increases in components and data); have low message latency; provide for high overall throughput (under a range of traffic patterns); be able to tolerate (a limited number of) faults; be energy efficient; be both economically and physically viable; and support virtualization (that is, the partitioning of the DCN into virtual networks on a dynamic basis), amongst many other things. Support for some of these properties can be measured using graph theory; for example, the diameter of the DCN gives guidance as regards the expected message latency. Of particular interest to us will be path diversity which we define (somewhat informally) as the capacity to send data without inducing additional congestion or so as to cope with existing congestion or faults. There are two contexts of interest to us: the one-to-one (or unicast) context, when a source server-node wishes to send data to a destination server-node by the utilization of independent paths (we will return to what we mean by ‘independent’ soon); and the one-to-many (or multicast) context, when a source server-node wishes to send data to a number of destination server-nodes so that the different transmissions do not induce congestion. Path diversity is highly relevant to a number of the above properties such as latency and scalability, where different paths are used to split and balance loads, and fault tolerance, where different paths provide alternative means of transit in the case of faults. That this is the case in the one-to-one context is obvious; however, the need for data centres to support data replication and applications like MapReduce [6] makes path diversity crucial in a one-to-many context too. As we shall soon see, just as with latency, the independence of paths can be considered graph-theoretically.

Hypergraphs provide the original framework for the $3$-step construction (to be defined later) as employed in [4, 13]: in [4], hypergraphs were used to model bus interconnection networks; and in [13], hypergraphs were used to model data centre networks. For the moment, and in order to appreciate the context of [4, 13], we retain this hypergraph framework before we phrase all content in this introduction within an encompassing bipartite graph framework.

A hypergraph $H=(V,E)$ consists of a finite set $V$ of nodes together with a finite set $E$ of hyperedges where each hyperedge is a non-empty set of nodes and each node appears in at least one hyperedge. The degree of a node is the number of hyperedges containing it and the rank of a hyperedge is its size as a subset of $V$. A hypergraph is regular (resp. uniform) if every node has the same degree (resp. every hyperedge has the same rank) with this degree (resp. rank) being the degree (resp. rank) of the hypergraph. Every graph $G=(V,E)$ has a natural representation as a hypergraph: the nodes of the hypergraph are $V$; and the hyperedges are $E$, where the hyperedge $e$ consists of the pair of nodes incident with the edge $e$ of $G$.

We can represent any hypergraph $H=(V,E)$ as a bipartite graph: the node set of the bipartite graph is $V\cup E$; and there is an edge $(v,e)$, for $v\in V$ and $e\in E$, in the bipartite graph if, and only if, $v\in e$ in the hypergraph. It is clear that this yields a one-to-one correspondence between hypergraphs and bipartite graphs (without isolated nodes) that come complete with a partition of the elements into a ‘left-hand side’, which will correspond to the nodes of the hypergraph, and a ‘right-hand side’, which will correspond to the hyperedges of the hypergraph. We assume (henceforth) that every bipartite graph comes equipped with such a partition and for clarity from now on we refer to the nodes on the left-hand side as nodes and the nodes on the right-hand side as blocks (this is in keeping with our upcoming realisation of transversal designs as bipartite graphs). Likewise, we refer to the degree of a node as its degree and the degree of a block as its rank. A bipartite graph corresponding to a regular, uniform hypergraph of degree $d$ and rank $\Delta$ is called a $(d,\Delta)$-bipartite graph. Every bipartite graph (and so every hypergraph) also describes its dual bipartite graph (or alternatively its dual hypergraph) where the roles of the nodes on the left-hand side and the blocks on the right-hand side of the partition are reversed in the definition of the bipartite graph; so, for example, the dual bipartite graph of a $(d,\Delta)$-bipartite graph is regular of degree $\Delta$ and uniform of rank $d$.

Note that if $G$ is a bipartite graph then it corresponds to a hypergraph via our representation above and it also corresponds to a hypergraph via the natural representation highlighted in Section 2.2. The two hypergraphs corresponding to the same bipartite graph are different and we are never interested in the representation of a bipartite graph as a hypergraph via the natural representation of Section 2.2.

A path in some hypergraph $H=(V,E)$ (or the corresponding bipartite graph) is an alternating sequence of nodes and hyperedges so that all nodes are distinct, all hyperedges are distinct, and a node $v\in V$ follows or preceeds a hyperedge $e\in E$ in the sequence only if $v\in e$ in the hypergraph (or $(v,e)$ is an edge in the corresponding bipartite graph). The first element of some path is the source and the final element the destination. The length of any path is its length in the bipartite graph corresponding to the hypergraph, and the distance between two distinct elements of $V\cup E$ is the length of a shortest path joining these two elements in the corresponding bipartite graph. The diameter of $H$ is the maximum of the distances between every pair of distinct nodes of $V$, and the line-diameter of $H$ is the maximum of the distances between every pair of distinct hyperedges of $E$.

We have two remarks. First, we have traditional notions of diameter and line-diameter in any bipartite graph. Note that our notion of diameter in a bipartite graph, which is the longest shortest node-to-node path (and so ignores node-to-block and block-to-block paths), is different from the usual graph-theoretic notion of diameter in a bipartite graph (the same comment can be made as regards line-diameter). When we talk of the diameter or line-diameter of a bipartite graph, we mean with respect to our notion of diameter or line-diameter, respectively; if we need to talk of the traditional notion of graph diameter then we will make this clear. Second, our notion of path length in a hypergraph differs from that in [13] where the length is the number of nodes (resp. hyperedges) in a hyperedge-to-hyperedge (resp. node-to-node) path. There is no real consequence to this difference; essentially, our notion of path length is double that in [13]. However, we shall soon move to an exclusively bipartite graph-theoretic formulation in which our notion of length is the natural one to adopt.

We shall be interested in building sets of paths in some hypergraph $H$ so that the paths might have the same sources or destinations; moreover, we shall require that these paths do not ‘interfere’ with one another (or are ‘independent’ as we mentioned earlier). We say that a set of paths in $H$ is:

• 1.

  pairwise internally-disjoint if any source or destination only appears as a source or destination, and any node or hyperedge that is not a source or destination appears on at most one path

• 2.

  pairwise edge-disjoint if every pair $(v,e)\in V\times E$ is such that $v$ follows or precedes $e$ on some path at most once across all paths from this set.

Given some hypergraph $H=(V,E)$, our intention is to ultimately transform this hypergraph into a DCN by considering both the nodes and the hyperedges as switch-nodes so that the switch-nodes corresponding to the nodes (which we shall later call the level-$1$ switch-nodes, with the switch-nodes corresponding to the hyperedges the level $2$-switch-nodes) also have adjacent server-nodes, which we have yet to define (this intention is best appreciated by working with the corresponding bipartite graph rather than the hypergraph; the upcoming Fig. 3.3 provides a visualization of what we mean). Consequently, we can regard a hypergraph $H$ as modelling a switch-centric DCN $N$ where there are two levels of switch-nodes.

Suppose that we have a set of pairwise internally-disjoint paths from one node of $H$ to another node of $H$. This translates to a set of pairwise internally-disjoint paths in $N$ from a level-$1$ switch-node to another level-$1$ switch-node. We can use these paths for the simultaneous transfer of data from server-nodes adjacent to the source level-$1$ switch-node to server-nodes adjacent to the destination level-$1$ switch-node. In order to facilitate this data transfer we require that level-$1$ switch-nodes are non-blocking whereas the level-$2$ switch-nodes can be blocking; recall that a switch-node is non-blocking when no contention arises when simultaneously sending data through the switch-node on two distinct input links and out on two distinct output links, and blocking otherwise. If our paths in $H$ are only pairwise edge-disjoint then we require that all switch-nodes of $N$ are non-blocking.

The notion of a transversal design is crucial to what follows.

We adopt a graph-theoretic perspective on transversal designs as defined in Definition 1: we think of the $[\Delta,k]$-transversal design $T$ as a bipartite graph where the elements of $\mathcal{X}$ (resp. $\mathcal{U}$) lie on the left-hand side (resp. right-hand side) of the partition, and so are called nodes (resp. blocks) within the bipartite graph, and so that in this bipartite graph there is an edge $(p,Q)$, for $p\in\mathcal{X}$ and $Q\in\mathcal{U}$, if, and only if, in the transversal design the element $p$ is in the block $Q$. Note that the bipartite graph corresponding to the transversal design from Definition 1 is a $(k,\Delta)$-bipartite graph. Henceforth, we adopt our bipartite graph framework and regard both hypergraphs and transversal designs as bipartite graphs (unless we state otherwise).

There is an intimate relationship involving transversal designs, orthogonal arrays and mutually orthogonal latin squares, although there is no need to give definitions here. However, it is well known: that there are $\Delta$ mutually orthogonal latin squares of order $k$ if, and only if, there is a $[\Delta+2,k]$-orthogonal array if, and only if, there is a $[\Delta+2,k]$-transversal design; and that there are at most $k-1$ mutually orthogonal latin squares of order $k$ (see, for example, [14]). Hence, if we have a $[\Delta,k]$-transversal design then $\Delta\leq k+1$. Also, if $k$ is a prime power then a $[\Delta,k]$-transversal design exists whenever $2\leq\Delta\leq k+1$ (again, see [14]). We shall use these facts later on. The study of the existence of $[\Delta,k]$-transversal designs, for various $\Delta$ and $k$, is a long-standing area of research.

We require one final bit of notation. If $T$ is some transversal design, as in Definition 1, and $x$ and $y$ are nodes in distinct groups then we refer to the unique block adjacent to both $x$ and $y$ as the block generated by $x$ and $y$.

The $3$-step construction proceeds as follows.

Note that:

• 1.

  each node of $H$ can be indexed as $a_{p,j}$, where $p\in\{p_{i}:i=1,2,\ldots,n\}$ and $j\in\{1,2,\ldots,k\}$, so that $p$ is the node of $H_{0}$ to which the group $G_{p}$ in which $a_{p,j}$ sits is associated and $j$ is the index of the node $a_{p,j}$ in this group

• 2.

  each block of $H$ can be indexed as $B_{Q,U}$, where $Q\in\{Q_{i}:i=1,2,\ldots,e\}$ and $U\in\{1,2,\ldots,k^{2}\}$, so that $Q$ is the block of $H_{0}$ to which the set of blocks $B_{Q}$ in which $B_{Q,U}$ sits is associated and $U$ is the block of $T$ to which $B_{Q,U}$ corresponds.

In addition, each node of $T$ can be indexed $u_{i,j}$, where $i\in\{1,2,\ldots,\Delta\}$ and $j\in\{1,2,\ldots,k\}$, so that $D_{i}$ is the group of nodes in which $u_{i,j}$ sits and $j$ is the index of $u_{i,j}$ in that group.

We refer to the $(dk,\Delta)$-bipartite graph $H$ (resp. the $(\Delta,dk)$-bipartite graph $H^{\ast}$) constructed above as having been constructed by the $2$-step (resp. $3$-step) method using the $(d,\Delta)$-bipartite graph $H_{0}$ and the $[\Delta,k]$-transversal design $T$. Note that $H$ (resp. $H^{\ast}$) has $nk$ nodes (resp. $ek^{2}$ nodes) and $ek^{2}$ blocks (resp. $nk$ blocks).

Our intention with our constructions is to ultimately design switch-centric DCNs with beneficial properties (as we outlined in Section 2.5). Whilst there are many properties we would like our DCNs to have, it is important that DCNs can integrate a large number of server-nodes so that the server-node-to-server-node distances are short and so that there is redundancy as to which (short) server-node-to-server-node routes we choose to use. In our framework of bipartite graphs, this translates as building bipartite graphs with a large number of nodes and with redundant (short) node-to-node paths. As a first step, the following result was proven in [4] (it is actually derivable from the proofs of our upcoming results) and allows us control over the length of shortest block-to-block paths in $2$-step constructions (and so shortest node-to-node paths in $3$-step constructions).

Of course, if $H^{\ast}$ is the dual bipartite graph of $H$ in Theorem 2 then it has diameter $\lambda$. We reiterate that our notion of diameter and line-diameter differs from that in [4, 13] (where the length of a block-to-block path is the number of nodes on that path; so, in [4, 13] the bound $\lambda\geq 4$ in our Theorem 2 appears as $\lambda\geq 2$).

We can iterate the $3$-step construction (as was done in [13]). Note that if $H_{0}$ is a $(d,\Delta)$-bipartite graph of line-diameter $\lambda\geq 4$, with $n$ nodes and $e$ blocks, then the bipartite graph $H_{1}$ resulting from the $2$-step construction (using $H_{0}$ and some $[\Delta,k]$-transversal design $T$) is a $(dk,\Delta)$-bipartite graph of line-diameter $\lambda$. So, repeating the $2$-step construction but with $H_{1}$ replacing $H_{0}$ (we keep the same $T$, although we do not have to) yields a $(dk^{2},\Delta)$-bipartite graph $H_{2}$ of line-diameter $\lambda$. By iterating this construction, we can clearly obtain a $(dk^{i},\Delta)$-bipartite graph $H_{i}$ of line-diameter $\lambda$. Converting $H_{i}$ into $H_{i}^{\ast}$ results in a bipartite graph with $ek^{2i}$ nodes, with $nk^{i}$ blocks, with diameter $\lambda$, and that is regular of degree $\Delta$ and uniform of rank $dk^{i}$.

New methods of composing bipartite graphs (built according to the $3$-step construction) so as to obtain switch-centric DCNs were also derived in [13]. In [13], $4$ such methods were given: Methods $M_{1}$, $M_{2}$ and $M_{3}$ are different cases of Method $A$, below; and Method $M_{4}$ is Method $B$.

In what follows, let $H$ be a $(\Delta,\delta)$-bipartite graph where $\Delta<\delta$ and where there are $n$ nodes and $e$ blocks.

In [13], switch-centric DCNs constructed using the $3$-step method allied with Methods $A$ and $B$ were favourably compared with the $3$-level Fat-Tree DCN from [3] with regard to the number of server-nodes therein when the diameter and the number of ports of a switch-node are held constant. The reader is referred to [3, 13] for full details as regards the topology of Fat-Tree and to Tables 2–4 in [13] for the complete comparison; however, we include a replicated table here purely for illustrative purposes. In Table 1 (which is Table 2 from [13]): the number of ports of any switch-node is forced to be $64$; the diameters of the DCNs resulting from using the $3$-step method, iteration and composition are forced to be (at most) $6$ (like that of Fat-Tree); and the numbers of server-nodes and switch-nodes in the resulting DCNs are as given (note that the length of a server-node-to-server-node path as defined in [13] is the number of switch-nodes on it, which is one less than our notion of length which is the number of links on the path).

• 1.

  The bipartite graph $H^{\ast}$ is obtained using the $3$-step method starting with a $(8,8)$-bipartite graph $H_{0}$, that has $855$ nodes, $855$ blocks, and diameter and line-diameter $4$ (such a bipartite graph $H_{0}$ exists; see [11]), and a $[8,8]$-transversal design $T$. The DCN $H^{\ast}$ in Table 1 is the DCN obtained by simply regarding every node of the bipartite graph $H^{\ast}$ as a server-node (note that in this DCN we require that every server-node has $8$ NIC ports); the DCN $N_{A}^{1}(H^{\ast})$ (resp. $N_{A}^{2}(H^{\ast})$, $N_{A}^{3}(H^{\ast})$) is obtained by employing Method $A$ with $c=1$ (resp. $c=7$, $c=4$); and the DCN $N_{B}(H^{\ast})$ is obtained by employing Method $B$ with $N_{A}^{1}(H^{\ast})$ (note that the number of switch-nodes entry in Table 2 in [13] is incorrect).

• 2.

  The bipartite graph $\bar{H}$ is obtained using the $3$-step method iterated twice, starting with a $(4,4)$-bipartite graph $\bar{H}_{0}$, that has $80$ nodes, $80$ blocks, and diameter and line-diameter $4$ (such a bipartite graph $\bar{H}_{0}$ exists; see [11]), and a $[4,4]$-transversal design $\bar{T}$ (actually, in [13] this transversal design is not mentioned; it does, however, exist). The DCN $\bar{H}^{\ast}$ in Table 1 is the DCN obtained by simply regarding every node of the bipartite graph $\bar{H}^{\ast}$ as a server-node (note that the number of server-nodes entry in Table 2 in [13] is incorrect, though the correct number is stated in the text); and the DCN $N_{A}^{1}(H^{\ast})$ is obtained by employing Method $A$ with $c=1$ (note that the numbers of server-nodes and of switch-nodes entries in Table 2 in [13] are incorrect).

It is clear from Table 1 (and from [13]) that we can build much bigger server-centric DCNs using the $3$-step method and the subsequent iterations and compositions than Fat-Tree but without increasing the diameter (which is a proxy for latency); of course, we would wish the new DCNs to have other properties that make them attractive within a data centre context. Establishing such properties was essentially the whole point of [13] and we continue with this line of research in what follows.

Before we move to our main results, let us comment on using the $2$-step method as opposed to the $3$-step method when building our switch-centric DCNs (the same comment was made in [13]). Note that when one uses the (iterated) $2$-step method, whilst the rank of the resulting bipartite graph stays the same, the degree grows. Were we to attach server-nodes to the switch-nodes that replace the nodes of the $2$-step bipartite graph $H$, rather than the $3$-step bipartite graph $H^{\ast}$, the number of ports of the level-$2$ switch-nodes (which would be $\Delta$) would be much less than the number of ports of the level-$1$ switch-nodes. Hence, it makes more sense to proceed as we have done above.

In order to detail the difficulties in [13], we adopt the terminology of [13]. There are slight problems with the proof of Theorem 2 in [13] (although they are easily surmountable). For example, in Subcases (1.2) and (2.2), $\{r_{i},s_{i},t_{i}\}\subseteq G_{i}^{E}$ and consequently we cannot generate the blocks $R_{j}$ and $S_{j}$. Also, in Subcase (2.1), the situation where $q\in P\cap Q\setminus\{p\}$ is not considered; it could be that $r_{j}=s_{j}$, for some $j\neq i$.

An attempt was also made in [13] to extend Theorem 2 of [13]: see Theorem 3 of [13]. Assumptions concerning the connectivity of $H_{0}$ are made and the existence of additional paths in $H^{\ast}$ to those constructed in the proof of Theorem 2 are claimed in the situation when the two blocks $B_{Q,U}$ and $B_{Q^{\prime},U^{\prime}}$ are such that $Q\neq Q^{\prime}$ (recall our method of indexing in Section 3.1 which we adopt here). However, there are serious flaws in the proof of Theorem 3 of [13], so much so that the theorem is untrue. In short, Theorem 3 of [13] claims that if there are $\omega$ pairwise internally-disjoint paths in $H_{0}$ from $Q$ to $Q^{\prime}$ then there are $\min\{\Delta\omega,k\omega\}$ pairwise internally-disjoint paths in $H$ from $B_{Q,U}$ to $B_{Q^{\prime},U^{\prime}}$. This does not make sense: the maximum number of pairwise internally-disjoint paths in $H$ from $B_{Q,U}$ to $B_{Q^{\prime},U^{\prime}}$ is $\Delta$ (as the bipartite graph $H$ has rank $\Delta$) and so we must have that $\min\{\Delta\omega,k\omega\}\leq\Delta$. For instance, in Example 1 of [13], the bipartite graph $H_{0}$ is the cycle of length $10$ ($H_{0}$ is derived from the cycle of length $5$ using its natural representation as a hypergraph; see Section 2.2), so that $d=\Delta=2$, $n=e=5$, and there $2$ internally-disjoint paths from any block of $H_{0}$ to any other block of $H_{0}$. A $[2,3]$-transversal design $T$ is used and the bipartite graph $H^{\ast}$ built by the $3$-step method has rank $6$ and degree $2$. However, if Theorem 3 of [13] were true then there would be $4$ pairwise disjoint paths from $B_{Q,U}$ to $B_{Q^{\prime},U^{\prime}}$ in $H^{\ast}$ which clearly cannot be the case.

We now resurrect (some of) the proofs of the main results from [13] and extend the results claimed in that paper. The following lemma proves most useful.

We use this lemma throughout, both explicitly and implicitly.

Our main result in the one-to-one context is concerned with building as many pairwise internally-disjoint paths as we can from any block to any other block in the bipartite graph built using the $2$-step method (or, equivalently, from any node to any other node in the bipartite graph built using the $3$-step method). We explain the impact of the existence of these paths on the path diversity of subsequently built DCNs presently. One added and significant complication in the proof of the following result comes about when the transversal design $T$ is a $[k+1,k]$-transversal design (so, there is the potential for $\Delta=k+1>k$ paths).