GLOBECOM 2017 - 2017 IEEE Global Communications Conference 2017
DOI: 10.1109/glocom.2017.8254753
|View full text |Cite
|
Sign up to set email alerts
|

Dynamic Flow Migration for Delay Constrained Traffic in Software-Defined Networks

Abstract: Abstract-Various industrial control applications have stringent end-to-end latency requirements in the order of a few milliseconds. Software-defined networking (SDN) is a promising solution in order to meet these stringent requirements under varying traffic patterns, as it enables the flexible management of flows across the network. Thus, SDN allows to ensure that traffic flows use congestion-free paths, reducing the delay to forwarding and processing delays at the SDN nodes. However, accommodating new flows a… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1

Citation Types

0
2
0

Year Published

2018
2018
2022
2022

Publication Types

Select...
5
1

Relationship

0
6

Authors

Journals

citations
Cited by 7 publications
(2 citation statements)
references
References 17 publications
0
2
0
Order By: Relevance
“…After the traffic is rerouted to use the new paths, the N1-N2 link is disabled and the testbed reaches the final configuration state C2. With our testbed, the calculation of the flow installation order is straightforward and can easily be hard-coded in the experimental scripts, but with larger scenarios, such flow migration is required to be computed considering the whole topology as input [53]. It is worth noting that during the initial configuration state C1, flow F1 is routed over two mmWave link hops and F2 over one hop, while in C2, flow F1 experiences two wireless hops and F2 experiences three hops.…”
Section: Scenario I: Reconfiguration Under Low Traffic Volumementioning
confidence: 99%
“…After the traffic is rerouted to use the new paths, the N1-N2 link is disabled and the testbed reaches the final configuration state C2. With our testbed, the calculation of the flow installation order is straightforward and can easily be hard-coded in the experimental scripts, but with larger scenarios, such flow migration is required to be computed considering the whole topology as input [53]. It is worth noting that during the initial configuration state C1, flow F1 is routed over two mmWave link hops and F2 over one hop, while in C2, flow F1 experiences two wireless hops and F2 experiences three hops.…”
Section: Scenario I: Reconfiguration Under Low Traffic Volumementioning
confidence: 99%
“…Moreover, all these requirements must be applied to the entire BH, which significantly complicates the reconfiguration. Existing work is mostly focused on effective flow migration techniques to avoid network disruption [10], yet an orchestrated reconfiguration of a mmWave BH is not properly addressed.…”
Section: Introductionmentioning
confidence: 99%