[go: up one dir, main page]

ES2268066T3 - Procedimiento para la utilizacion de sctp (stream control transmission protocol, protocolo de transmision con control del flujo) en redes mpls (multi procol label switching,conmutacion de etiquetas multiprotocolo). - Google Patents

Procedimiento para la utilizacion de sctp (stream control transmission protocol, protocolo de transmision con control del flujo) en redes mpls (multi procol label switching,conmutacion de etiquetas multiprotocolo). Download PDF

Info

Publication number
ES2268066T3
ES2268066T3 ES02754294T ES02754294T ES2268066T3 ES 2268066 T3 ES2268066 T3 ES 2268066T3 ES 02754294 T ES02754294 T ES 02754294T ES 02754294 T ES02754294 T ES 02754294T ES 2268066 T3 ES2268066 T3 ES 2268066T3
Authority
ES
Spain
Prior art keywords
information
network
protocol
route
entities
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES02754294T
Other languages
English (en)
Inventor
Michael Tuxen
Jochen Grimminger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Application granted granted Critical
Publication of ES2268066T3 publication Critical patent/ES2268066T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

Procedimiento para la transmisión de informaciones (14) a través de una red entre dos entidades (11), con un primer protocolo, que es MPLS y que utiliza para la transmisión de informaciones (14) entre dos entidades (11) rutas de red, caracterizadas por etiquetas que sirven en cada caso para representar una FEC (= Forward Equivalence Class, clase de equivalencia de retransmisión) en MPLS, estando determinadas inequívocamente una entidad de destino (11) y una entidad de origen (11) de las rutas de red con una etiqueta, y estando asignada la etiqueta inequívocamente a una ruta de red, con un segundo protocolo de transporte que se construye sobre el primer protocolo, asegurando el protocolo de transporte la recepción de una información (14) mediante una información de confirmación, con una primera etapa de inicialización (Init), en la que a través de una primera ruta de red se intercambian 1 a n etiquetas de rutas de red, que permiten un intercambio de informaciones entre las entidades (11), con una segunda etapa de intercambio de informaciones, en la que se intercambian las informaciones (14) a través de las 1 a n rutas de red.

Description

Procedimiento para la utilización optimizada de SCTP (Stream Control Transmission Protocol, protocolo de transmisión con control del flujo) en redes MPLS (Multi Protocol Label Switching, conmutación de etiquetas multiprotocolo).
SCTP [RFC2960] es un protocolo de transporte que ofrece una elevada redundancia en la red, es decir, queda asegurado que todos los datos enviados llegan en la secuencia correcta. Al respecto, se utiliza no sólo una posible vía de transporte como por ejemplo en TCP [RFC793] (realizada mediante IP [RFC 791]), sino varias. Esto es necesario en aplicaciones que deben practicarse con una elevada disponibilidad, como señalizaciones en redes PSTN. Entonces se utiliza como capa de red IP. SCTP apoya IP mediante parámetros adecuados (genéricos) en los avisos que se intercambian al establecer el enlace entre dos interlocutores.
En las actuales redes núcleo (core) "IP", tal como las que se utilizan en la comunicación sin hilos con por ejemplo UMTS, se renuncia cada vez con más frecuencia al simple IP. Se establecen más bien con ayuda de MPLS (Multi Protocol Label Switching, conmutación de etiquetas multiprotocolo) [RFC 3031]) entre distintos elementos de red LSPs (Label Switched Path, ruta conmutada por etiqueta) directos, utilizando ingeniería de tráfico. Los procedimientos conocidos se dan a conocer en los documentos [RFC 2960] y [RFC3031].
Por H. Schneider, "The concept of virtual paths and virtual channels in ATM-networks" (el concepto de rutas virtuales y canales virtuales en redes ATM), Circuitos y Sistemas Electrónicos para Comunicaciones, ETH Zurich, Mar. 5-8, 1990, Actas del Seminario Internacional de Zurich sobre Comunicaciones Digitales, Zurich, Instituto para la Electrónica Cuántica CH, 5.3.1990, págs. 63-72, se conoce un procedimiento para el enrutado mediante canales virtuales o bien rutas virtuales en redes de banda ancha sobre la base de ATM (asynchronous transfer mode, modo de transferencia asíncrono). Cuando se utilizan estos canales o bien rutas virtuales, se utilizan los llamados VCI (= Virtual Channel Identifier, identificador de canal virtual) o bien VPI (= Virtual Path Identifier, identificador de ruta virtual). Estos valores VCI o bien VPI sirven para retransmitir informaciones. Es tarea de la presente invención utilizar SCTP optimizado en redes MPLS.
Esto se resuelve mediante las particularidades de las reivindicaciones independientes, en especial por medio de un procedimiento para la transmisión de informaciones a través de una red entre dos entidades con un primer protocolo, que es MPLS y que utiliza para la transmisión de informaciones entre dos entidades rutas de red, caracterizadas por etiquetas que sirven en cada caso para representar una FEC (= Forward Equivalence Class, clase de equivalencia de retransmisión) en MPLS, estando determinadas inequívocamente una entidad de destino y una entidad de origen de las rutas de red con una etiqueta, y estando asignada la etiqueta inequívocamente a una ruta de red.
Este primer protocolo sirve solamente para enrutar las informaciones hasta la entidad de destino. El mismo no asume la tarea de comprobar también si las informaciones realmente han llegado. Para ello es necesario un segundo protocolo de transporte.
El segundo protocolo de transporte, que se construye sobre el primer protocolo, confirma la recepción de una información mediante una información de confirmación, que se envía de retorno a la entidad de origen. El procedimiento de la presente invención debe poner a disposición no solamente una ruta para la transmisión de informaciones, sino varias rutas. Estas deben ser comunicadas al establecerse la comunicación.
En un primer paso de inicialización (Init) se intercambian a través de una primera ruta de red 1 a n etiquetas de otras rutas de red. Cada una de estas rutas de red permite un inequívoco intercambio de informaciones entre las entidades. Una vez que se han intercambiado las rutas de red a través de las cuales ha de realizarse la comunicación y el intercambio de informaciones, se transmiten las informaciones a transmitir a través de las 1 a n rutas de red. En función de la situación de carga o del comportamiento en cuanto a respuesta sobre las distintas rutas de red, pueden distribuirse las informaciones a transmitir entre rutas de red menos cargadas.
Para evitar colisiones y para aumentar el flujo, se utilizan los circuitos de red solamente para un intercambio de informaciones unidireccional. Una utilización bidireccional es igualmente imaginable, pero no responde a las premisas del SCTP.
En un perfeccionamiento ventajoso, el primer protocolo es MPLS. La estructura detallada del protocolo se encuentra en (RFC 3031). Por lo demás, se describirá este protocolo en cuanto a sus fundamentos más adelante. Básicamente se reproducen protocolos de red mediante capas o bien layers individuales. Entonces el protocolo MPLS está dispuesto en la capa 2. Sobre este protocolo está previsto normalmente un protocolo IP en la capa 3, para asegurar la inequivocidad de la entidad emisora y de la receptora del paquete de informaciones. Sobre esta capa 3 se implanta TCP o bien alternativamente SCTP como protocolo de transporte en la capa 4. Estos dos protocolos aseguran también que el paquete de información efectivamente ha llegado, enviándose un nuevo paquete cuando no llega al emisor la confirmación de la recepción durante una ventana de tiempo predeterminada. Mediante la presente invención puede renunciarse a la capa 3 y con ello a su cabecera (overhead).
En una red MPLS se utilizan las llamadas FECs (Forwarding Equivalenc Classes, clases de equivalencia de retransmisión). Estas clases sirven para reproducir determinadas direcciones de IP sobre una etiqueta. Si existe por el contrario una relación bijectiva entre la dirección de IP y la clase de equivalencia, entonces puede utilizarse la etiqueta para asumir la tarea de la tercera capa. Esto significa que se utiliza solamente una etiqueta para las direcciones de IP emisora y receptora. De esta manera se corresponde cada FEC con una entidad de destino inequívoca y una entidad de origen inequívoca. Normalmente se intercambian mediante SCTP una serie de direcciones de IP que se gestionan como direcciones de destino o bien de origen y a través de las cuales se realiza el intercambio de informaciones. Una entidad presenta así varias direcciones de IP. Se habla de una entidad multi-homed (multipuerto). Los detalles sobre el SCTP se encuentran en RFC 2960 o bien más abajo. Una entidad es por lo general un servidor o un computador conocido. Puede pensarse no obstante también en que se trate de otros componentes de red, como por ejemplo enrutadores.
El protocolo de transporte del procedimiento correspondiente a la invención es SCTP, siendo sustituidas las direcciones de IP por las etiquetas de las rutas de red. En otra forma de perfeccionamiento se introducen etiquetas Id (de identificación) de ruta, que están situadas en la pila (stack) de los paquetes de información y que permiten una asociación inequívoca de la información a las distintas entidades de origen y de destino. De esta manera no tiene que ser inequívoca la ruta elegida, contrariamente a la alternativa antes citada. La utilización de una etiqueta de Id de ruta asegura que puede renunciarse a direcciones de IP, porque el receptor puede detectar, en base a la etiqueta de IP de ruta, de quién procede la información. El protocolo de transporte tiene básicamente la tarea de asegurar que las informaciones llegan y que se mantiene su secuencia. Para ello se utilizan los métodos conocidos del SCTP, que también son conocidos por el TCP. Los distintos paquetes, que contienen informaciones que se han separado una de otra, reciben una numeración. En base a esta numeración puede determinarse la secuencia de la composición. El TSN (Transmission Sequence Number, número de secuencia de transmisión) se asigna a cada paquete de información. Cada respuesta de las entidades receptoras o bien de destino, contiene el TSN, que previamente ha transmitido la entidad emisora o de origen. De esta manera puede determinarse si los paquetes efectivamente han llegado o si se han perdido. Si no llega una respuesta dentro del RTT (Round-Tripe Time, tiempo de ida y vuelta), entonces se envía de nuevo el paquete. El RTO (Retransmission Time-Out, tiempo de fin de retransmisión) determina el intervalo de tiempo al final del cual tiene lugar una nueva transmisión del paquete.
Antes de que las rutas de la red puedan servir para el intercambio de informaciones, deben establecerse las mismas. Para ello se utilizan procedimientos conocidos para la ingeniería del tráfico (Traffic-Engineering), que preferentemente trabajan con direcciones de IP, configurándose los enrutadores/switches de tal manera que para una ruta las entidades de destino y de origen son inequívocas. Los posibles procedimientos se describen en los documentos citados en la introducción a esta descripción.
En otra forma de perfeccionamiento se utiliza en la transmisión el Label-Stacking (apilamiento de etiquetas). A cada paquete de datos se le asigna una pila (stack), en la que se gestionan las etiquetas. Cada etiqueta equivale a una clase de equivalencia, tal como ya se ha descrito antes. Cuando llega un paquete de datos con una etiqueta a un enrutador, se desmonta la etiqueta que está más arriba en la pila y se sustituye por una nueva etiqueta, que se corresponde con esta clase de equivalencia sobre el enrutador actual. En base a la etiqueta inicial y a la etiqueta final, puede trazarse así de antemano la vía o bien la ruta del paquete con su información. SCTP elige, en función del flujo o del tiempo de respuesta, distintas rutas de red en la transmisión de informaciones. De esta manera se asegura un flujo elevado constante.
Otro componente de la invención es un dispositivo para intercambiar informaciones a través de una red que dispone de medios para realizar el procedimiento correspondiente a la invención. Al respecto, se trata preferentemente de aparatos terminales en forma de computadores, que disponen de una interfaz de red. Además se trata de enrutadores que se encuentran al principio de una ruta. Estos deben estar en condiciones de asignar las etiquetas a los correspondientes aparatos terminales. Las figuras muestran una posible forma de perfeccionamiento de la presente invención: se muestra en
Figura 1 una red con enrutadores que utilizan apilado de etiquetas (Label-Stacking), sustituyendo cada enrutador la etiqueta del enrutador precedente por su propia etiqueta, utilizándose adicionalmente una etiqueta de identificación de enrutadores que está dispuesta en la pila para asegurar la inequivocidad;
Figura 2 una red con enrutadores que utilizan apilamiento de etiquetas, sustituyendo cada enrutador la etiqueta del enrutador precedente por su propia etiqueta, describiendo las etiquetas una ruta inequívoca;
Figura 3 una red que reproduce el estado de la técnica, estando dispuesta la dirección IP en el paquete de datos.
La figura 1 muestra una red MPLS con dos entidades 11. Estas están unidas entre sí mediante dos rutas. Los paquetes de datos 12 son conducidos mediante enrutadores 16 a través de la red, para llegar a la correspondiente entidad de destino 11. Las rutas vienen caracterizadas por su etiqueta Id de ruta 13. La primera ruta presenta la etiqueta de identificación de ruta "pathID1". La segunda ruta viene caracterizada por la etiqueta de identificación de ruta "pathID2". Cada paquete de datos 12 presenta una pila, en la que se encuentran las etiquetas. Mediante la etiqueta que está más arriba 15, se determina el FEC. En la primera transmisión se asignó al paquete de datos la etiqueta con el número 0. El primer enrutador sustituye está etiqueta por la etiqueta 1. El último enrutador en esta ruta sustituye la etiqueta por la etiqueta con el número 4. En la respuesta se utiliza la segunda ruta. Al respecto, se dota la pila de los paquetes de datos de las correspondientes etiquetas, que son sustituidas por cada enrutador. La etiqueta que determina la ruta no se sustituye nunca, para que el receptor pueda detectar claramente quién ha enviado el paquete.
La figura 2 muestra una forma constructiva sin la etiqueta de identificación de ruta. Aquí es no obstante una premisa que cada etiqueta tenga asignada inequívocamente una ruta. Una ruta es siempre inequívoca cuando son inequívocas las identidades de origen y destino.
La figura 3 muestra el estado de la técnica, en el que la dirección IP está dispuesta en la información 14 a transportar. Si, como es usual, las etiquetas no son inequívocas, sino que determinan simplemente clases de equivalencia, entonces puede ser necesario que para una decisión de enrutado se analice la dirección de IP en la información a transportar. Este análisis puede ser muy costoso y precisa de una lógica adicional en el enrutador.
A continuación se entra en detalle en los distintos protocolos y sus modificaciones.
En redes MPLS emigra un paquete de un enrutador al siguiente. Cada enrutador toma una decisión independiente en cuanto a la retransmisión. Es decir, cada enrutador analiza la cabecera del paquete y cada enrutador recorre un programa con el algoritmo del enrutador. Cada enrutador elige una nueva ruta en función del resultado del algoritmo del enrutador. La elección de la siguiente ruta se realiza así en dos etapas. La primera etapa divide la cantidad total de los paquetes posibles en una cantidad de clases equivalentes (FEC). La segunda etapa forma cada FEC sobre una ruta. En lo que se refiere a la decisión de la transmisión, no se hace ninguna diferenciación entre los paquetes que pertenecen a la misma FEC. Paquetes distintos que pertenecen a la misma FEC no pueden diferenciarse. Como paquetes distintos se consideran los paquetes que presentan una dirección diferente de destino o de origen.
Para poder no obstante utilizar MPLS para la presente invención, debe ser inequívoca una ruta y con ello una clase de equivalencia se corresponde con una entidad inequívoca de origen y destino o bien sus direcciones. En una red MPLS se realiza la asignación a un FEC sólo una vez, precisamente cuando el paquete entra en la red. El FEC que está asignado a un paquete, es codificado como valor corto, que se denomina etiqueta. Cuando un paquete es enviado a la siguiente ruta, se envía con él la etiqueta. En los siguientes enrutadores no se realiza ningún análisis de los otros contenidos del paquete. Se comprueba solamente la etiqueta. La etiqueta se utiliza como índice para una tabla, a partir de la que pueden tomarse la siguiente ruta y la siguiente etiqueta. La etiqueta antigua es sustituida por la nueva etiqueta y el paquete se retransmite a la siguiente ruta, la etiqueta se utiliza como índice para una tabla, a partir de la que pueden deducirse la siguiente ruta y la siguiente etiqueta. La etiqueta antigua es sustituida por la nueva etiqueta y el paquete se retransmite a la siguiente ruta. En una red MPLS se controla la retransmisión sólo mediante las etiquetas. Esto tiene una serie de ventajas. Así, los enrutadores sólo necesitan tener capacidades reducidas. Los mismos deben estar simplemente en condiciones de analizar la etiqueta y comprobar en la tabla qué ruta está asignada a esta etiqueta, para sustituir la antigua etiqueta por una nueva etiqueta. Además, puede realizarse mediante estas tareas sencillas un elevado flujo. Otras ventajas pueden tomarse de la RFC 3031.
A continuación se definen algunos principios. Una etiqueta es un designador corto significativo localmente que presenta una longitud fija, para identificar un FEC. La etiqueta sirve para la representación de un FEC, al que está asignado el paquete. En la utilización básica del FEC se asigna éste a la posición básica de las direcciones de destino. No obstante, la utilización originaria del FEC no es una codificación de la dirección de la red. Precisamente en este punto hace una diferenciación la presente invención. Mediante la asociación inequívoca de la etiqueta a una ruta de la etiqueta, se logra una codificación de una dirección de la red.
Para asegurar que los enrutadores asignan los paquetes a las mismas clases de equivalencia, los enrutadores deben intercambiar regularmente informaciones de las cuales resulte claro qué paquetes se asignan a una etiqueta. Además, es importante que no se utilicen las mismas etiquetas de distintos enrutadores, siempre que esto imposibilite una identificación inequívoca del enrutador precedente. Además, señalemos que el flujo ascendente y el flujo descendente han de ser tratados de forma diferente. Así, éstos no presentan necesariamente las mismas etiquetas. En la arquitectura MPLS, la decisión de ligar una determinada etiqueta a una determinada clase de equivalencia, es tomada por el enrutador, que se encuentra flujo abajo en relación con este enlace. El enrutador que se encuentra flujo abajo informa entonces al enrutador que se encuentra flujo arriba de este enlace. Esta información puede transmitirse por ejemplo como información Huckepack (a cuestas) a otros paquetes.
En otro perfeccionamiento apoya el MPLS una jerarquía, siendo la elaboración de los paquetes dotados de las etiquetas completamente independiente del nivel de la jerarquía. Un paquete que no presenta etiqueta alguna, puede considerarse como paquete cuya pila está vacía. La utilización de la pila es clara cuando se habla de tuneleado de paquetes. Un tuneleado como el indicado puede tomarse del documento RFC 3031. Los paquetes se tunelean siempre que sean conducidos a través de una ruta de red que se encuentra entre dos enrutadores, incluyendo esta ruta de red a su vez una serie de enrutadores. Si se ha prescrito por ejemplo una ruta explicita que incluye los enrutadores R1 a R4 y se encuentra entre los enrutadores R1 y R2 una ruta que incluye los enrutadores R1.1, R1.2, R1.3, entonces se impulsa otra etiqueta a través del enrutador R1 para ponerla sobre la pila. Los enrutadores R1.1, R1.2, R1.3, funcionan ahora sobre este nuevo segundo elemento. Tan pronto como llega el paquete al enrutador R2, salta el elemento que se encuentra más arriba de la pila hacia fuera. Es problemático cuando no hay ninguna etiqueta sobre la pila. En la arquitectura MPLS normal se analiza la dirección de red (en el caso normal la dirección de IP) para determinar una clase de equivalencia. En la utilización de la presente invención no debe presentarse esta situación. MPLS ofrece dos tipos de elección de ruta. Una elección de ruta determina la ruta ya en el punto de arranque. Se determinan los distintos enrutadores que han de ser recorridos. Se trata aquí de un enrutado explicito. En el enrutado hop-by-hop (salto a salto) no se determinan los enrutadores explícitamente, con lo que cada enrutador puede determinar en base a sus tablas qué enrutador ha de ser el siguiente. La presente invención puede funcionar con ambas posibilidades de elección de ruta.
SCTP es un protocolo de transporte fiable que se construye inicialmente sobre redes de paquetes IP. En la presente forma constructiva, no se utiliza precisamente IP. De esta manera puede uno ahorrarse la capa 3 del esquema de la red.
Las ventajas del SCTP son las siguientes:
1. Transmisión libre de errores confirmada de datos de usuario sin posibilidades.
2. Fragmentación de datos en el marco MTU (Maximum Transmission Unit, unidad máxima de transmisión). Una MTU designa en una red basada en paquetes (por ejemplo TCP/IP) el tamaño del paquete que precisamente puede transmitirse aún en ese momento. TCP/IP utiliza la MTU para determinar el tamaño de un paquete en cada transmisión. Si se presenta un gran paquete - uno que el enrutador no puede transferir - se envía de retorno al correspondiente ordenador).
3. Transmisión de datos a través de varias rutas, presentando estos datos números de secuencia, para evitar una transmisión de informaciones que no se corresponda con la secuencia inicial.
4. Elevada tolerancia a los errores mediante el apoyo de entidades multihomed (multilocales) a ambos extremos de la asociación.
En la forma constructiva inicial se consideró SCTP como capa entre la aplicación de usuario y la red de paquetes sin enlace como IP. No obstante, en la presente forma la red IP es superflua. Las ventajas de ello ya se describieron anteriormente. SCTP es en su naturaleza una asociación orientada a los enlaces entre dos entidades, pero desde el punto de vista de su concepto está diseñada más amplia que TCP.
Una asociación se inicia mediante una consulta de un usuario SCTP. Un mecanismo de cookie, similar al descrito en RFC 2522, se utiliza durante la inicialización de la asociación, para asegurar la protección frente a ataques a la seguridad. Además, se realiza una finalización del enlace siempre que el usuario lo desee. Así queda excluido un estado de semiapertura, tal como es conocido por TCP. Cuando se ha cerrado el enlace no se aceptan nuevos datos.
La cantidad de flujos de datos en SCTP se determina en el instante de la inicialización del enlace. La cantidad es determinada por ambas entidades. Las informaciones que se intercambian mediante estos flujos presentan los correspondientes números. Internamente asigna SCTP a cada información o bien a cada paquete de información un número de secuencia de flujo inequívoco. Mediante la utilización de distintos flujos queda asegurado que las informaciones también se transmiten cuando uno de los flujos está bloqueado. En la presente invención los flujos corresponden a las distintas rutas de red que están caracterizadas por etiquetas. Un TSN (Transmission Sequence Number, número de secuencia de transmisión) es asignado a cada paquete. El TSN es independiente de cada número de secuencia de flujo. El receptor o bien la entidad de destino confirma la recepción de un paquete mediante un envío de retorno del TSN. De esta manera queda asegurado que todos los paquetes llegan. En el caso de que un paquete haya fallado, se envía el mismo de nuevo. Además, se determina mediante un temporizador si el paquete ha de ser enviado de nuevo. Si no se han mantenido los tiempos de respuesta, entonces se incrementa el temporizador y se envía el paquete de nuevo. El temporizador se incrementa hasta su límite superior, hasta que se recibe una respuesta al paquete. Mediante un campo de comprobación, se comprueba la consistencia del paquete.
A continuación se describe el establecimiento de un enlace y se hace una indicación respecto a cómo se distingue el SCTP conocido del protocolo modificado correspondiente a la invención. Antes de que pueda realizarse una primera transmisión de datos entre dos entidades SCTP (A y Z), debe realizarse un proceso de inicialización completo, en el que se genere una asociación SCTP.
Una vez que se ha constituido una asociación, pueden transmitirse flujos de datos unidireccionales a través de las rutas. El proceso de inicialización está compuesto por las siguientes etapas. La entidad A envía primeramente un paquete de inicialización a la entidad Z. Este paquete de inicialización contiene un tag de comprobación en el campo correspondiente (Tag-A). El tag es el correspondiente número aleatorio. Una vez se ha enviado este paquete de inicialización, se arranca un temporizador. La entidad A se traslada a un estado de espera de cookie. La entidad Z tiene aquí que contestar inmediatamente con un paquete de respuesta de inicialización. En lugar de las direcciones de IP, se intercambian ahora etiquetas o bien etiquetas ID de ruta. Las etiquetas ID de ruta se intercambian siempre que la ruta descrita por la etiqueta no es inequívoca. Una ruta no es inequívoca siempre que en el último enrutador no pueda determinarse inequívocamente la entidad de destino. Este es siempre el caso cuando la clase de equivalencia de la última etiqueta no es inequívoca, es decir, biyectiva. La entidad Z debe enviar ahora el campo de comprobación Tag-A y Tag-Z, así como un cookie cómo confirmación. Tras recibir esta confirmación, se detiene el temporizador de la entidad A. Igualmente se modifica el estado. Se envía a continuación una respuesta de un cookie a la entidad Z, que comunica que el cookie se ha recibido. A continuación se inicia de nuevo un temporizador de la entidad A. Este temporizador se detiene una vez que la entidad Z ha confirmado la recepción de la respuesta al cookie. Una interrupción del enlace ha de comunicarse siempre a la correspondiente entidad. Una vez que el enlace o bien la asociación se ha establecido de tal manera, se intercambian los datos a través de las rutas. Para la vigilancia de los enlaces, se transmiten regularmente informaciones de prueba. De esta manera puede determinarse el estado del enlace.
Otros detalles pueden tomarse de la RFC 2960.

Claims (10)

1. Procedimiento para la transmisión de informaciones (14) a través de una red entre dos entidades (11),
con un primer protocolo, que es MPLS y que utiliza para la transmisión de informaciones (14) entre dos entidades (11) rutas de red, caracterizadas por etiquetas que sirven en cada caso para representar una FEC (= Forward Equivalence Class, clase de equivalencia de retransmisión) en MPLS, estando determinadas inequívocamente una entidad de destino (11) y una entidad de origen (11) de las rutas de red con una etiqueta, y estando asignada la etiqueta inequívocamente a una ruta de red,
con un segundo protocolo de transporte que se construye sobre el primer protocolo, asegurando el protocolo de transporte la recepción de una información (14) mediante una información de confirmación,
con una primera etapa de inicialización (Init), en la que a través de una primera ruta de red se intercambian 1 a n etiquetas de rutas de red, que permiten un intercambio de informaciones entre las entidades (11),
con una segunda etapa de intercambio de informaciones, en la que se intercambian las informaciones (14) a través de las 1 a n rutas de red.
2. Procedimiento según una o varias de las reivindicaciones precedentes, donde el segundo protocolo de transporte es un SCTP, siendo sustituidas las direcciones de IP por las etiquetas (13) de las rutas de red.
3. Procedimiento para la transmisión de informaciones a través de una red entre dos entidades (11),
con un primer protocolo, que es MPLS y que utiliza para la transmisión de informaciones (14) entre dos entidades (11) rutas de red, caracterizadas por etiquetas (13) que sirven en cada caso para representar una FEC (= Forward Equivalence Class, clase de equivalencia de retransmisión) en MPLS, estando determinadas inequívocamente una entidad de destino (11) y una entidad de origen (11) mediante otra etiqueta de identificación de ruta (13) y estando asignada inequívocamente la etiqueta de identificación de ruta (13) a una ruta de red,
con un segundo protocolo de transporte que se construye sobre el primer protocolo, asegurando el protocolo de transporte la recepción de una información (14) mediante una información de confirmación,
con una primera etapa de inicialización (Init), en la que a través de una primera ruta de red se intercambian 1 a n etiquetas de rutas de red, que permiten un intercambio de informaciones entre las entidades (11), no sustituyéndose nunca la etiqueta de identificación de ruta (13).
4. Procedimiento según la reivindicación 3, donde el segundo protocolo de transporte es un SCTP, siendo sustituidas las direcciones de IP por las etiquetas de identificación de rutas (13) de las rutas de red.
5. Procedimiento según una o varias de las reivindicaciones precedentes, utilizándose para asegurar la transmisión de informaciones métodos del SCTP, en particular numeración de las informaciones parciales, TSN, RTO y/o RTT.
6. Procedimiento según una o varias de las reivindicaciones precedentes, inicializándose las rutas de red antes de establecerse la comunicación entre las entidades (11), utilizándose para la ingeniería de tráfico procedimientos que trabajan preferentemente con direcciones de IP y en los cuales los enrutadores/conmutadores se configuran de tal manera que para una ruta las entidades de destino y de origen (11) están determinadas inequívocamente.
7. Procedimiento según una o varias de las reivindicaciones precedentes, utilizándose en función del flujo y/o del tiempo de respuesta distintas rutas de red en la transmisión de informaciones (14).
8. Procedimiento según una o varias de las reivindicaciones precedentes, utilizándose en el protocolo MPLS un apilamiento de etiquetas.
9. Procedimiento según una o varias de las reivindicaciones precedentes, utilizándose las rutas de red solamente para un intercambio de informaciones unidireccional.
10. Dispositivo para el intercambio de informaciones a través de una red,
caracterizado porque el dispositivo dispone de medios para realizar un procedimiento según una o varias de las reivindicaciones precedentes.
ES02754294T 2001-07-10 2002-07-01 Procedimiento para la utilizacion de sctp (stream control transmission protocol, protocolo de transmision con control del flujo) en redes mpls (multi procol label switching,conmutacion de etiquetas multiprotocolo). Expired - Lifetime ES2268066T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10133473A DE10133473C1 (de) 2001-07-10 2001-07-10 Verfahren zur optimierten Nutzung von SCTP (Stream Control Transmission Protocol) in MPLS (Multi Protocol Label Switching) Netzen
DE10133473 2001-07-10

Publications (1)

Publication Number Publication Date
ES2268066T3 true ES2268066T3 (es) 2007-03-16

Family

ID=7691271

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02754294T Expired - Lifetime ES2268066T3 (es) 2001-07-10 2002-07-01 Procedimiento para la utilizacion de sctp (stream control transmission protocol, protocolo de transmision con control del flujo) en redes mpls (multi procol label switching,conmutacion de etiquetas multiprotocolo).

Country Status (8)

Country Link
US (1) US20040243670A1 (es)
EP (1) EP1405422B1 (es)
JP (1) JP4008879B2 (es)
KR (1) KR20030059129A (es)
CN (1) CN1554169A (es)
DE (2) DE10133473C1 (es)
ES (1) ES2268066T3 (es)
WO (1) WO2003007484A2 (es)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6360100B1 (en) 1998-09-22 2002-03-19 Qualcomm Incorporated Method for robust handoff in wireless communication system
US7668541B2 (en) 2003-01-31 2010-02-23 Qualcomm Incorporated Enhanced techniques for using core based nodes for state transfer
US6862446B2 (en) 2003-01-31 2005-03-01 Flarion Technologies, Inc. Methods and apparatus for the utilization of core based nodes for state transfer
JP4587446B2 (ja) 2003-08-07 2010-11-24 キヤノン株式会社 ネットワークシステム、並びにスイッチ装置及び経路管理サーバ及びそれらの制御方法、及び、コンピュータプログラム及びコンピュータ可読記憶媒体
DE10339280B4 (de) * 2003-08-26 2006-09-07 Siemens Ag Auswahlverfahren für Nachrichtenpfade in Kommunikationssystemen
US20050169169A1 (en) * 2004-01-30 2005-08-04 Srinivas Gadde Determination of an endpoint association from a transport address
US8509799B2 (en) 2005-09-19 2013-08-13 Qualcomm Incorporated Provision of QoS treatment based upon multiple requests
US9066344B2 (en) 2005-09-19 2015-06-23 Qualcomm Incorporated State synchronization of access routers
WO2007035793A1 (en) * 2005-09-19 2007-03-29 Qualcomm Incorporated State synchronization of access routers
US9736752B2 (en) 2005-12-22 2017-08-15 Qualcomm Incorporated Communications methods and apparatus using physical attachment point identifiers which support dual communications links
US8982835B2 (en) 2005-09-19 2015-03-17 Qualcomm Incorporated Provision of a move indication to a resource requester
US9078084B2 (en) 2005-12-22 2015-07-07 Qualcomm Incorporated Method and apparatus for end node assisted neighbor discovery
US8982778B2 (en) 2005-09-19 2015-03-17 Qualcomm Incorporated Packet routing in a wireless communications environment
US8983468B2 (en) 2005-12-22 2015-03-17 Qualcomm Incorporated Communications methods and apparatus using physical attachment point identifiers
US9083355B2 (en) 2006-02-24 2015-07-14 Qualcomm Incorporated Method and apparatus for end node assisted neighbor discovery
EP1830523A1 (en) * 2006-03-02 2007-09-05 BRITISH TELECOMMUNICATIONS public limited company Multi-protocol label switching
US7616643B2 (en) 2006-04-19 2009-11-10 Cisco Technology, Inc. Techniques for integrated routing of call circuit signaling and the internet protocol
US9155008B2 (en) 2007-03-26 2015-10-06 Qualcomm Incorporated Apparatus and method of performing a handoff in a communication network
US8830818B2 (en) 2007-06-07 2014-09-09 Qualcomm Incorporated Forward handover under radio link failure
US9094173B2 (en) 2007-06-25 2015-07-28 Qualcomm Incorporated Recovery from handoff error due to false detection of handoff completion signal at access terminal
JP5246271B2 (ja) 2009-01-19 2013-07-24 日本電気株式会社 Sctp通信方法、sctp通信システムおよびノード
JP5451260B2 (ja) * 2009-08-28 2014-03-26 キヤノン株式会社 制御装置、制御システム及びコマンド送信方法ならびにプログラム
US8615241B2 (en) 2010-04-09 2013-12-24 Qualcomm Incorporated Methods and apparatus for facilitating robust forward handover in long term evolution (LTE) communication systems
EP2381621A1 (en) * 2010-04-21 2011-10-26 Thomson Licensing Method for evaluating an available path bitrate based on an acknowledgment path selection
EP2672671A1 (en) 2012-06-04 2013-12-11 Thomson Licensing Data transmission using a multihoming protocol such as SCTP
US10389618B2 (en) * 2017-01-23 2019-08-20 Cisco Technology, Inc. Distributing network path information in a network environment

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0530394B1 (en) * 1991-09-03 1996-11-13 Hewlett-Packard Company Message-routing apparatus
SE515465C2 (sv) * 1998-12-15 2001-08-13 Telia Ab Förbättringar inom, eller hänförande sig till, dataöverföringssystem
EP1201061B1 (en) * 1999-06-07 2005-08-17 Nortel Networks Limited System and method for loop avoidance in multi-protocol label switching
CA2319944A1 (en) * 1999-09-21 2001-03-21 Alcatel Usa Sourcing Lp System and method for transporting in/ain signaling over an internet protocol (ip) network
US7600039B2 (en) * 2000-02-16 2009-10-06 Motorola, Inc. Label-based multiplexing
US7099327B1 (en) * 2000-10-12 2006-08-29 Lucent Technologies Inc. Data communications networks with high performance and reliability
US7082102B1 (en) * 2000-10-19 2006-07-25 Bellsouth Intellectual Property Corp. Systems and methods for policy-enabled communications networks
US7099334B2 (en) * 2001-03-29 2006-08-29 Nortel Networks Limited ATM over MPLS connection establishment mechanism
US7542419B2 (en) * 2001-04-02 2009-06-02 International Business Machines Corporation Method and apparatus for managing aggregate bandwidth at a server
US7298700B1 (en) * 2001-05-24 2007-11-20 At&T Corp. Method for unidirectional and bidirectional label switched path setup in a label switched network

Also Published As

Publication number Publication date
JP2004535133A (ja) 2004-11-18
DE10133473C1 (de) 2003-02-20
DE50208079D1 (de) 2006-10-19
EP1405422A2 (de) 2004-04-07
CN1554169A (zh) 2004-12-08
WO2003007484A2 (de) 2003-01-23
EP1405422B1 (de) 2006-09-06
WO2003007484A3 (de) 2003-05-30
JP4008879B2 (ja) 2007-11-14
KR20030059129A (ko) 2003-07-07
US20040243670A1 (en) 2004-12-02

Similar Documents

Publication Publication Date Title
ES2268066T3 (es) Procedimiento para la utilizacion de sctp (stream control transmission protocol, protocolo de transmision con control del flujo) en redes mpls (multi procol label switching,conmutacion de etiquetas multiprotocolo).
AU717590B2 (en) Method and apparatus for enabling flow control over multiple networks having disparate flow control capability
US6501754B1 (en) Scheme for label switched path loop detection at node device
US7225259B2 (en) Service tunnel over a connectionless network
US6055561A (en) Mapping of routing traffic to switching networks
US7443845B2 (en) Apparatus and method for a lightweight, reliable, packet-based transport protocol
US6967927B1 (en) Method of transmitting data flows over an ATM network and device for implementing the method
CN1337130A (zh) 电信系统中的流量控制方法
Nagami et al. Toshiba's Flow Attribute Notification Protocol (FANP) Specification
ES2233866T3 (es) Procedimiento y dispositivo para la comprension de la cabecera en redes orientadas a paquetes.
ES2372278T3 (es) Aparato de transmisión multiplex y procedimiento de transmisión multiplex.
US7639692B2 (en) Unified inverse address resolution
KR100776084B1 (ko) 티씨피/아이피 프로토콜 계층 2에서 리라이어블 서비스제공장치 및 그 방법
ES2640982T3 (es) Método de configuración de red
ES2239129T3 (es) Procedimiento y sistema para transmitir un paquete de datos desde una primera unidad de conmutacion a una segunda unidad de conmutacion en una red de datos.
Cisco X.25 and LAPB Commands
SE518422C2 (sv) Förfarande och anordning för punkt-till-punktförbindelser i ett kommunikationsnät
Widjaja et al. Exploiting parallelism to boost data-path rate in high-speed IP/MPLS networking
CA2412914A1 (en) Offering differentiated services
Heinänen Review of backbone technologies
Bai et al. RSTP: a new lightweight transport protocol for VoIP
Nagami et al. RFC2129: Toshiba's Flow Attribute Notification Protocol (FANP) Specification
KUMAR et al. Efficient Bandwidth Utilization for Optical Switching in WDM Networks
Matsuzawa et al. Network Working Group K. Nagami Request for Comments: 2129 Y. Katsube Category: Informational Y. Shobatake A. Mogi
AlWehaibi et al. Hybrid FEC/ARQ delay for DiffServ over IP and MPLS multicast networks