[LISPmob-devel] Proposing a new interface management architecture

[Marc Portoles]

Hi,

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
>>> RLOC)
>>> 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
>> policies?
>
> 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.

Regards,

Marc