- Jan 25, 2017
-
-
Nikolai Reed authored
-
Nikolai Reed authored
-
Nikolai Reed authored
-
- Jan 24, 2017
-
-
Nikolai Reed authored
-
Nikolai Reed authored
-
Nikolai Reed authored
-
- Sep 08, 2016
-
-
Nikolai Reed authored
-
- Sep 05, 2016
-
-
vikin91 authored
- Jul 29, 2016
-
- Jul 28, 2016
-
-
vikin91 authored
-
vikin91 authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
- Jul 20, 2016
-
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
- Jul 19, 2016
-
-
Maximilian Kiesner authored
-
- Jul 15, 2016
-
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
- Jul 14, 2016
-
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
- Jul 07, 2016
-
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
Maximilian Kiesner authored
-
vikin91 authored
-
- Jun 30, 2016
-
-
Piotr authored
-
Maximilian Kiesner authored
Suppose there is an SDN switch(S) and a server which hosts an SDN controller(C). For every flow which is routed via S, an SdnFlowRule has to be modeled. S now has to interact with C. Therefore we use SdnControlFlow instances. We need an SdnControlFlow from S to C (called forwardFlow in the transformation) and an SdnControlFlow from C to S (called backwardFlow). We assume that for every flow that is routed via S the corresponding SdnControlFlows can take the same route (i.e. the same Direction instances, except for their flow property). To simplify modeling it is no longer required to model every SdnControlFlow and Direction instance. We can now model the SdnControlFlows and Directions for one parent flow and automatically generate them for all other parent flows (in the context of S and C). This is done in DNI3/etl/DNI-sdn-routing-DNI.etl, which is executed even before the routing transformation
-
- Jun 23, 2016
- Jun 14, 2016