| 105 | | Centralized routing is hardly a novel concept and we explore several |
| 106 | | existing protocols in this section that embrace a centralized design. |
| 107 | | The critical distinction is that these earlier solutions were designed |
| 108 | | for wired networks characterized by low churn, high bandwidth, and |
| 109 | | significant memory. These assumptions do not hold in sensornets which |
| 110 | | exhibit high-churn, low-bandwidth, and high resource-constraints. |
| 111 | | |
| 112 | | Ethane~\cite{ethane} is the work that is architecturally most similar |
| 113 | | to ours. Designed for large enterprise networks, Ethane divides the |
| 114 | | network into four tiers: controllers, switches, hosts, and users. |
| 115 | | Network administrators specify high-level access policies. Each |
| 116 | | switch maintains a flow table against which it can classify incoming |
| 117 | | packets based on header fields. If no applicable entry exists, the |
| 118 | | packet is forwarded to the controller where the controller consults |
| 119 | | its policy specification, and installs flow entries along the path. |
| 120 | | |
| 121 | | We adopt several aspects of Ethane's design including ``default |
| 122 | | routes'' to a controller and maintaining global network topology |
| 123 | | centrally. Although architecturally similary, low-power wireless |
| 124 | | links expose many assumptions underlying Ethane's operation, which |
| 125 | | must be addressed in our context. Among the (invalid) assumptions are |
| 126 | | (i) a reliable path exists to the central controller; (ii) a |
| 127 | | consistent global view of the topology is available; and (iii) links |
| 128 | | are generally stable. None of these assumptions hold in a wireless |
| 129 | | sensornet. |
| 130 | | |
| 131 | | Other centralized Internet routing designs exist, which we review |
| 132 | | briefly for completeness. The Routing Control Platform architecture |
| 133 | | makes the case for separating the control aspect of routing from |
| 134 | | routers~\cite{feamster-separating, caesar-rcp}. Greenberg {\it et |
| 135 | | al.} present 4D~\cite{4d,tesseract}, a general framework for |
| 136 | | separating routing from routers. The framework consists of four |
| 137 | | components: a decision plane, a dissemination plane, a discovery |
| 138 | | plane, and a data plane. |
| | 105 | One recent track in networking has pursued the design of general network management tools~\cite{feamster-separating, caesar-rcp, 4D}, predominantly centralized, which strive to avoid specialization for a specific environment (e.g. datacenters, enterprise networks, or WANs). NOX~\cite{nox}, the successor to Ethane~\cite{ethane}, is the most recent instantiation within this track. In the NOX architecture, a centralized controller maintains a global view of the network, and dictates routing decisions to programmable switches that provide remote access to their flow tables. |
| | 106 | |
| | 107 | Although not our original inspiration, {\lowthane} could be viewed as a direct port of NOX to L2Ns. However, one of our main contributions is {\emph{how}} to do this port. Setting up secure channels between switches and the controller, maintaining a global view of the topology, and providing reliable delivery are trivial tasks in NOX; the same is not true in high-churn, low-bandwidth, and resource-constrained sensornets. In other words, we don't claim that NOX deployments (e.g. datacenters~\cite{noxDC}) are trivial; rather that those challenges are orthogonal to ours. |
| | 108 | |
| | 109 | %Centralized routing is hardly a novel concept and we explore several |
| | 110 | %existing protocols in this section that embrace a centralized design. |
| | 111 | %The critical distinction is that these earlier solutions were designed |
| | 112 | %for wired networks characterized by low churn, high bandwidth, and |
| | 113 | %significant memory. These assumptions do not hold in sensornets which |
| | 114 | %exhibit high-churn, low-bandwidth, and high resource-constraints. |
| | 115 | % |
| | 116 | %Ethane~\cite{ethane} is the work that is architecturally most similar |
| | 117 | %to ours. Designed for large enterprise networks, Ethane divides the |
| | 118 | %network into four tiers: controllers, switches, hosts, and users. |
| | 119 | %Network administrators specify high-level access policies. Each |
| | 120 | %switch maintains a flow table against which it can classify incoming |
| | 121 | %packets based on header fields. If no applicable entry exists, the |
| | 122 | %packet is forwarded to the controller where the controller consults |
| | 123 | %its policy specification, and installs flow entries along the path. |
| | 124 | % |
| | 125 | %We adopt several aspects of Ethane's design including ``default |
| | 126 | %routes'' to a controller and maintaining global network topology |
| | 127 | %centrally. Although architecturally similary, low-power wireless |
| | 128 | %links expose many assumptions underlying Ethane's operation, which |
| | 129 | %must be addressed in our context. Among the (invalid) assumptions are |
| | 130 | %(i) a reliable path exists to the central controller; (ii) a |
| | 131 | %consistent global view of the topology is available; and (iii) links |
| | 132 | %are generally stable. None of these assumptions hold in a wireless |
| | 133 | %sensornet. |
| | 134 | % |
| | 135 | %Other centralized Internet routing designs exist, which we review |
| | 136 | %briefly for completeness. The Routing Control Platform architecture |
| | 137 | %makes the case for separating the control aspect of routing from |
| | 138 | %routers~\cite{feamster-separating, caesar-rcp}. Greenberg {\it et |
| | 139 | % al.} present 4D~\cite{4d,tesseract}, a general framework for |
| | 140 | %separating routing from routers. The framework consists of four |
| | 141 | %components: a decision plane, a dissemination plane, a discovery |
| | 142 | %plane, and a data plane. |
