[OOR-Users] [LISPmob-users] Modifying LISPMob Code

[Albert López]

Hi Musab,

First I would like to let you know that we are now OpenOverlayRouter 
<http://www.openoverlayrouter.org/>. If possible use the new OOR mailing 
lists to contact us from now on :)

I will try to give you some answers inline:

On 01/03/16 18:40, MUSAB MUHAMMAD wrote:
> Hi all,
>
> I want to introduce a new network entity, Location Server (LS) for 
> some reason, and have MNs and PITRs interact with it as follows:
>
>   * When an MN detects its interface signal dropping (which is going
>     to be determined by an external program), /MN should issue
>     Map-Reply(LS) to PITR, and Map-Reply(NULL) to LS/.
>   * When an MN's interface comes back up after binding to a new
>     address RLOC, and the MN (eventually) issues Map-Reply(RLOC) to
>     PITR, /MN should also issue Map-Reply(RLOC) to LS/.
>
Are you trying to modify the SMR process to also send a Map Reply to the 
LS with the specified RLOCs of the previous point, or you are sending 
directly map replys?

> As we know, a Solicit-Map-Request (SMR) is sent to PITR at interface 
> up, and the PITR sends a Map-Request to the MN, which then sends a 
> Map-Reply with its new RLOC. tr_recv_map_request() in 
> control/lisp_xtr.c appears to handle the incoming Map-Request and 
> respond with a Map-Reply, so I intend to modify this function to deal 
> with both interaction, and supply it through the lisp_xtr_r structure 
> with a flag to distinguish the two behaviours, and the LS address.  
> The flag will be set if the signal drop has been detected, and cleared 
> if the interface has come back up.  There are two modifications:
>
>   * If the flag is set, Map-Reply(LS) will be sent to PITR instead of
>     Map-Reply(RLOC).
>   * An additional Map-Reply(flag ? NULL : RLOC) will be sent to LS.
>
The SMR process not only affects to the PiTR but also all the entries of 
the map cache.
> For the first change, can someone explain how the RLOC currently gets 
> set in the new message?  Is it uc->la, for example?  Or do I need to 
> build a new mapping_t?
uc is just used to indicate the IPs and the udp ports to be used to send 
the packet. You will probably have to generate a mapping with the new 
RLOCs you want to use
>
> For the second change, I don't strictly have to use a Map-Reply, as my 
> code will be talking to my LS, but it would be nice to re-use the 
> message type.  What could I do to express some sort of 
> Map-Reply(NULL)?  Use lisp_msg_put_neg_mapping, perhaps?  Or just an 
> all-zero IP address?
Yes, using a negative map reply (locator_count = 0) will be useful. 
Other possibilities could be to use priority 255 in order to indicate to 
not use the locators. When you create the mapping you also add a locator 
for the LS and then you change priority to 255 of the locators you don't 
want to be used.
>
>
> It looks like send_all_smr_and_reg() sends SMR, so that will result in 
> a later invocation of tr_recv_map_request().  It is only invoked from 
> send_all_smr_cb(), which appears to be invoked by a timer.  Is that 
> timer set as a result of a new binding, i.e., so that SMR will be sent 
> a short moment after the new binding is established?  IOW, does the 
> invocation of send_all_smr_cb() imply that the lisp_xtr object has 
> learned of the new binding?  If so, I intend to clear the flag inside 
> send_all_smr_cb(), so that the subsequent (indirect) invocation of 
> tr_recv_map_request() will behave normally to PITR (as well as send an 
> additional message to LS).  I will also add a non-static function to 
> set the flag, and then call send_all_smr_and_reg().  I will later 
> arrange to call this new function when the signal drop is detected.
We have a structure for each interface (iface_locators) which contain 
the changes produced in the interface. When we receive a netlink message 
we update this structure and we program the SMR timer. If we receive a 
new netlink message before the timer expires, we reprogram the timer 
again. When timer expires we call send_all_smr_cb where we check the 
iface_locators structures to decide if we have to do a SMR or if we had 
a flapping situation and we don't need to initiate the SMR.

I hope with this information you can proceed with your development.

Best regards

Albert
>
> Regards,
> Musab Isah
> Research Student,
> School of Computing and Communications,
> D29, InfoLab21
> Lancaster University


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20160303/9f419a1c/attachment.html>