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
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
