[LISPmob-devel] Proposing a new interface management architecture
mportoles at cttc.cat
Mon Feb 20 18:42:08 CET 2012
Regarding the discussion on APIs, I think we would benefit a lot from
working a bit the use-cases to be supported. I share the idea with Lori
that I would firstly focus on the analysis on how to manipulate
interfaces and routes but solving the use-cases may help us identifying
functionality to be included in the "lower API" so that the "upper API"
is not limited in the future.
>>> IMHO the API should support three main set of functionalities:
>>> 1) Basic LISP
>>> 2) Connection Management (inbound/outbound flow allocation to a given
>>> 3) Privacy extensions (EID or RLOC privacy)
>>> At this point I can´t imagine a functionality not covered by the above
>>> list. But please jump in if you have any idea.
Following the idea of the use cases I agree that these three cases seem
to cover most common scenarios. Correctly if I'm wroing but I understand
them as 1) how to make Lispmob run on current systems, 2) how to add and
exploit multihoming support and 3) adding enhanced functionality
>>> 1) Basic LISP
>>> The information that LISPmob requires for basic functionality is the
>>> one contained in a Map-Register (EIDs -> set of RLOCs +
>>> Priority/Weight). Hence the API could have a function that conveys the
>>> same information than a Map-Register. After a handover a new
>>> "Map-Register" is sent to lispd that will react accordingly.
>>> Given that multiple EIDs can be defined in a single Map-Register a
>>> function stating which is the prefered EID should be also included.
>> In case I was right, and this is the "upper" application facing API, do
>> you mean that we can provide a flow manager (or even individual
>> applications) a list of EIDs that we have, and allow them to set usage t
> This is just to be general enough, but ideally only one EID should be
> selected in "basic" mode,
Just to make sure, when talking about multiple EIDs are you referring to
source EIDs right? That is, it would be the responsibility of the host's
connection manager to pick one EID to use.
Thinking out loud, in the "basic lisp" scenario and assuming there is a
Connection Manager running on the system (e.g., NetworkManager) I
believe that the "lower API" would have to be able to: 1) set a default
routing entry without conflicting with existing connection managers
(this is the main issue to solve), 2) discover handoffs and announce
them to lispd and 3) Manage policy routing rules. All these functions
are included now in lispd code. The "upper API" would announce which
RLOC is being used so that potential flow managers would decide whether
to block or allow applications to run.
>> The idea is to have a new interface management architecture, as
>> illustrated in the attached image: separate the code maintaining
>> information about available interfaces, the RLOCs configured on them,
>> routes, etc. from the code listening to events and actually modifying
>> routing tables and addresses. Unless we work directly over NETLINK, the
>> latter functionality is connection manager dependent.
> I think the current approach is to use D-BUS since it is available on
> the distro. In my opinion, the trade-off is that with Dbus,
> we have an already existing connection manager which can be leveraged.
> But I think Netlink is more generic.
> Marc, do you know if the connection manager on Ubuntu
> (Network-manager) supports both Netlink too?
Browsing a bit the code of NetworkManager it seems that they also use
Netlink sockets to monitor routing table changes. I hope this simplifies
a bit the options to consider. I guess that any interface with Netlink
would be a quite generic approach. Then, more specialized pieces of code
can be added that take advantage of the specific software that each
system runs (e.g., NetworkManager, ConnMan). Also, NetworkManager uses
udev to manage devices.
More information about the devel