Open Source Projects Europe

• assigned_to: edugrasa

Hello,

since Resource Allocator is (according to ResourceAllocator-RINA-RFC-2010-002.pdf) responsible for management of (N-1)-flows, I decided to include an additional module to store details about currently allocated flows for convenience purposes. I don't believe PDU Forwarding Table is by itself sufficient for this since it only contains a set of "dumb" mappings of destination addresses and QoS IDs to sets of (N-1)-ports.

It's meant to serve as something you can glance at when you need detailed information about what flows are currently allocated through which IPC processes.

I suppose the current placement of PDU Forwarding Table might be a bit confusing -- we could move it closer to RMT in the IPC process topology since it's mostly used for relaying purposes by RMT.

Regards,
Tomas

Ok, got you, so this is an N-1 Flow table to keep track of the N-1 flows that are currently allocated and used by the IPC Process, right? Maybe changing the name to "N-1 Flow Table" would make it easier to understand (if it is easy to do, otherwise nevermind).

Note that this functionality is conceptually part of the IPC Resource Manager (IRM) entity that is part of each application instance, since all applications need to manage N-1 flows from underlying DIFs (so you could have it there if you want to make the implementation of this functionality available to applications as well). In the IPC Process the IRM functions are "assumed" by the Resource Allocator, so now I can see why the Table is there).

On the PDU Fowarding Table it's ok.. it is populated and updated by the Resource Allocator and queried by the RMT, so both are "users" of it.

Unfortunately the plus/minus sign isn't really compatible with identifier naming in both OMNeT++ topology definitions and C++, otherwise I would have used the original notation. We can still refer to (N-1)-flows as 'nMinusOneFlows', 'lowerFlows', 'supportFlows' or whatever else we can come up with.

• status: open --> closed