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 PDFInfo
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims description 27
- 238000000034 method Methods 0.000 title claims description 26
- DYWNLSQWJMTVGJ-UHFFFAOYSA-N (1-hydroxy-1-phenylpropan-2-yl)azanium;chloride Chemical compound Cl.CC(N)C(O)C1=CC=CC=C1 DYWNLSQWJMTVGJ-UHFFFAOYSA-N 0.000 title 1
- 230000004044 response Effects 0.000 claims description 10
- 238000004891 communication Methods 0.000 claims description 6
- 238000012790 confirmation Methods 0.000 claims description 6
- 235000014510 cooky Nutrition 0.000 description 6
- 230000004069 differentiation Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 239000007943 implant Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing 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.
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)
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)
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 |
-
2001
- 2001-07-10 DE DE10133473A patent/DE10133473C1/de not_active Expired - Fee Related
-
2002
- 2002-07-01 ES ES02754294T patent/ES2268066T3/es not_active Expired - Lifetime
- 2002-07-01 DE DE50208079T patent/DE50208079D1/de not_active Expired - Lifetime
- 2002-07-01 KR KR10-2003-7003429A patent/KR20030059129A/ko not_active Application Discontinuation
- 2002-07-01 US US10/483,339 patent/US20040243670A1/en not_active Abandoned
- 2002-07-01 JP JP2003513134A patent/JP4008879B2/ja not_active Expired - Fee Related
- 2002-07-01 WO PCT/DE2002/002381 patent/WO2003007484A2/de active IP Right Grant
- 2002-07-01 EP EP02754294A patent/EP1405422B1/de not_active Expired - Lifetime
- 2002-07-01 CN CNA02817688XA patent/CN1554169A/zh active Pending
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 |