Nightly

DNS - IP address - Produces IOR
Since there is no MG, hence at time of birth there is no need to produce IOR.
MH produces original IOR and ukey or Hash and distributes to all neighbour MHs to make an entry in their tables.
On movement Birth MH might not be connected to the old set of MH and might be connected to the new set of MH.
Birth MH notifies new set of MH not the old set of MH.
How old set of MH would be notified about the IOR getting dirty?
On movement of MH, devices which are immediate neighbour would get notified about device demise.
Request can be received from MH or FC.
In CORBA, a request can only be launched if a client has IOR.
1. An IOR can be distributed to the connected consumes(FC or MH).
2. A request of search can be issued by consumer (FH or MH) to connected MH by giving some search attributes, so that the receiving MH can do:
2a. Forwards the request attributes to it's connected MH if can't be answered.
2b. Replies back to the client with the modified or swapped IOR.

In approach 1, as IOR gets dirty it becomes difficult to trace. There would a heavy overhead of the distribution of the new IOR, I think this would need to be distributed to almost all.
In appraoch 2, a search request would be forwarded and it need to return the latest IOR or IOR information.
In appraoch 2, a category of identifying parameter needs to be passed by the servant to the birth MH and then by birth MH to connected MH, so that searching of the servant based on attributes can be done.

On movement the search attribute related entry in registers of neighbour MH is modified, so that the latest entry remains.