General Layout

En el capítol anterior s’han vist les modificacions implementades sobre el codi font del dimoni UMIP per tal de d’admetre nodes dormants i eliminar el trànsit cap a l’MN.

Per tal de validar les modificacions realitzades, s’ha dut a terme un pla de proves sobre el demostrador MIPv6 (vegeu la figura 3.1).

Fig. 3.1. Escenari de proves

Per a facilitar la lectura de les proves, a continuació es resumeix el comportament del MN i l’HA atenent a les modificacions descrites al capítol anterior. En l’estat actiu, l’MN es comporta de la mateixa manera que el dimoni UMIP original, mentre que en l’estat dormant apareixen els següents canvis:

 L’MN només envia els missatges Binding Update cap a l’HA cada temps HaMaXBindingLife (paràmetre definit a l’HA). Si aquest paràmetre no es

defineix, es pren per defecte el paràmetre MnMaxHaBindingLife de l’MN (vegeu l’Annex III).

 L’MN no processa els Router Advertisement que provenen del router. En lloc d'això, llegeix cada temps Router Expired l’SSID de l’AP a què es troba connectat i dedueix l’adreça de xarxa del router. Amb l’adreça llegida, pot emular la recepció d’un paquet RtrAdv i seguir en estat dormant.

 Quan l’MN fa la transició de l’estat dormant a actiu, torna a processar els RtrAdv i es comporta de la mateixa manera que el dimoni original.

 Quan l’MN canvia de xarxa però no d’àrea de paging, fa el traspàs de manera silenciosa i no informa l’HA del canvi. L’MN no passa a l’estat actiu ni canvia de CoA.

 Quan l’MN canvia de xarxa i d’àrea de paging, fa el traspàs però no canvia a l’estat actiu. Tot seguit envia un Binding Update cap a l’HA per a informar del canvi.

 En cas que un node vulgui enviar informació cap a l’MN, l’HA envia un missatge Binding Refresh Request cap a l’MN per a obligar-lo a passar a l’estat actiu. Aquesta implementació només és funcional en cas que l’MN no canviï de xarxa, ja que en estat dormant sempre es conserva la CoA i, per tant, no es pot enviar directament el paquet BRR cap a l’MN tal com s’explica al Capítol 2. En un futur caldrà implementar aquesta funcionalitat.

 En cas que l’MN vulgui enviar trànsit, passa automàticament a l’estat actiu, avisa l’HA i envia la informació.

Al llarg dels apartats següents es descriuen en primer lloc les proves realitzades i tot seguit es validen per tal de deixar constància del funcionament correcte del projecte.

3.1.1. Prova 1: l’MN canvia a l’estat dormant

En aquesta prova es vol comprovar que l’MN decideix correctament quan ha de passar a l’estat dormant.

Inicialment, l’MN es registra amb l’HA i passa a l’estat actiu. Tot seguit, es força una comunicació amb el CN (mitjançant l’eina ping6) de manera que es troben els escenaris següents:

 P1.1 L’MN rep i transmet trànsit  P1.2 L’MN rep trànsit

 P1.3 L’MN transmet trànsit

3.1.1.1. Resultats esperats

Per a cadascuna de les proves realitzades a l’apartat 3.1.1, s’espera que l’MN es comporti de la manera següent:

 P1.1 L’MN rep i transmet trànsit: l’MN sempre es troba en l’estat actiu i envia correctament els missatges BU cap a l’HA.

 P1.2 L’MN rep trànsit: l’MN sempre es troba en l’estat actiu i envia correctament els missatges BU cap a l’HA.

 P1.3 L’MN transmet trànsit: l’MN sempre es troba en l’estat actiu i envia correctament els missatges BU cap a l’HA.

 P1.4 L’MN no rep ni transmet trànsit: l’MN fa una transició a l’estat dormant i envia correctament el missatge BU cap a l’HA amb el flag dormant. L’HA inclou correctament el node a la llista de nodes dormants.

3.1.2. Prova 2: l’MN canvia a l’estat actiu

En aquesta prova es vol comprovar que l’MN decideix correctament quan ha de passar a l’estat actiu.

Inicialment, l’MN es registra amb l’HA i passa a l’estat actiu. Una vegada en l’estat actiu, no envia ni rep trànsit durant tot un període de Binding Lifetime i, per tant, passa a l’estat dormant. Tot seguit, es força una comunicació amb el CN (mitjançant l’eina ping6), de manera que es troben els escenaris següents:  P2.1 L’MN no té trànsit per a enviar ni per a rebre

 P2.2 L’MN no té trànsit per a enviar  P2.3 L’MN no té trànsit per a rebre 3.1.2.1. Resultats esperats

Per a cadascuna de les proves realitzades a l’apartat 3.1.2, s’espera que l’MN es comporti de la manera següent:

 P2.1 L’MN no té trànsit per a enviar ni per a rebre: l’MN sempre es troba en l’estat dormant i envia correctament els missatges BU cap l’HA amb el flag dormant activat cada Binding Lifetime (valor que imposa l’HA).

 P2.2 L’MN no té trànsit per a enviar: l’MN sempre es troba en l’estat dormant i envia correctament els missatges BU cap l’HA amb el flag dormant activat cada Binding Lifetime (valor que imposa l’HA).

 P2.3 L’MN no té trànsit per a rebre: l’MN sempre es troba en l’estat dormant i envia correctament els missatges BU cap l’HA amb el flag dormant activat cada Binding Lifetime (valor que imposa l’HA).

3.1.3. Prova 3: l’MN avisa correctament l’HA per canvi d’àrea de paging

En aquesta prova es vol comprovar que l’MN decideix correctament quan ha d’avisar l’HA en cas que l’MN canviï de xarxa.

Inicialment, l’MN es registra amb l’HA i passa a l’estat actiu, i es força un canvi de xarxa.

 P3.1 L’MN canvia de xarxa

Una vegada superada la prova, l’MN no envia ni rep trànsit durant tot un període de Binding Lifetime i, per tant, passa a l’estat dormant. Tot seguit, es força un canvi de xarxa.

 P3.2 L’MN canvia de xarxa dins la mateixa àrea de paging  P3.3 L’MN canvia de xarxa i d’àrea de paging

3.1.3.1. Resultats esperats

Per a cadascuna de les proves realitzades a l’apartat 3.1.3, s’espera que l’MN es comporti de la manera següent:

 P3.1 L’MN canvia de xarxa: l’MN fa el canvi de xarxa i informa l’HA del canvi.

 P3.2 L’MN canvia de xarxa dins la mateixa àrea de paging: l’MN fa el canvi de xarxa però no passa a l’estat actiu ni canvia de CoA. Tampoc no informa l’HA del canvi.

 P3.3 L’MN canvia de xarxa i d’àrea de paging: l’MN fa el canvi de xarxa, canvia de CoA i informa l’HA del canvi.

3.1.4. Prova 4: comportament de l’HA per a localitzar l’MN

En aquesta prova es vol comprovar que l’HA localitza correctament l’MN quan aquest es troba en l’estat dormant.

Inicialment, l’MN es registra amb l’HA i passa a l’estat actiu. Una vegada en l’estat actiu, no envia ni rep trànsit durant tot un període de Binding Lifetime i, per tant, passa a l’estat dormant. Tot seguit, es força una comunicació amb el CN (mitjançant l’eina ping6), de manera que es troba l’escenari següent:

3.1.4.1. Resultats esperats

Per a la prova realitzada a l’apartat 3.1.4, s’espera que l’HA i l’MN es comportin de la manera següent:

 P4.1 El CN envia trànsit a l’MN que no ha canviat de xarxa: l’HA envia un paquet BRR cap a l’MN. L’MN respon a aquest paquet enviant automàticament un Binding Update i passant a l’estat actiu.

3.1.5. Prova 5: retard

En aquesta prova es vol comprovar el retard l’eficiència de l’enviament de paquets ICMPv6 del CN cap a l’MN i més concretament l’impacte d’IP Paging sobre el mateix.

Per als dos escenaris següents s’ha realitzat una prova empírica dels valors d’RTT (Round Trip Time):

 P5.1 El CN envia trànsit a l’MN en l’estat actiu  P5.2 El CN envia trànsit a l’MN en l’estat dormant 3.1.5.1. Resultats esperats

Per a les proves realitzades a l’apartat 3.1.5, s’esperen els resultats següents:

 P5.1 El CN envia trànsit a l’MN en l’estat actiu: s’espera un RTT major en l’enviament del primer paquet ICMPv6 cap a l’MN. L’RTT de la resta de paquets ICMPv6 també és superior a la mitjana en cas de fer un ping6 directament a la CoA de l’MN.

 P5.2 El CN envia trànsit a l’MN en l’estat dormant: s’espera un RTT major que el de la prova P5.1 en l’enviament del primer paquet ICMPv6 cap a l’MN.