PowerDEVS simulation implementation: Routing for multi-path flows

los datos de un felix hacia un swrod puede tomar 2 posibles caminos (uno por cada switch). Ademas, los 2 links que salen del felix en la realidad son bonded-links (la aplicación lo ve como uno solo).

Implementation

Structural changes (routing model in hosts)

In order to support Bonded Links (2+ physical links which are seen as 1 logical link) we changed the implementation of the Router atomic model.
The Router atomic model is in charge of forwarding incoming packets to the corresponding port (see next section). This can be used inside the host models (Felix servers) to decide which of the outports to use.

GeneratorApplications generate a Flow of packets, but the same flow can take different routes across the network. i.e: each for can be associated with more than one path.

Routing model implementation (routing tables, flow definitions)

The Router atomic model is in charge of forwarding incoming packets to the corresponding port.

Originally, the Generator atomic model was implemeted so that all packets were created with its route (a flow was associated with a single path), so the Router model only read the route of the packet to decide which outport to use.
Now, the implementation was changed so that:

• Flows can be created independently of routes.
• Routes can be created independently of flows.
• Flows and Routes are registered in the FlowDefinitions.cpp static class.
  • Flows are registered to specify its source nodes (where the packets are going to be generated. A single flow could be generated in more that one source).
  • Router are registered to fill the routing tables (implemented in GlobalFlowBasedRoutingTable.h)
• GlobalFlowBasedRoutingTable implementes a global flow-based routing table. Entries in the table are of the form: <RouterName, FlowID, outgoingPort>. Helper methods were added to facilitate registering complete Routes for a Flow (see below).
  • Global: because it contains the routing tables for all devices.
  • Flow-based: because the routing decision is based ONLY on the flowID. This can be extended in the future (to allow incomming port, src, dst, TCP ports, etc, etc).
• Packets are generated without any specific route, and they only have their FlowId (for routing purposes. Packet do contain other info for other purposes)
• The router model uses the FlowId (from the incomming packet) and its name to query the GlobalFlowBasedRoutingTable for the outgoing port that should be used.

1. It resembles closer to the reality: 1) Routers use routing tables. 2) packets dont contain their full route 3) the applications that generates packets are not aware of network routes. Bad: routing tables are usually based on several fields (rules, etc)
2. Allows for more flexibility: 1) a single flow of packets can traverse the network through different paths 2) same flow description can be used by multiple generators 3) routing table entries can be individually specified and/or specified for complete routes

Below there is an example of specification of a flow with 2 different routes:

// create flow
auto flowFlow0_1 = std::make_shared<Flow>("Flow0_1", 0 /*startTime*/, 0 /*typeOfService*/, flowFlow0_1PeriodDistribution, flowFlow0_1PacketSizeDistribution);
// routes for flow Flow0_1
auto flowFlow0_1_route0 = std::make_shared<Route>( std::deque<Route::Node>{
{0, "lar_felix_0.Routing"},
{2, "lar_switch_01.Routing"},
{0, "lar_swrod_0.Routing"}
});
auto flowFlow0_1_route1 = std::make_shared<Route>( std::deque<Route::Node>{
{1, "lar_felix_0.Routing"},
{2, "lar_switch_02.Routing"},
{1, "lar_swrod_0.Routing"}
});
// register flow Flow0_1 with its routes
FlowDefinitions::registerFlowSourceNode(flowFlow0_1, "lar_felix_0.GeneratorApplication");
FlowDefinitions::registerFlowRoute(flowFlow0_1, flowFlow0_1_route0);
FlowDefinitions::registerFlowRoute(flowFlow0_1, flowFlow0_1_route1);

Generator support (mutiple paths per flow)

The TopologyGenerator was updated to support:

1. Multiple in/out ports in hosts
2. Allow multiple paths per flow
3. Generate the PDM and C++ code to support the features described below.

paths=[]

# path using switch 1
path = Path.new felix, @sw_rod_servers[0]
path.add_link @topology.get_element_by_id "link_felix1_switch1"
path.add_link @topology.get_element_by_id "link_switch1_swrod1"
paths.push path1

# path using switch 2
path = Path.new felix, @sw_rod_servers[index]
path.add_link @topology.get_element_by_id "link_felix1_switch2" # felix{i} -> switch_2
path.add_link @topology.get_element_by_id "link_switch2_swrod1" # switch_2 --> lar_swrod{i}
paths.push path2

@topology.add_flow "Flow1_1", FELIX_FLOW_PRIORITY, paths, FELIX_GENERATION_RATE, FELIX_GENERATION_SIZE

Simulation Results

Configuration: 2 Felix, 2 SWRod
Topology:

Felix Generation rates: 1Gbps

• FELIX_GENERATION_PERIOD = ExponentialDistribution.new 1.0/(1*M) # distribution period in seconds
• FELIX_GENERATION_SIZE = ConstantDistribution.new 1.0*K #distribution size in bits

both RODs receive ~125MB/s = 1Gbps (the plot shows 1255 B/s because the sampling is every 0.01s)

Both links of the hosts are equally used

-- MatiasAlejandroBonaventura - 2016-11-17