Cartesian Product Router

• Cartesian Product Router is a decentralized routing protocol that applies canonical addition and lookup rules to construct local routing in Cartesian product graphs.
• It leverages consistent rotation maps from factor graphs, ensuring constant-time (O(1)) per-hop forwarding and minimal local state.
• The approach reduces computational complexity and storage needs, making it ideal for implementing efficient routing in distributed network systems.

A Cartesian Product Router is a constructive protocol for local routing in the Cartesian product of regular graphs by leveraging consistent rotation maps on the factor graphs. The approach directly specifies, via canonical addition and lookup rules, how to realize a consistent rotation map on the product graph from given factor rotation maps; the result is a decentralized routing mechanism with constant-time forwarding and strictly local state, guaranteeing correctness and minimizing per-hop computational complexity (Alexander, 2021).

1. Formalism: Regular Graphs and Consistent Rotation Maps

Let $G=(V,E)$ be a $d$-regular undirected graph, meaning every $v\in V$ has $\deg_G(v)=d$, and $H=(V_H, E_H)$ be $d_H$-regular. Assign to each vertex a canonical port ordering, $[d] = \{1,2,\ldots,d\}$. A rotation map of $G$ is a function $R_G : V \times [d] \to V \times [d]$, where $R_G(v,i) = (w,j)$ if the $i$-th port at $v$ leads to $w$, and, at $w$, the same edge is its $j$-th port. $R_G$ is an involution: $R_G(R_G(v,i)) = (v,i)$.

A rotation map $R_G$ is consistent if for every $w\in V$, the incoming port-labels at $w$ permute $[d]$; equivalently, in the $|V|\times d$ matrix whose $(v,i)$–entry is the vertex-index of $R_G(v,i)$, each column is a permutation of $V$ and each port index $j\in[d]$ appears exactly once per column. This constructs canonical local edge-labelings that yield well-behaved local forwarding.

2. Structure of the Cartesian Product and Port Indexation

Given $G$ $d_G$-regular and $H$ $d_H$-regular, their Cartesian product is $G \Box H = (V_G \times V_H, E_{\Box})$, where edge $((u,v),(u',v'))\in E_{\Box}$ if either (i) $u=u'$, $(v,v')\in E_H$, or (ii) $v=v'$, $(u,u')\in E_G$. Every node $(u,v)$ has degree $d_G+d_H$. Port indices for $(u,v)$ are ordered as $1,\ldots,d_G$ (corresponding to $G$-edges, i.e., moving in the $G$-factor) and $d_G+1,\ldots,d_G+d_H$ (corresponding to $H$-edges, i.e., moving in the $H$-factor).

3. Construction of the Product Rotation Map

Given consistent rotation maps $R_G$ and $R_H$ for the factors, the rotation map for the product is defined as

$$R_{G\Box H}: (V_G \times V_H) \times [d_G+d_H] \to (V_G \times V_H) \times [d_G+d_H]$$

using addition and lookup rules:

• For $1\leq i \leq d_G$: let $(u',i') = R_G(u,i)$. Then $R_{G\Box H}((u,v),i) = ((u',v), i')$.
• For $d_G+1 \leq i \leq d_G+d_H$: set $k = i-d_G$, compute $(v',k') = R_H(v,k)$. Then $R_{G\Box H}((u,v),i) = ((u,v'), d_G + k')$.

Each such mapping is an involution and preserves consistency because the factor maps are consistent; incoming $G$-ports (resp. $H$-ports) at the product nodes always exhaust their proper local index sets.

4. Routing Algorithm: Local Table Lookup

At each node $(u,v)\in V_G\times V_H$, a routing table of length $d_G+d_H$ is stored, where entry $i$ contains the tuple $$(\text{neighbor},\text{out-port}) = R_{G\Box H}((u,v),i)$$. Upon arrival at $(u,v)$, given destination $(u_*,v_*)$ and input port $i_\text{in}$ (or a special marker for initial injection), the router selects an exit port $i_\text{out}\in [d_G+d_H]$ according to some routing policy, such as shortest-path in the product metric or greedy per coordinate. The packet is dispatched via $i_\text{out}$, with arrival information updated to the appropriate in-port label, all using a single table lookup.

Pseudocode for one forwarding step:

Input: current node (u,v), chosen exit‐port i_out ∈ [1..d_G+d_H] Table_R = table of size (d_G+d_H) at node (u,v) (neighbor, in_port) = Table_R[i_out] Send packet to neighbor via local port i_out; set packet.arrival_port = in_port

This enables $O(1)$ per-hop computation. Table filling is $O(|V_G||V_H|(d_G+d_H))$, and local memory per node is $O(d_G+d_H)$. Alternatively, if storage is at a premium, the router may compute $R_{G\Box H}((u,v),i)$ on-the-fly by referencing the factor graph tables at each step, with minor arithmetic overhead.

5. Explicit Example: $C_4 \Box K_3$

Consider $G=C_4$, the 4-cycle ($V_G=\{1,2,3,4\}$, $d_G=2$) and $H=K_3$, the triangle ($V_H=\{a,b,c\}$, $d_H=2$), with canonical port assignments.

Rotation maps:

• $R_G(1,1)=(2,2)$, $R_G(1,2)=(4,1)$, and similar for all $i\in\{1,2,3,4\}$
• $R_H(a,1)=(b,2)$, $R_H(a,2)=(c,1)$, and so on for all $x\in\{a,b,c\}$

The product $C_4\Box K_3$ has 12 vertices $(i,x)$. For $(1,a)$, port $1$ (G-edge): $R_G(1,1)=(2,2)\implies R_{□}((1,a),1)=((2,a),2)$. For port $3$ ($k=1$): $R_H(a,1)=(b,2)\implies R_{□}((1,a),3)=((1,b),4)$. Completing all $12\times 4$ entries defines the full router table.

A packet routed greedily from $(1,a)$ to $(4,c)$ via “move in $G$ until $i=4$, then adjust in $H$” might traverse $$(1,a)\xrightarrow{1}(2,a)\xrightarrow{1}(3,a)\xrightarrow{1}(4,a)\xrightarrow{3}(4,c)$$, using only local table lookups.

6. Computational Complexity and Storage Considerations

• Precomputation: $O(|V_G||V_H|(d_G+d_H))$ for all table entries.
• Per-node memory: $O(d_G+d_H)$ (each stores $(\text{neighbor},\text{port})$ per local port).
• Overall memory: $O(|V_G||V_H|(d_G+d_H))$.
• Per-hop route selection: $O(1)$ lookup.
• Trade-off: storing the complete table yields fastest forwarding at the cost of linear space; dynamically computing via the smaller factor tables requires minor arithmetic but less memory.

7. Summary and Significance

The Cartesian Product Router synthesizes efficient, local, and scalable routing protocols for product networks by composition of consistent rotation maps on factor graphs. The methodology is purely combinatorial and exploits the involutive, label-preserving structure of rotation maps. Direct applications arise in communication networks, parallel processor topologies, and any distributed system naturally modeled by graph products. The protocol guarantees correctness and minimal computational overhead for routing decisions on the product space, provided the factor rotations are given and consistent (Alexander, 2021).