ES2257342T3

ES2257342T3 - Metodo para el tunelado en redes no aseguradas en cuanto a secuencia.

Info

Publication number: ES2257342T3
Application number: ES00981135T
Authority: ES
Inventors: Klaus David Gradischnig; Michael Tuxen; Hanns Jurgen Schwarzbauer
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 1999-09-30
Filing date: 2000-09-29
Publication date: 2006-08-01
Anticipated expiration: 2020-09-29
Also published as: WO2001026319A2; EP1216551B1; WO2001026319A3; EP1216551A2; DE50012661D1

Abstract

Procedimiento para la transmisión de mensajes de una aplicación de comunicaciones a través de redes, según el cual los mensajes que son enviados mediante un protocolo de transmisión del nivel 2, que presupone que el tramo de transmisión que se encuentra debajo mantiene la secuencia de los mensajes, son conducidos antes de llegar a una red no asegurada en cuanto a secuencia a través de un puente (Bridge), a través del cual son retransmitidos por la red no asegurada en cuanto a secuencia de una forma transparente para la aplicación de comunicaciones, caracterizado porque los citados mensajes son dotados por el puente de números secuenciales, con cuya ayuda es posible el funcionamiento del aseguramiento de secuencia, y debido a que el propio puente no repite ningún mensaje.

Description

Método para el tunelado en redes no aseguradas en cuanto a secuencia.

1. ¿Qué problema técnico ha de resolverse mediante su invención?

2. ¿Cómo se ha solucionado este problema hasta ahora?

3. ¿De qué manera resuelve su invención el problema técnico indicado (indique usted ventajas)?

4. Ejemplo(s) de la invención.

Respecto a 1

Muchos protocolos de transmisión del nivel 2 presuponen en el tramo de transmisión que se encuentra debajo que éste mantiene la secuencia de mensajes, es decir, un mensaje enviado no puede adelantar a un mensaje enviado previamente. Con la difusión siempre creciente de redes IP, surge el deseo de sustituir para muchas aplicaciones de comunicaciones (KA) un tramo de transmisión por una red IP, sin o con sólo una mínima variación de los protocolos de comunicaciones que son utilizados por la aplicación de comunicaciones.

Respecto a 2

Las soluciones utilizadas hasta ahora siguen distintas vías. Una de ellas es una solución de Gateway (puerta), en la que la pila del protocolo KA en una Gateway se termina hasta un determinado nivel (al menos hasta el nivel 2) y los mensajes KA se retransmiten entonces mediante protocolos basados en IP a la Gateway remota. Para ello hay para KA basadas en SS7 productos en el mercado, por ejemplo de la empresa Tekelek. Otra solución consiste en la sustitución de los niveles inferiores de la pila de protocolo de la KA por protocolos basados en IP. Una tercera solución consiste en una modificación del nivel 2 existente, con lo que también puede utilizarse en redes IP. Un ejemplo de ello es la recomendación Q.2111, que actualmente se encuentra en elaboración en ITU, que modifica el protocolo SSCOP definido en Q.2110, entre otros para una utilización en redes IP. Todas estas soluciones precisan no obstante bien de una solución de Gateway (puerta) costosa, que dado el caso podría ser también específica de protocolo, o bien de una modificación de la KA existente, para hacer ésta "susceptible de IP".

Respecto a 3

La invención se basa en el conocimiento de que las funciones que garantizan una trasmisión de mensajes asegurada se separan de las funciones que aseguran una correcta secuencia de mensajes y pueden ser realizadas sobre distintas plataformas.

La invención soluciona el problema de tal manera que en lugar de una Gateway (puerta) se utiliza un puente (Bridge), que no termina el protocolo de nivel 2, sino que retransmite las PDUs del protocolo de manera transparente a través de la red IP, es decir, tunelea a través de la red. Esto se da también a conocer en la US 5594732, que no obstante no garantiza la correcta secuencia de mensajes. Se prescinde entonces de una utilización de TCP para el aseguramiento de la secuencia, ya que esto significa una "duplicidad" de la transmisión totalmente asegurada por parte de la red IP mediante TCP por un lado y el protocolo nivel 2 tunelado por otro lado, lo cual también origina una complejidad innecesaria de la Gateway. Además, para muchos protocolos a tunelear del nivel 2 y sus usuarios, no es aceptable el retardo de transmisión originado por el TCP. Por lo tanto, se describe una solución basada por ejemplo en UDP y/o IP. (Naturalmente funciona esta función y sus variantes con todos los protocolos del datagrama).

La invención se resuelve mediante las particularidades indicadas en las reivindicaciones 1 y 2.

Adicionalmente al protocolo de red utilizado, el puente sólo asegura que no se adelanta ninguna PDU.

Este aseguramiento tiene lugar mediante la introducción de los correspondientes números secuenciales en las PDUs enviadas a través de "túnel". En el puente recibido se vigila la secuencia correcta mediante los números secuenciales. Si se detecta un hueco, se espera un cierto tiempo para ver si llega o llegan la(s) PDU(s) que falta(n) antes de retransmitir las siguientes PDUs. Si tales PDUs que faltan sólo llegan una vez transcurrido el tiempo de espera, se desechan las mismas.

Queda a criterio de los nudos que contienen las KA y del protocolo del nivel 2 realizado allí el enviar de nuevo dado el caso las PDUs que faltan. Los puentes por sí mismos no repiten ninguna PDU. Para determinar este tiempo de espera, contiene cada mensaje un sello de tiempo absoluto, que indica cuándo ha sido enviado el mensaje. Al respecto se parte de que tanto el emisor como el receptor tienen (suficientes) relojes sincronizados en frecuencia; no obstante, no es necesario un sincronismo absoluto de los relojes. Con ello está el receptor en condiciones de aplicar métodos conocidos y comprobados para averiguar el tiempo de transmisión medio estimado y la varianza estimada del tiempo de transmisión. Éstos pueden ser utilizados para estimar con cierta probabilidad el máximo retardo a esperar de un mensaje en la red. Esta magnitud - juntamente con el sello del tiempo - puede utilizarse entonces para calcular el instante hasta el cual se espera a posibles mensajes que aún falten.

Eligiendo la forma como a partir de ambas magnitudes estimadas se calcula el máximo retardo admisible, puede optimizarse la Perfomance (rendimiento) del túnel, realizando el equilibrado deseado entre un desechado innecesario de PDUs (tiempo de espera demasiado pequeño) y un retardo demasiado largo debido a una espera demasiado larga a PDUs perdidas (tiempo de espera demasiado grande).

Introduciendo adicionalmente un sello de tiempo relativo que indica el tiempo transcurrido desde el envío de la última PDU y que puede ser dado a cada PDU, puede seguirse optimizando el rendimiento, ya que de esta manera puede detectarse durante cuánto tiempo "se ha retardado ya" como mínimo un mensaje que aún falte. Al respecto puede procederse de tal manera que al llegar una PDU y una o varias PDUs que falten (inmediatamente) antes, se calcule mediante ambos sellos de tiempo el instante de envío de las PDUs que falten previamente y a continuación se decida mediante el procedimiento antes indicado si ha de esperarse y durante cuánto tiempo ha de esperarse aún a las mismas.

Evidentemente puede seguirse optimizando el procedimiento con otros sellos de tiempo relativos adicionales. Ello no necesita descripción más detallada.

Una ventaja de esta solución reside en que un puente es bastante más sencillo y económico de realizar que una Gateway (puerta), ya que no tiene que ser terminado ningún protocolo y se necesita menos espacio de memoria. Además, esta solución es adecuada para prácticamente todos los protocolos, aún cuando para algunos, como por ejemplo el MTP del nivel 2, puede ser ventajoso introducir procedimientos específicos del protocolo en el puente, para minimizar el envío de PDUs superfluas, (por ejemplo determinadas FISU) a través de la red IP.

Una variante de la utilización de la solución antes descrita es la realización de las funciones adicionales, que hacen que un protocolo "convencional" sea susceptible de red IP (es decir, las funciones que compensan una posible permuta de mensajes de las capas inferiores) en un puente separado. Al respecto, corresponde el protocolo, que se utiliza sobre uno de los lados del puente, al protocolo original, no susceptible de red IP (por ejemplo SSCOP según Q. 2110), mientras el otro lado corresponde al protocolo modificado (en el ejemplo, por lo tanto, el SSCOPMCE de la Q.2111). En comparación con la primera variante, el puente se vuelve más complejo, pero sigue siendo no obstante más sencillo y económico que una Gateway (puerta), en la que deben ser realizados ambos protocolos, por ejemplo SSCOP y SSCOPMCE. Por otro lado, la ventaja de una solución como la indicada es que este puente puede comunicar directamente con una realización plena del protocolo modificado (por ejemplo el SSCOPMCE). Esto puede ser ventajoso cuando por un lado es necesario a corto plazo un cambio inmediato de una KA a comunicación a través de una red IP (para ello pueden utilizarse los puentes descritos) cuando no obstante a largo plazo ha de utilizarse directamente el protocolo modificado. Entonces siguen pudiendo comunicar precisamente nudos con el nuevo protocolo en la fase de cambio con los nudos servidos a través de puentes.

Respecto a 4

A continuación se describen más en detalle ejemplos de ejecución de la invención en base al dibujo, incluyendo el dibujo 3 figuras.

a): El ejemplo de ejecución para la primera variante de solución se describe aquí con la posibilidad indicada de la mejora de rendimiento. Igualmente se describe aquí la solución sobre la base del protocolo UDP. Por razones de simplicidad, se considera aquí sólo el caso en el que un emisor comunica sólo con otra máquina de protocolo. La ampliación a varias máquinas de protocolo es no obstante realizable de manera sencilla utilizando el zócalo del lado contrapuesto para identificar la comunicación.

Formato de los mensajes

Aquí se describe el formato del Payload (carga útil) de un datagrama de UDP. Tal como se representa en la figura 1, contiene cada mensaje el tiempo de envío N(T_{s}), la diferencia de tiempos N(T_{D}) en el instante de envío del mensaje precedente, el tiempo N(T_{F}) del envío del primer mensaje para esta relación de comunicaciones, un número de secuencia N(S), así como los datos del usuario. Al respecto, se indican los tiempos en el formato de 64 bits del NTP (RFC 958). El número secuencial incluye 32 Bits.

El emisor

Cuando se envía el primer mensaje al lado contrapuesto de un enlace, memoriza el emisor el tiempo de emisión de este mensaje en las variables de estado VT(T_{F}). Este tiempo sirve para identificar el enlace y se inscribe en todos los mensajes en el campo N(T_{F}). Si cae el emisor y se arranca de nuevo a continuación, puede reconocer esto el lado contrapuesto y desechar mensajes antiguos. El tiempo de emisión del mensaje se inscribe en el campo N(T_{s}) y se memoriza en el emisor en las variables de estado VT(T_{L}). Con ayuda del tiempo de emisión del primer mensaje, se forma la diferencia respecto al tiempo actual y se inscribe en el campo N(T_{D}). Además, se numeran correlativamente todos los mensajes. Esto tiene lugar cíclicamente y el número de secuencia se transporta en el campo N(S). Para ello necesita el emisor la variable de estado VT(S), que el mismo inicializa con 0.

El receptor

El receptor posee una memoria tampón (buffer) de resecuenciado, en la que memoriza transitoriamente mensajes que no recibe en la secuencia correcta. Esta memoria puede memorizar hasta VR(W) mensajes. La variable de estado VR(S) contiene el número de secuencia del siguiente mensaje esperado en la secuencia correcta. El mismo se inicializa con 0. El buffer de resecuenciado puede memorizar por lo tanto los mensajes con N(S)=VR(S), VR(S)+1,... . VR(S)+VR(W)-1. (La aritmética tiene lugar en Z/(2^32)). El receptor inicializa la variable de estado VR(T_{F})con 0. Este instante se encuentra siempre en el pasado. Si recibe el receptor un mensaje con N(T_{F}) < VR(T_{F}), entonces desecha el mensaje. Si es N(T_{F}) > VR(T_{F}), entonces se transfieren todos los mensajes en el buffer de resecuenciado a la capa de protocolo superior y se coloca VR(S) =0 y V(T_{F}) = N(T_{F}) y a continuación se procesa el mensaje de forma normal.

Si es N(T_{F}) = VR(T_{F}), entonces se procesa el mensaje de forma normal como sigue: Si es N(S)= VR(S), entonces puede enviarse este mensaje a la capa superior e incrementarse VR(S). Si es VR(S) < N(S) < VR(S) +VR(W), entonces se inscribe el mensaje en el buffer de resecuenciado. Entonces se calcula el tiempo en el que este mensaje y el precedente deben ser transferidos como muy tarde a la capa más elevada. Si se encuentra uno de estos instantes en el pasado o se corresponde con el instante actual, entonces se transfieren inmediatamente éstos y todos los mensajes con número de secuencia inferior a la capa más elevada. Además, se coloca VR(S) igual a N(S)+1. Si ambos instantes se encuentran en el futuro, entonces se asegura mediante un temporizador que el mensaje se transferirá en el instante esperado a la capa más elevada. Cuando transcurre el tiempo del temporizador, se transfiere el correspondiente mensaje a la capa más elevada y se coloca VR(S) en N(S)+1. Si es VR(S)-2^31 < = N(S)< VR(S), entonces se evalúa el mensaje como caducado y se desecha. Si es VR(S)+ VR(W)< = N(S)+2^31, entonces el mensaje es nuevo. Todos los mensajes en el buffer de resecuenciado con N(S) entre VR(S) y N(S)- VR(W), se transfieren a la capa más elevada. Entonces se coloca VR(S) en N(S)- VR(W)+1 y se memoriza el mensaje recibido. Si ya está incluido un mensaje con N(S)=VR(S), se transfiere el mismo a la capa superior y se incrementa V(S). A continuación, se repite esta comprobación.

b): Como ejemplo de ejecución para la segunda variante de solución, sirven los protocolos según Q.2110 y Q.2111. Las figuras 2 y 3 muestran ambos casos posibles de aplicación. Las funciones esenciales a ejecutar por parte del puente son como sigue:

\bullet: Los estados de los enlaces han de ser transmitidos simultáneamente. Aquí es posible una simplificación, dando lugar cada ER o bien ERAK y RS o bien RSAK PDU a que el puente finalice por ambos lados el enlace mediante el envío de END PDUs.

\bullet: Las variables definidas adicionalmente en SSCOPMCE y el temporizador, han de ser gestionados.

\bullet: Ciertas variables ya existentes en SSCOP (p.ej. VT (SQ), VR(SQ), VT(MS), VT(PS), VT(PA), VT(PS), VT(S), VR(H)), deben ser arrastradas.

\bullet: Nuevas variables específicas del puente VT(Soff) y VR(Soff), que memorizan los valores de los números de secuencia VT(S) y VR(S) utilizados al comienzo del enlace por el SSCOPMCE receptor y emisor, para adaptar correspondientemente los números secuenciales contenidos en los SD, STAT, USTAT y POLL PDUs.

\bullet: Reproducción del estado del buffer de entrada del SSCOP mediante la correspondiente evaluación de las informaciones contenidas en el STAT y USTAT PDUs recibidos por el SSCOP. Esto es importante para decidir si se espera aún a un mensaje "antiguo" o si se trata de una repetición a desechar, cuya recepción colocaría al protocolo SSCOP en un estado de error.

\bullet: Gestión de un buffer en el que las SD PDUs recibidas por la red IP esperan a SD PDU que aún faltan.

Detalles o bien otras funciones resultan de la descripción bajo 3. o bien de las definiciones de SSCOP (Q.2110) y SSCOMPCE (Q.2111) y pueden ejecutarse fácilmente cuando se conocen estas informaciones.

Claims

1. Procedimiento para la transmisión de mensajes de una aplicación de comunicaciones a través de redes, según el cual los mensajes que son enviados mediante un protocolo de transmisión del nivel 2, que presupone que el tramo de transmisión que se encuentra debajo mantiene la secuencia de los mensajes, son conducidos antes de llegar a una red no asegurada en cuanto a secuencia a través de un puente (Bridge), a través del cual son retransmitidos por la red no asegurada en cuanto a secuencia de una forma transparente para la aplicación de comunicaciones, caracterizado porque los citados mensajes son dotados por el puente de números secuenciales, con cuya ayuda es posible el funcionamiento del aseguramiento de secuencia, y debido a que el propio puente no repite ningún mensaje.

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

caracterizado porque los mensajes de la citada aplicación de comunicaciones son conducidos antes de abandonar la red no asegurada en cuanto a secuencia a través de otro puente, mediante el cual se ejecuta la función del aseguramiento de secuencia en base a las informaciones adicionales contenidas en los mensajes.

3. Puente que

a): recibe mensajes de una aplicación de comunicaciones que se envían a través de un protocolo de transmisión del nivel 2, que presupone que el

b): tramo de transmisión que se encuentra debajo mantiene la secuencia de los mensajes antes de entrar en una red no asegurada en cuanto a secuencia,

c): retransmite los mensajes recibidos de una manera transparente para la aplicación de comunicaciones a través de la red no asegurada en cuanto a secuencia, caracterizado porque el puente dota los mensajes de números secuenciales, con cuya ayuda la función del aseguramiento de secuencia es posible y debido a que el puente por sí mismo no repite mensaje alguno.

4. Puente según la reivindicación 3, caracterizado porque un lado del puente utiliza el protocolo SSCOP (Q.2110) y el otro lado del puente el protocolo SSCOPMCE (Q.2111), realizando el puente la adaptación entre ambos protocolos.