PROCEDIMIENTO PARA OPTIMIZAR LA SEÑALIZACION NSIS EN APLICACIONES MOVILES BASADAS EN MOBIKE.

Procedimiento para reducir la parte general (overhead) del mensaje de señalización de un nodo móvil (MK),

que mantiene al menos una sesión activa de señalización Next-Steps-In-Signaling NSIS (próximos pasos en la señalización), así como un enlace MOBIKE con una pasarela (gateway) de una red privada virtual (VPN), y que cambia su punto de enlace con Internet,

caracterizado por las siguientes etapas de procedimiento:

- inserción de al menos una dirección de IP de la gateway VPN y/o de un espacio de direcciones que coincide con la subred de la gateway VPN en un objeto de información de enrutamiento de mensaje (Message-Routing-Information; MRI) contenido en el mensaje de señalización,

- fijación de un valor para un índice de parámetro de seguridad (Security Parameter Index; SPI),

- inserción del valor de SPI en el objeto MRI, así como

- activación de un indicador (flag) S en el objeto MRI, así como

- inserción de un espacio de direcciones que se refiere a la dirección de IP del MK en el objeto MRI,

- limitándose tanto como sea posible, el espacio de direcciones para la dirección de IP propia, indicándose el espacio de direcciones que se refiere a la dirección de IP del MK mediante indicación de una dirección de IP del MK y de un prefijo

Procedimiento para optimizar la señalización NSIS en aplicaciones móviles basadas en MOBIKE.

La invención se refiere a un procedimiento para reducir la parte general (overhead) del mensaje de señalización de un nodo móvil, que mantiene al menos una sesión activa de señalización Next-Steps-In-Signaling (próximos pasos en la señalización), así como un enlace MOBIKE con una pasarela (gateway) de una red privada virtual (VPN), y que cambia su punto de enlace con Internet, según el preámbulo de la reivindicación 1.

Una red privada virtual (VPN) es una red de ordenadores que para el transporte de datos privados utiliza una red pública, por ejemplo Internet. Los abonados de una VPN puede intercambiar datos como en una red local interna (Local Area Network; LAN). Los propios abonados individuales no tienen que estar conectados directamente para ello. El enlace a través de la red pública se encripta usualmente. La conexión de un abonado que utiliza un llamado VPN-Client (cliente) con su red de lugar de origen que pone a disposición un llamado VPN Server (servidor), es posible mediante un túnel entre el VPN-Client y el VPN-Server. La mayoría de las veces se asegura entonces el túnel, pero también puede utilizarse un túnel de texto explícito no asegurado para conectar un VPN-Client con un VPN-Server.

Una VPN puede servir entre otros para dar a colaboradores externos a una organización o a una empresa acceso a la red interna. Entonces establece el ordenador del colaborador un enlace VPN con una pasarela (gateway) VPN de la empresa. Mediante este enlace le es posible ahora al colaborador funcionar como si él se encontrase en la red local de la empresa.

Para posibilitar una transmisión segura de datos en VPNs, se necesitan protocolos especiales. Un grupo de tales protocolos se conoce en conjunto como IP-security (IPsec, seguridad de IP). Al mismo pertenecen entre otros la Internet Key Exchange Version 2 (IKEv2, versión de intercambio de claves por Internet). La misma es responsable de generar las claves necesarias para los mecanismos criptográficos, también de otros protocolos. Un túnel constituido utilizando IPsec para un enlace VPN se denomina también túnel IPsec. El protocolo Mobile-Internet-Key-Exchange o de intercambio de claves por Internet móvil (protocolo MOBIKE) amplía el IKEv2 contenido en IPsec, en el sentido de que posibilita al cliente VPN cambiar su punto de enlace con la red sin que el cambio de dirección de su protocolo de Internet (IP) que ello implica dé lugar a que su sesión VPN tenga que establecerse de nuevo.

En un escenario VPN típico, intercambian un VPN-Client y una pasarela VPN (VPN-Gateway) datos a través de un túnel IPsec. Cuando el VPN-Client es un nodo móvil (MK), por ejemplo un laptop, un palmtop, un asistente digital personal (Personal Digital Assistent, PDA) o similar y cuando éste cambia de punto de enlace con Internet, se modifica también su dirección de IP. En el protocolo MOBIKE está especificado cómo se gestiona de manera efectiva este cambio de dirección en el escenario VPN. Cuando el MK ha iniciado una sesión de señalización Next-Steps-In-Signaling (NSIS) para este túnel, entonces debe actualizarse cuando hay un cambio de punto de enlace el estado de todos los nodos capaces de NSIS que a lo largo de la ruta del túnel participan en la señalización, para poder seguir el cambio de la dirección de IP del MK. Este proceso implica una parte general del mensaje (overhead), que es tanto más grande cuanto más a menudo cambie el MK su punto de enlace. Puede resultar un malgasto adicional de recursos cuando los antes citados nodos NSIS han reservado recursos para el flujo de datos del túnel IPsec. Tales reservas de recursos, como por ejemplo velocidad de transmisión, anchura de banda y similares, se realizan por ejemplo cuando la señalización es una señalización de calidad del servicio (Quality of Service, QoS), por ejemplo la QoS-NSLP (Quality of Service NSIS Signaling Layer Protocol, protocolo de la capa de señalización NSIS), generado por el Grupo de Trabajo NSIS). El antes citado malgasto surge porque en el espacio de tiempo entre el cambio de dirección y la antes citada actualización del estado los recursos reservados no están a disposición del flujo de datos del túnel Ipsec ni en otro lugar. Esto significa igualmente que el flujo de datos no puede utilizar los recursos reservados para el mismo hasta que se haya realizado la actualización de todos los nodos NSIS a lo largo de la ruta. Esto a su vez significa que las garantías QoS prometidas al principio no pueden mantenerse. El usuario percibe esto por ejemplo porque la velocidad de transmisión empeora claramente.

Por el estado de la técnica no se conoce ninguna solución que permita una optimización de la señalización NSIS cuando cambia el punto de enlace del MK en espacios MOBIKE. Los informes de trabajo del grupo de trabajo NSIS (ver por ejemplo draft-cheng-nsis-flowid-issues-02.txt), describen solamente los métodos básicos sobre cómo han de aplicarse los protocolos de señalización NSIS en escenarios móviles. Estos métodos exigen que el MK envíe mensajes de señalización siempre que se modifique su dirección de IP. Es tarea de estos mensajes actualizar los estados de los nodos NSIS que participan en la sesión de señalización con la dirección de IP actual del MK.

Por lo tanto, es tarea de la invención indicar un procedimiento que evite los citados retardos y el malgasto de recursos que ello implica.

Esta tarea se resuelve mediante un procedimiento según la reivindicación 1. Ventajosos perfeccionamientos de la invención resultan de las reivindicaciones dependientes y de la siguiente descripción.

El procedimiento correspondiente a la invención para reducir la parte general (overhead) del mensaje de señalización o bien para reducir el malgasto de recursos que puede resultar cuando un nodo móvil que mantiene al menos una sesión de señalización Next-Steps-In-Signaling activa y que tiene un enlace MOBIKE con una gateway VPN cambia su punto de enlace con Internet, incluye las siguientes etapas de procedimiento:

El espacio de direcciones que se refiere a la dirección de IP del MK se indica indicando una dirección de IP del MK y un prefijo. El prefijo indica qué parte de la dirección de IP del MK puede modificarse sin que la dirección de IP del MK abandone el correspondiente espacio de direcciones. Según el estándar GIST utilizan los nodos NSIS que participan en la sesión de señalización la gama de direcciones de IP que viene definida por el par que incluye la dirección de IP del MK y el prefijo, para identificar los paquetes pertenecientes al flujo de datos del túnel IPsec. Más exactamente, pertenecen los paquetes de datos al flujo de datos cuando la dirección de IP del MK indicada en la cabecera del IP se encuentra en esta gama de direcciones. Cuando se modifica ahora la dirección de IP del MK dentro de esta gama de direcciones, tampoco tiene que realizarse una actualización de los estados de los nodos NSIS a lo largo de la ruta del túnel Ipsec. Así se reducen o evitan de manera efectiva la parte general del mensaje (cabecera) y el malgasto de recursos que eventualmente pudiera producirse.

Una ventajosa configuración del procedimiento correspondiente a la invención prevé que en el objeto MRI se indique un espacio de direcciones para la dirección de IP del MK que incluya las posibles direcciones de IP para el MK que son de esperar considerando el movimiento usual del MK. Al respecto puede pensarse en que los movimientos del MK se vigilen y las direcciones de IP asignadas durante su movimiento se memoricen, para deducir de ello un perfil de movimiento preferente y un espacio de direcciones que incluya las direcciones de IP asignadas al MK dentro de su espacio...

1. Procedimiento para reducir la parte general (overhead) del mensaje de señalización de un nodo móvil (MK), que mantiene al menos una sesión activa de señalización Next-Steps-In-Signaling NSIS (próximos pasos en la señalización), así como un enlace MOBIKE con una pasarela (gateway) de una red privada virtual (VPN), y que cambia su punto de enlace con Internet,

caracterizado por las siguientes etapas de procedimiento:

2. Procedimiento según la reivindicación 1,

caracterizado porque el prefijo indica qué parte de la dirección de IP del MK puede modificarse sin que la dirección de IP del MK abandone el correspondiente espacio de direcciones.

3. Procedimiento según la reivindicación 1 ó 2,

caracterizado porque adicionalmente se indica en el objeto MRI un espacio de direcciones para la dirección de IP del MK, que incluye las direcciones de IP móviles posibles para el MK que son de esperar teniendo en cuenta el movimiento usual del MK.

4. Procedimiento según una de las reivindicaciones precedentes,

caracterizado porque el valor del SPI se fija mediante la pasarela (gateway) VPN tal que se evitan colisiones entre túneles IPsec que existen entre distintos MK y la misma pasarela (gateway) VPN.

5. Procedimiento según una de las reivindicaciones 1 a 3,

caracterizado porque el valor del SPI se elige aleatoriamente, o mediante una función apropiada por medio del NSIS-Session-Identifier (identificador de sesión NSIS).