27.03.2014 Views

Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

D0103v1.doc Version 1 6.7.2003<br />

Since MTNM module is in user space and FHO module is in kernel space, as specified before, to<br />

exchange messages between them we deployed the character device technology. The character device is a<br />

special device which allows the communication between user space and kernel space; figure 17 depicts<br />

the behaviour of FHO module.<br />

USERSPACE<br />

MTNM<br />

KERNELSPACE<br />

FHO<br />

START_FHO<br />

L2_REQ<br />

-Sending Router Soll. Proxy<br />

-Receiving Proxy Router Adv<br />

-Sending Fast Binding Update<br />

-Receiving Fast Binding Ack<br />

Configuring<br />

Layer 2 handover<br />

L2_ACK<br />

-Fast Handover Execution<br />

FHO_ACK<br />

Figure 17: User space/Kernel space communication<br />

The Fast Handover Module waits for the START_FHO message from the MTNM in order to trigger the<br />

fast handover mechanism (independently if the handover was triggered automatically or manually). Once<br />

the fast handover trigger is received, the message flow depicted in figure 18 is executed.<br />

According to what is specified in previous sections, the module performs two main tasks:<br />

• on the oldAR when the Router Solicitation Proxy message is received FHO module recovers<br />

AAAC context from AAAC Attendant and sends it, as data attached in the Handover Initiate<br />

message, to the newAR. In parallel a request for QoS availability is send to QoS attendant.<br />

• on the newAR, once the Handover Initiate message has been handled, FHO module waits for a<br />

response from QoS attendant about resource availability: in case of positive answer it relies the<br />

AAAC context to the AAAC attendant, otherwise this step is just skipped. In both conditions an<br />

Handover Acknowledgement is send back to the oldAR in order to inform the MN (MTNM)<br />

about the possibility or not to perform handover.<br />

Mobile IPv6 messages exchanged between MN-oldAR-newAR are realized via new types of ICMP<br />

messages, which are created by the Fast Handover Module and sent via ‘standard’ IPv6 kernel functions<br />

(i.e., interface Fast Handover Module and IPv6 stack). .<br />

The “layer 2” handover is triggered via the interface with MTNM module (i.e. character device); the<br />

messages L2_req (layer 2 handover request) and L2_ack (layer 2 handover acknowledgement) are<br />

exchanged between MTNM module and FHO module after receiving the message Fast Binding<br />

Acknowledgement on the MN.<br />

The last message (FHO_ACK) informs MTNM module about the result of the handover: if all the steps<br />

described are well performed the returned status is safe, otherwise, if the handover is not possible, (e.g. a<br />

lack of resources on the new link) MTNM will try to use another technology (if available) or to access<br />

another link.<br />

D0103v1.doc 34 / 168

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!