ES2269828T3 - Metodo para evitar una oscilacion de actualizacion de red. - Google Patents
Metodo para evitar una oscilacion de actualizacion de red. Download PDFInfo
- Publication number
- ES2269828T3 ES2269828T3 ES02805853T ES02805853T ES2269828T3 ES 2269828 T3 ES2269828 T3 ES 2269828T3 ES 02805853 T ES02805853 T ES 02805853T ES 02805853 T ES02805853 T ES 02805853T ES 2269828 T3 ES2269828 T3 ES 2269828T3
- Authority
- ES
- Spain
- Prior art keywords
- update
- network update
- port
- message
- bus
- 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
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]
- H04L12/40—Bus networks
-
- 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]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40091—Bus bridging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- 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
- H04L45/18—Loop-free operations
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Information Transfer Systems (AREA)
- Bidet-Like Cleaning Device And Other Flush Toilet Accessories (AREA)
- Diaphragms For Electromechanical Transducers (AREA)
- Oscillators With Electromechanical Resonators (AREA)
Abstract
Método para evitar una oscilación de actualización de red de un puente de bus debida a mensajes de actualización de red que compiten, que comprende: recibir en un primer puerto de dicho puente de bus un primer mensaje de actualización de red desde un primer coordinador en un primer bus; y si dicho puente de bus recibe en un segundo puerto del puente de bus un segundo mensaje de actualización de red desde un segundo coordinador en un segundo bus antes de que se haya procesado dicho primer mensaje de actualización de red por parte de dicho primer puerto de dicho puente de bus, entonces: seleccionar y procesar por el puente uno de los mensajes de actualización de red primero y segundo como mensaje de actualización de red superviviente, desechar el otro de los mensajes de actualización primero y segundo; y actualizar la información de clan de modo que el primer y segundo puerto contenga información de clan del mensaje de actualización de red superviviente; definiéndose un clan como un grupo depuertos de puente afiliados que presentan filiación al mismo puerto principal, siendo un puerto principal un puerto singular dentro de una red de buses interconectados.
Description
Método para evitar una oscilación de
actualización de red.
La presente invención se refiere a un bus en
serie puenteado. Más particularmente, la presente invención se
refiere a problemas de oscilación de actualización de red en puentes
de bus en serie tales como el IEEE 1394.
Una red se refiere a un grupo de buses que se
interconectan mediante puentes. Según la definición de IEEE, un
puente implementa dos puertos y reenvía subacciones asincrónicas, y
también puede reenviar subacciones asincrónicas según la
información de ruta que está almacenada. Cada bus que forma parte de
una red tiene un identificador individual que es único si la red es
estable y está configurada de manera apropiada. En particular, en
una red IEEE 1394, puede haber hasta 1.023 buses lógicos y hasta 63
nodos en cada bus. Se permite la interconexión de bucle de manera
física entre los buses dentro de una red. Sin embargo,
el(los) bucle(s), si existe, se eliminará mediante el
silenciamiento de al menos un puente por bucle según el borrador de
la norma IEEE 1394 sobre puentes. Cuando dos o más redes puenteadas
están conectadas, se requiere un procedimiento de actualización de
red.
El documento EP 1058427 describe la
determinación de una tabla de encaminamiento en una red que
comprende buses en serie IEEE 1394 conectados mediante puentes.
Cada puente comprende dos puertos auxiliares. Estando conectado un
primer puerto a un primer bus y estando conectado un segundo puerto
a un segundo bus. Cada bus se identifica mediante un identificador
de bus único y cada puerto se identifica mediante un identificador
de puerto único.
Según el borrador de la norma IEEE1394.1 sobre
puentes, versión 1.00, un puerto principal se define como un puerto
singular dentro de una red de buses interconectados y un clan se
define como un grupo de puertos de puente afiliados que presentan
filiación al mismo puerto principal. Cuando se conectan dos redes,
es posible que los puertos de puente del mismo bus pertenezcan a
diferentes clanes. Sin embargo, esto es una condición temporal que
se resuelve mediante procedimientos de actualización de red.
Cuando un coordinador en un bus encuentra
puertos que pertenecen a diferentes clanes, el coordinador
seleccionará un puerto principal y actualizará la información de
encaminamiento de paquetes según el borrador de la norma IEEE
1394.1 sobre puentes. Entonces, el coordinador enviará un mensaje de
ACTUALIZAR_RUTA a cada puerto en su bus local con el fin de
actualizar la información de encaminamiento de paquetes y la
afinidad de clan de cada puerto.
Si se inicia un nuevo proceso de actualización
mientras que se está(n) procesando otra(s)
actualización(-ones) de red, estos procesos de actualización de red
se combinarán en uno. De lo contrario, una red no puede configurarse
de manera apropiada. Según el borrador de la norma IEEE 1394.1
sobre puentes, versión 1.0, únicamente un coordinador puede
detectar conflictos de actualización de red e iniciar nuevos
procesos de actualización tras seleccionar un puerto principal
superviviente y actualizar la información de encaminamiento de
paquetes.
Sin embargo, surge un problema porque si un
puente observa un proceso de actualización de red en un puerto
mientras que está procesando otra actualización de red recibida en
el otro puerto, pueden hacerse pasar a través del puente dos
mensajes de ACTUALIZAR_RUTA diferentes relacionados con dos
actualizaciones de red diferentes sin combinarse en uno. Entonces,
ambos puertos puente se actualizan con los mensajes de
ACTUALIZAR_RUTA intercambiados, y entonces inician
reinicializaciones de bus en sus buses locales.
Como resultado, cada coordinador en cada bus
observa un nuevo conflicto de actualización de red diferente.
Entonces, dos coordinadores pueden enviar mensajes de
ACTUALIZAR_RUTA diferentes a cada puerto en su bus local respectivo
debido a los conflictos de actualización de red diferentes. Si esto
ocurre, de nuevo el mismo puente observará un proceso de
actualización de red en un puerto mientras que procesa otra
actualización de red recibida en el otro puerto. Esto podría dar
como resultado un problema de fluctuaciones de actualización de red
infinitas.
Por ejemplo, la figura 1 ilustra un diagrama de
flujo en el tiempo de un ejemplo en el que un puente recibe dos
mensajes de ACTUALIZAR_RUTA en sus dos buses locales y los dos
mensajes de ACTUALIZAR_RUTA pasarán y se reenviarán a otros
buses.
Un proceso de actualización de red comienza
cuando un puente recibe un mensaje de actualización de red desde un
puerto. Normalmente, después de que un coordinador (es decir, el
puerto del puente encargado de las actualizaciones de red) reciba
una mensaje de actualización de red, se actualiza la información de
clan del puente, y el proceso finaliza con el inicio de una
reinicialización de bus en el otro bus del puerto.
El coordinador (no mostrado) en el primer bus A
(no mostrado) envía un mensaje de actualización de red, que el bus
A recibe en el punto 120. Aproximadamente al mismo tiempo 130, el
coordinador (no mostrado) en el bus B envía una actualización de
red al bus B. Por tanto, existe un "cruce" de mensajes de
actualización entre el inicio desde un bus hasta la
reinicialización en el otro bus, en la trama de tiempo denominada
como periodo de actualización de red (el periodo desde 130 hasta
140).
Cuando el bus A recibe la información de clan,
que incluye información de reinicialización desde el bus B, éste
actualiza su información de clan y se inicia una
reinicialización.
Así, los coordinadores respectivos para A y B
seguirán detectando una "competición" con respecto a la
información de clan del puente y ambos volverán a llevar a cabo
actualizaciones de red.
A continuación, los dos coordinadores iniciarán
de nuevo diferentes procesos de actualización. El puente puede
recibir de nuevo dos mensajes de actualización de red diferentes en
ambos puertos mediante el cruce en 150. El resultado puede ser un
bucle de actualización de red infinita. En otras palabras, el puente
recibe continuamente dos mensajes de actualización de red en ambos
puertos y los reenvía a los buses infinitamente. En tal situación,
la configuración de red nunca finaliza. Este bucle se denomina como
oscilación de actualización de red.
Según un aspecto de la presente invención, un
método para evitar la oscilación de actualización de red incluye
que el puente seleccione únicamente uno de los dos mensajes de
ACTUALIZAR_RUTA, cada uno de los cuales se crea por cada uno de los
puertos por sí mismos si el puerto es un coordinador en su bus
local, que lo contrario se enviaría por un coordinador local del
puerto y se recibiría por el puerto. A continuación, el puente
desecha el otro mensaje de ACTUALIZAR_RUTA, de modo que no puede
ocurrir una oscilación de actualización de red infinita. El mensaje
de ACTUALIZAR_RUTA seleccionado, que se denomina como mensaje de
ACTUALIZAR_RUTA superviviente, se procesará por el puente según el
borrador de la norma IEEE 1394.1 sobre puentes, por lo tanto el
puerto que recibió el mensaje de ACTUALIZAR_RUTA superviviente
inicia una reinicialización de bus como un inicio de un evento de
red, mientras que el otro puerto no lo hace. Entonces, un
coordinador (que podría ser el puerto) tras la reinicialización del
bus encontrará el conflicto del proceso de actualización de red y
resolverá el asunto según el borrador de la norma IEEE 1394.1 sobre
puentes.
Puesto que se ha rechazado uno de los eventos de
actualización de red observados por el puente y únicamente se
procesará un evento de actualización de red, los eventos de
actualización de red no pueden pasar a través de un puente. Esto
puede evitar el problema de oscilación de red explicado
anteriormente.
En un primer aspecto de la invención, un método
para evitar una oscilación de actualización de red de un puente de
bus debida a mensajes de actualización de red que compiten,
comprende las etapas de:
(a) determinar si un puerto en particular es un
coordinador en su bus local; y proceder a la etapa (b) (i) si dicho
puerto en particular es un coordinador, de lo contrario, proceder a
la etapa (b) (ii);
(b) (i) determinar si dicho puerto en particular
encuentra un conflicto de actualización de red en su bus local; y
proceder a la etapa (c) si se encontrara el conflicto de
actualización de red;
(b) (ii) determinar si el puerto en particular
recibe un mensaje de ACTUALIZAR_RUTA desde otro puerto que es un
coordinador en el bus local; y proceder a la etapa (c) si se recibe
el mensaje de ACTUALIZAR_RUTA;
(c) establecer un bit de actualización de red
global a uno mediante un procedimiento de bloqueo;
(d) verificar si el procedimiento de bloqueo en
la etapa (c) se ha llevado a cabo satisfactoriamente determinando
si el bit de actualización de red se ha establecido a uno;
(e) llevar a cabo uno de:
- (i)
- desechar la actualización de red si se ha determinado en la etapa (d) que el procedimiento de bloqueo en la etapa (c) no se ha llevado a cabo satisfactoriamente; y
- (ii)
- procesar la actualización de red según la norma IEEE 1394.1 sobre puentes y establecer el bit de actualización de red a cero, si se ha determinado en la etapa (d) que el procedimiento de bloqueo en la etapa (c) se ha llevado a cabo satisfactoriamente.
\vskip1.000000\baselineskip
En otro aspecto de la invención, un método para
evitar la oscilación de actualización de red comprende:
(a) recibir en un primer puerto del puente de
bus un primer mensaje de actualización de red desde un primer
coordinador en un primer bus;
(b) recibir en un segundo puerto del puente de
bus un segundo mensaje de actualización de red desde un segundo
coordinador en un segundo bus antes de que se haya procesado dicho
primer mensaje de actualización por parte de dicho primer puerto de
dicho puente de bus;
(c) seleccionar y procesar por parte del puente
uno de los mensajes de actualización de red primero y segundo como
mensaje de actualización de red superviviente, y desechar el otro de
los mensajes de actualización primero y segundo; y
(d) actualizar la información de clan de modo
que tanto el primer como segundo puerto contengan información de
clan del mensaje de actualización de red superviviente.
\newpage
La figura 1 es un diagrama de flujo en el tiempo
que muestra cómo en la técnica anterior puede ocurrir una
oscilación de actualización de red infinita.
La figura 2 es un diagrama de flujo de un método
de la presente invención para evitar la oscilación de actualización
de red.
Con respecto a cómo el puente selecciona el
mensaje de ACTUALIZAR_RUTA superviviente recibido por un puerto y
desecha el otro recibido, los siguientes ejemplos únicamente tienen
fines explicativos y no limitan la invención reivindicada
únicamente a estos criterios para seleccionar un mensaje
superviviente y desechar un mensaje víctima.
(1) En primer lugar; el puente mantiene
el primer mensaje de actualización de red recibido en un bus y
desecha el segundo mensaje;
(2) Prioridad de CPU, una CPU; el mensaje
encontrado en primer lugar por la CPU se mantiene y el otro mensaje
se desecha; o
(3) Prioridad de CPU, múltiples CPUs; la
primera CPU que notifica una detección de evento de actualización
de red a la otra CPU lo procesa, mientras que la otra CPU que
detecta eventos de actualización de red posteriores antes de que el
primer evento de actualización de red finalice ignorará los eventos
de actualización de red; o
(4) Configuración de puertos; un puerto
en un puente puede designarse como el superviviente y el otro como
la víctima. Si cada puerto del puente recibe un mensaje de
ACTUALIZAR_RUTA o encuentra un evento de actualización de red y a
continuación crea un mensaje de ACTUALIZAR_RUTA como un coordinador,
se desecha el mensaje de ACTUALIZAR_RUTA del puerto víctima y se
procesa el otro mensaje de ACTUALIZAR_RUTA del puerto superviviente;
o
(5) Uso de los mismos criterios de selección
principal especificados por el borrador de la norma IEEE 1394.1;
pero en este caso el puente puede que no edite ningún mensaje de
actualización. El puente mantendrá y procesará el mensaje de
ACTUALIZAR_RUTA correspondiente al mensaje principal superviviente
seleccionado según el borrador de la norma IEEE 1394.1 sobre
puentes, y desechará el otro mensaje de ACTUALIZAR_RUTA.
La figura 2 muestra un diagrama de flujo que
proporciona un ejemplo de maneras de implementar la invención para
un puente que comprende al menos dos puertos. Un puente que
implementa el procedimiento descrito por el siguiente diagrama de
flujo implementará un bit global compartido por los puertos. El bit
global puede implementarse bien en software o bien en hardware, y
con fines explicativos se denomina bit de actualización de red. Un
procedimiento de bloqueo bien conocido se usa para establecer el bit
de actualización de red a uno. El bit de actualización de red puede
ponerse a cero por un puerto que lo ha establecido a uno. El valor
inicial del bit de actualización de red deberá ser cero.
En la etapa 200, si un puerto es un coordinador
en su bus local, la etapa 210 se procesará a continuación, por el
contrario, si el puerto no es un coordinador en su bus local, a
continuación se ejecutará la etapa 220.
En la etapa 210, si el puerto encuentra un
conflicto de actualización de red en el bus local según el borrador
de la norma IEEE 1394.1 sobre puentes, a continuación se llevará a
cabo la etapa 230. De lo contrario, a continuación se procesará la
etapa 200.
En la etapa 220, si el puerto recibe un mensaje
de ACTUALIZAR_RUTA desde su coordinador en el bus local, a
continuación se llevará a cabo la etapa 230. De lo contrario, a
continuación se procesará la etapa 200.
En la etapa 230, el bit de actualización de red
global se establece a uno mediante un procedimiento de bloqueo bien
conocido. Por ejemplo, en la etapa 231, si el bit de actualización
de red identifica uno, el bloqueo falla. Por el contrario, si el
bit de actualización de red es cero, en la etapa 232 el bit de
actualización de red global se establece a uno y el bloqueo es
satisfactorio. Si el bloqueo de la etapa 230 falla, a continuación
se procesará la etapa 260. Por el contrario, si el bloqueo de la
etapa 230 es satisfactorio, a continuación se procesará la etapa
240.
En la etapa 240, se procesa la actualización de
red por el puerto según el borrador de la norma IEEE 1394.1 sobre
puentes. A continuación se procesará la etapa 250.
En la etapa 250, el puerto pone a cero el bit de
actualización de red.
En la etapa 260, el puerto rechaza el evento de
actualización de red. Para este caso, otro puerto ha estado
procesando otra actualización de red, encontrada en el otro bus
local del puerto.
Como resultado de la etapa 260, el puente
desecha todos menos uno de los eventos de actualización de red que
se producen de manera concurrente y puede evitarse un posible
problema de oscilación de actualización de red.
En todo lo anterior puede usarse un bus IEEE
1394 o un equivalente del mismo, pero la invención no se limita
expresamente al IEEE 1394 y puede usarse en cualquier puente de bus
en serie.
Claims (7)
1. Método para evitar una oscilación de
actualización de red de un puente de bus debida a mensajes de
actualización de red que compiten, que comprende:
recibir en un primer puerto de dicho puente de
bus un primer mensaje de actualización de red desde un primer
coordinador en un primer bus; y si dicho puente de bus recibe en un
segundo puerto del puente de bus un segundo mensaje de
actualización de red desde un segundo coordinador en un segundo bus
antes de que se haya procesado dicho primer mensaje de
actualización de red por parte de dicho primer puerto de dicho
puente de bus, entonces:
seleccionar y procesar por el puente uno de los
mensajes de actualización de red primero y segundo como mensaje de
actualización de red superviviente,
desechar el otro de los mensajes de
actualización primero y segundo; y
actualizar la información de clan de modo que el
primer y segundo puerto contenga información de clan del mensaje de
actualización de red superviviente; definiéndose un clan como un
grupo de puertos de puente afiliados que presentan filiación al
mismo puerto principal, siendo un puerto principal un puerto
singular dentro de una red de buses interconectados.
2. Método según la reivindicación 1, que
comprende además iniciar una reinicialización de uno del primer bus
y el segundo bus que tenía un mensaje de actualización de red
desechado.
3. Método según la reivindicación 2, que
comprende además iniciar una reinicialización del bus del que se ha
seleccionado el mensaje de actualización de red superviviente.
4. Método según la reivindicación 1, en el que
el mensaje de actualización de red recibido en primer lugar se
selecciona como el mensaje de actualización de red
superviviente.
5. Método según la reivindicación 1, en el que
el puente comprende una Unidad de Procesamiento Central (CPU) y el
mensaje de actualización de red encontrado primero por la Unidad de
Procesamiento Central se selecciona como el mensaje de
actualización de red superviviente.
6. Método según la reivindicación 1, en el que
el puente comprende una configuración de Unidad de Procesamiento
Central múltiple, y el mensaje de actualización de red que una
Unidad de Procesamiento Central notifica en primer lugar a al menos
otra Unidad de Procesamiento Central de la configuración de Unidad
de Procesamiento Central múltiple se selecciona como el mensaje de
actualización de red superviviente.
7. Método según la reivindicación 1, en el que
una configuración del primer puerto y del segundo puerto del puente
designa uno de entre el primer puerto y el segundo puerto para
seleccionar su mensaje de actualización de red para designarse como
el mensaje de actualización de red superviviente.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US29824 | 2001-12-27 | ||
US10/029,824 US6898658B2 (en) | 2001-12-27 | 2001-12-27 | Method to prevent net update oscillation |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2269828T3 true ES2269828T3 (es) | 2007-04-01 |
Family
ID=21851081
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES02805853T Expired - Lifetime ES2269828T3 (es) | 2001-12-27 | 2002-12-09 | Metodo para evitar una oscilacion de actualizacion de red. |
Country Status (10)
Country | Link |
---|---|
US (1) | US6898658B2 (es) |
EP (1) | EP1461922B1 (es) |
JP (1) | JP2005513961A (es) |
KR (1) | KR20040086254A (es) |
CN (1) | CN1611039A (es) |
AT (1) | ATE337663T1 (es) |
AU (1) | AU2002367217A1 (es) |
DE (1) | DE60214238T2 (es) |
ES (1) | ES2269828T3 (es) |
WO (1) | WO2003056769A1 (es) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100421482C (zh) * | 2005-07-15 | 2008-09-24 | 华为技术有限公司 | 一种更新A2p接口承载参数的方法 |
CN100466809C (zh) * | 2005-09-22 | 2009-03-04 | 华为技术有限公司 | 一种更新承载参数的控制方法和*** |
US7818432B2 (en) | 2005-12-08 | 2010-10-19 | International Business Machines Corporation | Seamless reflection of model updates in a visual page for a visual channel in a composite services delivery system |
US8189563B2 (en) | 2005-12-08 | 2012-05-29 | International Business Machines Corporation | View coordination for callers in a composite services enablement environment |
US7809838B2 (en) | 2005-12-08 | 2010-10-05 | International Business Machines Corporation | Managing concurrent data updates in a composite services delivery system |
US20070133773A1 (en) * | 2005-12-08 | 2007-06-14 | International Business Machines Corporation | Composite services delivery |
US7877486B2 (en) | 2005-12-08 | 2011-01-25 | International Business Machines Corporation | Auto-establishment of a voice channel of access to a session for a composite service from a visual channel of access to the session for the composite service |
US10332071B2 (en) | 2005-12-08 | 2019-06-25 | International Business Machines Corporation | Solution for adding context to a text exchange modality during interactions with a composite services application |
US11093898B2 (en) | 2005-12-08 | 2021-08-17 | International Business Machines Corporation | Solution for adding context to a text exchange modality during interactions with a composite services application |
US7890635B2 (en) | 2005-12-08 | 2011-02-15 | International Business Machines Corporation | Selective view synchronization for composite services delivery |
US8005934B2 (en) | 2005-12-08 | 2011-08-23 | International Business Machines Corporation | Channel presence in a composite services enablement environment |
US7792971B2 (en) | 2005-12-08 | 2010-09-07 | International Business Machines Corporation | Visual channel refresh rate control for composite services delivery |
US7827288B2 (en) | 2005-12-08 | 2010-11-02 | International Business Machines Corporation | Model autocompletion for composite services synchronization |
US8259923B2 (en) | 2007-02-28 | 2012-09-04 | International Business Machines Corporation | Implementing a contact center using open standards and non-proprietary components |
US8594305B2 (en) | 2006-12-22 | 2013-11-26 | International Business Machines Corporation | Enhancing contact centers with dialog contracts |
US9247056B2 (en) | 2007-02-28 | 2016-01-26 | International Business Machines Corporation | Identifying contact center agents based upon biometric characteristics of an agent's speech |
US9055150B2 (en) | 2007-02-28 | 2015-06-09 | International Business Machines Corporation | Skills based routing in a standards based contact center using a presence server and expertise specific watchers |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63192149A (ja) * | 1987-02-05 | 1988-08-09 | Nissin Electric Co Ltd | デ−タバス制御装置 |
JPH04329453A (ja) * | 1991-05-01 | 1992-11-18 | Fujitsu Ltd | 情報処理装置 |
US5754803A (en) * | 1996-06-27 | 1998-05-19 | Interdigital Technology Corporation | Parallel packetized intermodule arbitrated high speed control and data bus |
US5961623A (en) * | 1996-08-29 | 1999-10-05 | Apple Computer, Inc. | Method and system for avoiding starvation and deadlocks in a split-response interconnect of a computer system |
US5923673A (en) * | 1997-02-13 | 1999-07-13 | Sony Corporation | IEEE 1394 data/protocol analyzer |
US5996034A (en) * | 1997-10-14 | 1999-11-30 | Advanced Micro Devices, Inc. | Bus bridge verification system including device independent bus monitors |
US6032261A (en) * | 1997-12-30 | 2000-02-29 | Philips Electronics North America Corp. | Bus bridge with distribution of a common cycle clock to all bridge portals to provide synchronization of local buses, and method of operation thereof |
US6715008B2 (en) * | 1998-05-08 | 2004-03-30 | Fujitsu Ltd. | Method and system for over-run protection in a message passing multi-processor computer system using a credit-based protocol |
US6389547B1 (en) * | 1999-03-19 | 2002-05-14 | Sony Corporation | Method and apparatus to synchronize a bus bridge to a master clock |
AU4482000A (en) * | 1999-04-23 | 2000-11-10 | Sony Electronics Inc. | Method of and apparatus for implementing and sending an asynchronous control mechanism packet |
ES2207139T3 (es) * | 1999-06-02 | 2004-05-16 | Thomson Multimedia | Procedimiento y dispositivo para la creacion de una tabla de encaminamiento para una red de comunicaciones. |
US6633943B1 (en) * | 1999-09-21 | 2003-10-14 | Sony Corporation | Method and system for the simplification of leaf-limited bridges |
US6751697B1 (en) * | 1999-11-29 | 2004-06-15 | Sony Corporation | Method and system for a multi-phase net refresh on a bus bridge interconnect |
US6601124B1 (en) * | 2000-02-14 | 2003-07-29 | International Business Machines Corporation | Universal interface for selectively coupling to a computer port type and method therefor |
ATE372625T1 (de) * | 2000-02-18 | 2007-09-15 | Bridgeco Ag | Mehrtor-brücke zur lieferung von netzwerkverbindungen |
-
2001
- 2001-12-27 US US10/029,824 patent/US6898658B2/en not_active Expired - Fee Related
-
2002
- 2002-12-09 EP EP02805853A patent/EP1461922B1/en not_active Expired - Lifetime
- 2002-12-09 WO PCT/IB2002/005307 patent/WO2003056769A1/en active IP Right Grant
- 2002-12-09 AU AU2002367217A patent/AU2002367217A1/en not_active Abandoned
- 2002-12-09 JP JP2003557161A patent/JP2005513961A/ja not_active Withdrawn
- 2002-12-09 AT AT02805853T patent/ATE337663T1/de not_active IP Right Cessation
- 2002-12-09 KR KR10-2004-7010170A patent/KR20040086254A/ko not_active Application Discontinuation
- 2002-12-09 DE DE60214238T patent/DE60214238T2/de not_active Expired - Lifetime
- 2002-12-09 CN CNA028263162A patent/CN1611039A/zh active Pending
- 2002-12-09 ES ES02805853T patent/ES2269828T3/es not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP1461922A1 (en) | 2004-09-29 |
DE60214238T2 (de) | 2007-06-21 |
JP2005513961A (ja) | 2005-05-12 |
US6898658B2 (en) | 2005-05-24 |
WO2003056769A1 (en) | 2003-07-10 |
DE60214238D1 (de) | 2006-10-05 |
KR20040086254A (ko) | 2004-10-08 |
CN1611039A (zh) | 2005-04-27 |
AU2002367217A1 (en) | 2003-07-15 |
US20030126340A1 (en) | 2003-07-03 |
EP1461922B1 (en) | 2006-08-23 |
ATE337663T1 (de) | 2006-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2269828T3 (es) | Metodo para evitar una oscilacion de actualizacion de red. | |
US10291511B2 (en) | Bit index explicit replication (BIER) forwarding for network device components | |
ES2375326T3 (es) | Método, sistema y dispositivo de protección en una red de transporte de paquetes. | |
US7668082B1 (en) | Network routing using link failure information | |
ES2499034T3 (es) | Método de gestión de la topología de una red Ethernet multianillo, y su sistema | |
US4577313A (en) | Routing mechanism with encapsulated FCS for a multi-ring local area network | |
ES2323015T3 (es) | Procedimiento para procesar el fallo entre el lsr de salida y el equipo de datos conectado al mismo. | |
US4621362A (en) | Routing architecture for a multi-ring local area network | |
ES2910849T3 (es) | Método, dispositivo y sistema para la sincronización de información | |
ES2262525T3 (es) | Encaminamiento de telecomunicaciones. | |
US20030058850A1 (en) | Routing packets across multiple forwarding elements | |
ES2318268T3 (es) | Procedimiento y aparato para la reconfiguracion rapida de una topologia de red. | |
CA2011593A1 (en) | High-speed mesh connected local area network | |
JPH0738639B2 (ja) | 通信交換システム | |
RU2010141754A (ru) | Способ и устройство для квитирования состояния линии связи для предотвращения зацикливания | |
US8837329B2 (en) | Method and system for controlled tree management | |
JP2002077246A (ja) | マイクロモビリティネットワークにおける経路更新方法 | |
US20020080804A1 (en) | Router and IP-packet-transferring method | |
JP5246158B2 (ja) | 半導体集積回路及びフィルタ制御方法 | |
US20050088979A1 (en) | Configuration validation checker | |
WO2004056051A1 (en) | Return path derivation in packet-switched networks | |
CN100539545C (zh) | 用于在分组交换通信网中确定多径传输路径的方法和网络节点 | |
ES2647665B2 (es) | Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red | |
ES2777576T3 (es) | Procedimiento de comunicación con cálculo de ruta a partir de redes primarias, programa informático, nodo de interconexión y estación de radiocomunicación asociada | |
US20040076122A1 (en) | Implementation of constraints to ensure deadlock avoidance in networks |