MétaCan
Menu
← all works

HyperFlow: a distributed control plane for OpenFlow

2010· article· en· 902 citations· W1829787244 on OpenAlex

Why is this work in the frame?

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

Canadian affiliationAn author listed a Canadian institution. This is the only route the usual frame has.

Full frame distilled prediction

Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

Candidate categories
none
Consensus categories
none
Domain
Candidate signal: noneConsensus signal: none
Study design
Candidate signal: Not applicableConsensus signal: none
Genre
Candidate signal: MethodsConsensus signal: none
Teacher disagreement score
0.900
Threshold uncertainty score
0.330
Validation status
machine_predicted_unvalidated · codex-gemma-dda1882f352a

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0000.000
Meta-epidemiology (narrow)0.0000.000
Meta-epidemiology (broad)0.0000.000
Bibliometrics0.0000.000
Science and technology studies0.0000.000
Scholarly communication0.0000.000
Open science0.0010.000
Research integrity0.0000.000
Insufficient payload (model declined to judge)0.0000.000

Machine scores (provisional)

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Opus teacher head0.008
GPT teacher head0.221
Teacher spread
0.213 · how far apart the two teachers sit on this one work
Validation status
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it

Abstract

OpenFlow assumes a logically centralized controller, which ideally can be physically distributed. However, current deployments rely on a single controller which has major drawbacks including lack of scalability. We present HyperFlow, a distributed event-based control plane for OpenFlow. HyperFlow is logically centralized but physically distributed: it provides scalability while keeping the benefits of network control centralization. By passively synchronizing network-wide views of OpenFlow controllers, HyperFlow localizes decision making to individual controllers, thus minimizing the control plane response time to data plane requests. HyperFlow is resilient to network partitioning and component failures. It also enables interconnecting independently managed OpenFlow networks, an essential feature missing in current OpenFlow deployments. We have implemented HyperFlow as an application for NOX. Our implementation requires minimal changes to NOX, and allows reuse of existing NOX applications with minor modifications. Our preliminary evaluation shows that, assuming sufficient control bandwidth, to bound the window of inconsistency among controllers by a factor of the delay between the farthest controllers, the network changes must occur at a rate lower than 1000 events per second across the network. 1.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

The record

Venue
Topic
Software-Defined Networks and 5G
Field
Computer Science
Canadian institutions
University of Toronto
Funders
not available
Keywords
OpenFlowScalabilityComputer scienceSynchronizingForwarding planeController (irrigation)Distributed computingComputer networkBandwidth (computing)Software-defined networkingTransmission (telecommunications)Telecommunications
Has abstract in OpenAlex
yes