ES2241587T3 - Procedimiento para la transmision de cuadros de ethernet. - Google Patents
Procedimiento para la transmision de cuadros de ethernet.Info
- Publication number
- ES2241587T3 ES2241587T3 ES00914029T ES00914029T ES2241587T3 ES 2241587 T3 ES2241587 T3 ES 2241587T3 ES 00914029 T ES00914029 T ES 00914029T ES 00914029 T ES00914029 T ES 00914029T ES 2241587 T3 ES2241587 T3 ES 2241587T3
- Authority
- ES
- Spain
- Prior art keywords
- ethernet
- cob
- server
- transmission
- ids
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Abstract
Procedimiento para la transmisión de cuadros de Ethernet a través de secuencias adecuadas de paquetes de datos de otro protocolo de transmisión, siendo extraídas las informaciones relevantes para el protocolo de transmisión a partir de una cabecera del cuadro de Ethernet, caracterizado porque: - una instancia central (Servidor Identificador de Objetos CAN) administra una cantidad de Identificadores de Objetos CAN, Red de Área del Controlador, utilizables, - la instancia central (Servidor Identificador de Objetos CAN) asigna a cada pareja de nodos de comunicación, entre los que se transmiten cuadros de Ethernet, una pareja de Identificadores de Objetos CAN, Red de Área del Controlador.
Description
Procedimiento para la transmisión de cuadros de
Ethernet.
La presente invención se refiere a un
procedimiento para la transmisión de cuadros de Ethernet.
El documento EP 0 771 096 publica un
procedimiento para la transmisión de cuadros de Ethernet a través
del protocolo ATM (Modo de Transferencia Asíncrona). El cometido de
la presente invención consiste en crear una posibilidad, con la que
se consigue una transmisión de cuadros de Ethernet con la ayuda del
Bus de Red de Área de Controlador (CAN). El documento de Bruce
Boyes: "Hard Real-Time Connectivity; it's in the
CAN", 1997, diseño de ordenador, describe las dificultades de
transmitir cuadros de Ethernet a través del Bus CAN, pero no
muestra ninguna posibilidad de solución.
De acuerdo con la invención, este cometido se
soluciona a través de un procedimiento con las características de
la reivindicación 1.
A continuación se describe un ejemplo de
realización de la invención:
En éste:
La figura 1 muestra el llamado formato de Cuadros
de CAN.
La figura 2 muestra una arquitectura global del
sistema según la invención.
La figura 3 muestra un paquete IP / ARP en el
cuadro de Ethernet.
La figura 4 muestra la administración del
Identificador de Objetos de CAN a través de un Servidor
COB-ID.
La figura 5 muestra direcciones MAC de nodos
CAN.
La figuras 6 muestra el registro de un abonado en
el Servidor COB-ID.
La figura 7 muestra la asignación de un
COB-ID punto a punto, y
La figura 8 muestra la transmisión de un cuadro
de Ethernet.
A continuación se representan de forma
esquemática exclusivamente las propiedades del protocolo Bus CAN,
que son absolutamente necesarias para la comprensión siguiente. Una
descripción en detalle del bus CAN se publica en la Norma
Controller Area Network (CAN) (ISO 11898).
En la figura 1 se representa el formato de cuadro
CAN. El Bus CAN ofrece varias longitudes de cuadros con 0 a 8
octetos de datos útiles, velocidades de transmisión brutas
programables hasta 1 Mbit/s (con longitud de segmento de 40 m,
reducción de la velocidad de transmisión en el caso de extensión
mayor de los segmentos en virtud de los tiempos binarios fijos) y
direccionamiento basado en mensajes. Esto último significa que a
una estación no está asignada una dirección amplia de la red, que
sirve como dirección de destino en un proceso de emisión (como, por
ejemplo, direcciones MAC en Ethernet), sino que en su lugar cada
mensaje está provisto previamente con una identificación relacionada
con el contenido, que sirve para las otras estaciones para la
selección de mensajes, que deben ser recibidos por ellas. Puesto
que los mensajes pueden ser considerados, desde el punto de vista
de la aplicación, como objetos CAN depositados en el hardware CAN,
recibidos o a transmitir, las identificaciones utilizadas son
designadas también como "Identificadores de Objetos CAN"
(COB-ID). Éstos tienen una longitud o bien de 11
bits o de 29 bits (CAN Extendido). Los controladores CAN
inteligentes habituales actualmente, como la Interfaz CAN del
\muControlador 80C167 o el CAN Controller Intel 82527, están en
condiciones de configurar al mismo tiempo diferentes IDs de emisión
y de recepción en sus memorias intermedias del hardware, cuyo
proceso de emisión o bien de recepción propiamente dicho se
desarrolla sin la actuación de un procesador. Junto con los
procedimientos de detección de errores y de tratamiento de errores
resultantes de ello, el bus CAN consigue de esta manera una
difusión múltiple atomizada del mensaje emitido.
El COB-ID utilizado de un mensaje
representa al mismo tiempo una prioridad: cuanto más bajo es el
COB-ID, tanto más alta se considera la prioridad del
mensaje. La prioridad sirve para el arbitraje del bus, es decir,
para la solución de conflictos de acceso en el caso de deseo de
emisión simultánea de diferentes nodos. La resolución del conflicto
se realiza, en oposición a otros procedimientos habituales, durante
la transmisión, sin provocar en este caso una destrucción del
mensaje. En su lugar, el mensaje de máxima prioridad se lleva a
efecto a través de la utilización de los llamados nivel dominante (0
lógico) y nivel recesivo (1 lógico) de una manera automática en el
bus. Para los mensajes de baja prioridad, que fueron pospuestos de
esta manera, los nodos tratan de realizar de forma automática una
nueva transmisión en el instante siguiente más próximo.
Puesto que la asociación de un
COB-ID se realiza normalmente con relación a la
importancia del contenido de los datos emitidos (por ejemplo,
velocidad de rotación de la rueda delantera izquierda) y no con
relación al nodo emisor o receptor, resulta también la prohibición
de que dos nodos diferentes envíen en el mismo instante un paquete
CAN con el mismo COB-ID. Esto no está permitido
dentro del Protocolo CAN, puesto que los dos mensajes se
superpondrían y conducirían a un estado no definido o al menos
erróneo sobre el bus.
El principio seguido prevé utilizar las pilas
TCP/IP existentes (como, por ejemplo, en PC/Windows NT) y hacer que
el bus CAN aparezca como una Ethernet. A tal fin, se transportan
cuadros de Ethernet, como se transmiten habitualmente a un
circuito excitador de Ethernet, en trozos a través del bus CAN. Por
lo tanto, hay que desarrollar un protocolo de transmisión, que
transmita cuadros de Ethernet a través de secuencias adecuadas de
paquetes CAN entre las estaciones implicadas. Las informaciones
relevantes para el protocolo de transmisión a desarrollar deben
extraerse en este caso a partir de las cabeceras de Ethernet de los
cuadros a emitir.
La arquitectura global resultante se representa
en la figura 2. Los componentes a desarrollar están constituidos,
en principio, por una capa de circuitos excitadores CAN para el
contacto con el hardware CAN y una capa de circuitos excitadores de
Ethernet, que se comunica hacia abajo con el circuito excitador CAN
e interactúa hacia arriba con la pila TCP/IP.
La arquitectura representada implica grandes
ventajas. Si se consigue totalmente la emulación de un segmento de
Ethernet, entonces la transmisión a través del CAN para la pila
TCP/IP y todos los protocolos de aplicación que se colocan encima
es totalmente transparente. En particular, se mantienen todas las
propiedades del plano IP, que acondiciona, en general, la pila, como
difusión múltiple, ruta, etc. Por lo tanto, en general, existe la
integración sin costura del plano del campo en redes
superpuestas.
En esta sección se representan de forma
esquemática las propiedades básicas de los paquetes IP, como son
generadas por protocolos superpuestos como TCP o UDP, y los cuadros
de Ethernet, sobre los que se reproducen paquetes IP típicamente en
entornos LAN. Para más detalles, se remite a uno de los numerosos
manuales de enseñanza sobre TCP/IP.
Los datos a enviar sobre el plano de transporte
por la aplicación de emisión son transferidos, en general, a través
de la interfaz de zócalo como corriente TCP o bien como paquetes
UDP a la pila TCP/IP y allí son desintegrados o bien empaquetados
en paquetes IP del plano de la red. Cada paquete IP es transmitido,
teniendo en cuenta las longitudes máximas, como cuadro de Ethernet a
la capa Link-Layer subordinada. Como se deduce a
partir de la figura 3, la cabecera de Ethernet contiene
especialmente la dirección de destino del cuadro sobre el medio de
Ethernet. Se designa como Dirección de Control de Acceso del Medio
(Dirección MAC) y está constituida, según la Norma IEEE 803.2, por
una identificación de 48 bits unívoca para cada adaptador de la red
de Ethernet jamás producido. El segundo campo, que debe
considerarse en la cabecera de Ethernet, es el ether_type_Feld, en
el que está definido el tipo del paquete contenido en el cuadro de
Ethernet. Aquí se contemplan los tipos ETHERTYPE_IP para paquetes
IP y ETHERTYPE_ARP; este último se utiliza a través del Protocolo
de Resolución de la Dirección (ARP) integrado en la pila TCP/IP para
la reproducción de direcciones IP en direcciones de
Ethernet-MAC.
Un problema básico es la asociación entre las
direcciones MAC de los cuadros de Ethernet y los CAN
COB-IDs, como se utilizan por el hardware CAN para
la transmisión. A tal fin, se indica una solución a
continuación.
Ya se ha descrito la diferencia básica de un
direccionamiento orientado a la estación en el lado de Ethernet en
oposición a un direccionamiento orientado a los mensajes dentro del
protocolo CAN.
Para la realización de una comunicación IP
transparente entre los nodos de abonados debe realizarse, por lo
tanto, un direccionamiento unívoco de estaciones individuales.
Además, la norma de Ethernet prevé la posibilidad de radiodifusión
y de difusión múltiple, también de cuadros de Ethernet, que están
dirigidos al mismo tiempo a todos o a una cantidad parcial de las
estaciones conectadas en el medio.
Los nodos de la red basados en CAN, en cambio,
están en condiciones, en general, de recibir cualquier paquete
discrecional emitido a través del bus, si una de las memorias
intermedias de recepción en el hardware está configurada para el
identificador CAN respectivo del mensaje. En este caso, no debe
realizarse ninguna asociación unívoca a una memoria intermedia,
puesto que el hardware utilizado contiene también memoria
intermedia, cuya aceptación para un identificador se puede marcar a
través de un registro, de manera que todos los
COB-IDs, que contienen un patrón binario determinado
o incluso cualquier identificador CAN discrecional, son aceptados
por la memoria intermedia de recepción. De la misma manera, cada
estación está en condiciones de emitir paquetes CAN con diferentes
COB-IDs libremente elegidos, siendo configuradas
memorias intermedias de emisión correspondientes.
Un principio nuevo sencillo para la reproducción
del direccionamiento de Ethernet consiste en asignar un
COB-ID fijo a cada abonado. Sin embargo, esto no
puede ser una dirección de recepción relacionada con la estación,
puesto que de esta manera se infringiría la prohibición de colocar
dos mensajes CAN con el mismo ID al mismo tiempo en el Bus, en el
caso de que la estación respectiva deba recibir en el mismo
instante mensajes de dos nodos diferentes. De esta manera, la
asignación de la identificación del emisor se mantiene como el ID
asociado de una manera unívoca a un nodo. Pero entonces la estación
direccionada como receptor solamente podría ser codificada en la
parte de datos del mensaje CAN; para establecer que ha sido
activada ella misma, una estación debería recibir, por lo tanto, en
primer lugar la totalidad de los mensajes emitidos, evaluar el
contenido y rechazar los paquetes dirigidos a otras estaciones.
Para la carga elevada máxima del sistema existiría, además, la
necesidad de alojar la dirección de la estación de destino en los
datos útiles, de todos modos apenas dimensionados con 8 Bytes, de
cada paquete.
Según la invención, se desarrolla un modelo (ver
la figura 4), que evita los problemas mencionados, pero para ello
requiere un nodo en un segmento del CAN como instancia central.
En este nodo se trata del llamado Servidor
COB-ID, que administra la cantidad de los
COB-IDs utilizables. La cantidad de los
COB-IDs utilizables para la emulación de Ethernet
se puede establecer libremente. De esta manera, se garantiza la
compatibilidad requerida con otros protocolos CAN sobre el bus CAN.
Para el transporte de los datos útiles, que forman cuadros de
Ethernet, se asocia a cada pareja de nodos que se comunican entre
sí, respectivamente, una pareja de COPB-IDs; para
la realización de la radiodifusión, cada nodo que desea emitir
recibe en cada caso un COB-ID desde el Servidor
COB-ID. Los receptores respectivos siguen la
asignación de COB-IDs de tal manera que se disponen
para la recepción de paquetes con estos identificadores y, por lo
tanto, ignoran los paquetes, que están destinados para otras
estaciones.
Las asociaciones respectivas se pueden mantener
sin más para procesos de comunicación posteriores de las parejas de
nodos; solamente en el caso de escasez creciente de los
COB-IDs libres, el Servidor COB-ID
debe reclamar los COB-IDs asignados. El protocolo
para la administración de los COB-IDs se describe
en detalle en la sección 5 siguiente.
No obstante, para una inicialización correcta,
cada nodo de abonado dentro de la emulación de Ethernet de un
segmento CAN debe poseer una dirección de estación unívoca, que se
establece ya en el instante de la instalación. Esta dirección sirve
para la identificación del nodo dentro de la fase de inicialización
del protocolo entre el nodo y el Servidor
COB-ID.
A tal fin, se ha seleccionado un valor de 16 bits
sin signo, de manera que se puede direccionar un máximo teórico de
64k nodos. Al mismo tiempo, este valor forma los 16 bits inferiores
de la dirección de Ethernet MAC de la estación en el marco de la
emulación; los bits más significativos son colocados en un prefijo
establecido, por ejemplo 0 (ver la figura 5). Puesto que en este
caso se trata solamente de una emulación de Ethernet y no del medio
real, estas direcciones MAC no pueden entrar en conflicto en un
segmento con las de adaptadores de Ethernet "auténticos".
La capa de emulación de Ethernet integrada en los
nodos de abonados y la aplicación del Servidor
COB-ID implementan en conjunto un protocolo que
permite la asignación de COB-IDs para diferentes
finalidades así como regula el control del flujo en el ciclo de
comunicación entre los nodos. La capa de Ethernet de los nodos de
los abonados actúa como capa de protocolo entre la implementación
TCP/IP y el circuito excitador CAN (ver la figura 1).
Sus cometidos consisten en la reproducción de las
direcciones de Ethernet MAC sobre COB-IDs, en la
segmentación y en el reensamblaje de cuadros de Ethernet en paquetes
CAN así como en la administración de los objetos CAN
correspondientes en el hardware con la ayuda del circuito excitador
CAN.
El cometido del servidor COB-ID
(designado en adelante, en tanto que sea unívoco, como
"Servidor") consiste en la memorización y organización de las
informaciones de administración para el desarrollo del protocolo
entre los nodos de abonados, especialmente para la utilización
correcta y eficiente de COB-IDs para la transmisión
de cuadros de Ethernet.
Un componente del protocolo del Servidor
COB-ID es un protocolo de inicialización dinámica,
con el que se registra un nuevo abonado en el Servidor
COB-ID. El desarrollo se representa en la figura
6.
Tan pronto como se ha inicializado localmente un
nodo de abonados, emite una solicitud de registro con un
COB-ID bien conocido al Servidor
COB-ID. Este COB-ID bien conocido
está fijado en el instante de proyecto y es utilizado por todos los
abonados para el registro. A este respecto, teóricamente, es decir,
en el caso de solicitud simultánea de registro a través de varios
abonados, se podría producir una colisión, que conduciría sobre el
bus CAN a una transmisión errónea reconocida. Para la resolución
del conflicto, se procede de acuerdo con el procedimiento
CSMA/CD.
En el caso de registro con éxito, el servidor
asigna al abonado a registrar una COB-ID unívoca,
privada, que utiliza la estación de abonado para cada comunicación
posterior con el servidor. En este mensaje de respuesta así como en
otros mensajes de control, el servidor utiliza un segundo
COB-ID bien conocido, para todos los nodos que
participan en el protocolo, que deben estar constantemente
preparados para la recepción para recibir mensajes de estado o
mensajes de control. Pero esto significa también que cada mensaje
del servidor es recibido por todos los nodos (difusión múltiple).
Los receptores deben evaluar en cada caso con la ayuda del contenido
del paquete si están afectados por el mensaje. El gasto generado de
esta manera se puede considerar reducido en virtud de la
transmisión de difusión múltiple de mensajes de control que tiene
lugar raras veces en relación con las transmisiones de datos
útiles.
Los dos COB-IDs bien conocidos
considerados son los dos únicos identificadores establecidos en todo
el sistema en el instante de la instalación, que están reservados a
través del protocolo "IP sobre CAN". Todos los
COB-IDs utilizados, además, son asignados por el
servidor y pueden ser retirados de nuevo después del uso, en caso
necesario. Para los COB-IDs que están disponibles en
este caso, están previstas actualmente zonas fijas en el código del
servidor. Una fijación dinámica de
COB-ID-Pools correspondientes, tal
vez en el instante de inicialización del servidor, puede tener en
cuenta especialmente las necesidades de las otras aplicaciones que
coexisten en el Bus CAN. De esta manera, se cumple de una forma
óptima la demanda de compatibilidad del protocolo con otros
protocolos CAN.
Por otro lado, se tienen en cuenta los encargos
de emisión de la capa superior del protocolo para cuadros de
Ethernet y los procesos que resultan de ello en el Protocolo del
Servidor COB-ID. Si se transmite en un nodo de
abonado un cuadro de Ethernet para la emisión, entonces se verifica
en primer lugar la dirección de destino en la cabecera de Ethernet
y se procede en función de si se trata de una dirección de estación
real o de una dirección de radiodifusión. (Una dirección de difusión
múltiple igualmente posible puede ser tratada como una transmisión
de radiodifusión y no se considera en detalle a continuación).
Una transmisión punto a punto de un cuadro de
Ethernet a una estación determinada con dirección MAC dada se
inicia con la solicitud de una pareja de COB-ID
desde el servidor COB-ID, como se representa en la
figura 7. La asignación de los COB-ID utilizados se
realiza, como se ha descrito anteriormente, a través de los
COB-ID bien conocidos y se registra también por
todas las estaciones en el bus, pero solamente se tiene en cuenta
por la estación asociada del emisor, que se prepara para la
recepción para el primer identificador y a continuación emite un
paquete CAN, direccionado con el segundo COB-ID
asociado como confirmación a la segunda estación, que se prepara
para la recepción para este identificador. Ahora se puede llevar a
cabo la transmisión del cuadro de Ethernet.
El modo emisor comienza la transmisión del cuadro
de Ethernet con un primer paquete CAN, que contiene la longitud del
Cuadro de Ethernet y los primeros datos útiles. Todos los otros
nodos reciben este paquete y los paquetes CAN inmediatamente
siguientes sin otras informaciones de control y los combinan en un
cuadro de Ethernet recibido. Si la transmisión del cuadro está
completa, entonces se transmite a las capas superiores de la
red.
Si se trata de un paquete de radiodifusión,
entonces se procede de una manera similar como en el caso de una
transmisión punto a punto. El nodo emisor de abonados solicita
desde el Servidor COB-ID un COB-ID
de radiodifusión. La asignación de los COB-ID a
utilizar se realiza de nuevo a través del COB-ID
bien conocido y se registra por todas las otras estaciones en el
bus, que se pueden configurar en este caso para la recepción del
cuadro de radiodifusión con el nuevo COB-ID.
Los COB-IDs asignados para una
finalidad determinada se pueden reutilizar en una nueva comunicación
de la misma pareja de estaciones, hasta que el Servidor
COB-ID lo reclama por falta de
COB-IDs disponibles. También en el caso de una
transmisión punto a punto en sentido inverso a una transmisión
precedente, se utiliza la pareja de COB-ID
asignada, siendo decisivas exclusivamente las estaciones
implicadas. Lo mismo se aplica para las radiodifusiones nuevas.
La reclamación de un COB-ID o
bien de una pareja predeterminada por el Servidor
COB-ID se inicia cuando el número de los
COB-IDs que están disponibles todavía para la
asignación en el Servidor COB-ID no alcanza un valor
crítico. La secuencia y la extensión de la reclamación se pueden
implementar en función de la estrategia. Una implementación
sencilla, realizada hasta ahora, utiliza un algoritmo FIFO. Una
supervisión temporal en el lado del Servidor COB-ID
de la utilización real de COB-IDs asignados es
posible a través de los nodos de abonados y puede servir al
Servidor COB-ID como base, por ejemplo, para un
algoritmo LRU para la selección de las reclamaciones. Para el inicio
de una reclamación, el Servidor COB-ID emite para
cada estación afectada una solicitud de devolución, que contiene la
dirección de la estación del nodo y los COB-ID
respectivos. Una transmisión de paquetes,, que se desarrolla todavía
a través del canal correspondiente, puede ser terminada por el
nodo, antes de que se confirme la devolución de los
COB-ID, respectivamente, por el nodo emisor con una
respuesta de devolución al Servidor COB-ID. Por
último, el Servidor COB-ID conduce los
COB-IDs devueltos de nuevo a su reserva de los
COB-IDs disponibles y confirma la devolución
realizada con un mensaje de control correspondiente. A
continuación, los objetos de emisión y recepción correspondientes
pueden ser desinicializados por los nodos y se retiran entradas en
las tablas de asignación local. La confirmación a través del
Servidor COB-ID está prevista para impedir que un
nodo pierda su disponibilidad de recepción para un
COB-ID, antes de que la parte contraria haya
ajustado todos los procesos de emisión para este ID. El proceso
descrito para la pareja de COB-ID se aplica de una
manera correspondiente también para COB-IDs
previstos para fines de radiodifusión, estando implicados en este
caso sólo un nodo y el Servidor COB-ID.
Claims (4)
1. Procedimiento para la transmisión de cuadros
de Ethernet a través de secuencias adecuadas de paquetes de datos
de otro protocolo de transmisión, siendo extraídas las
informaciones relevantes para el protocolo de transmisión a partir
de una cabecera del cuadro de Ethernet, caracterizado
porque
- -
- una instancia central (Servidor Identificador de Objetos CAN) administra una cantidad de Identificadores de Objetos CAN, Red de Área del Controlador, utilizables,
- -
- la instancia central (Servidor Identificador de Objetos CAN) asigna a cada pareja de nodos de comunicación, entre los que se transmiten cuadros de Ethernet, una pareja de Identificadores de Objetos CAN, Red de Área del Controlador.
2. Procedimiento según la reivindicación 1,
caracterizado porque la instancia central (CAN, Red de Área
del Controlador) reclama Identificadores de Objetos CAN asociados,
a medida que se incrementa la escasez de Identificadores de Objetos
CAN libres.
3. Procedimiento según la reivindicación 1 ó 2,
caracterizado porque un nodo de abonados emite una solicitud
de registro a la instancia central (Servidor de Identificadores de
Objetos CAN) y la instancia central (Servidor de Identificadores de
Objetos CAN) asigna al nodo de abonados un Identificador de Objetos
CAN unívoco privado.
4. Procedimiento según la reivindicación 1 ó 2,
caracterizado porque la instancia central (Servidor de
Identificadores de Objetos CAN) utiliza para la transmisión de
mensajes de control a uno o varios nodos de abonados una
identificación, para la que todas las estaciones están
constantemente preparadas para recibir.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE19908510 | 1999-02-26 | ||
| DE19908510 | 1999-02-26 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2241587T3 true ES2241587T3 (es) | 2005-11-01 |
Family
ID=7899064
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00914029T Expired - Lifetime ES2241587T3 (es) | 1999-02-26 | 2000-02-14 | Procedimiento para la transmision de cuadros de ethernet. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7443853B2 (es) |
| EP (1) | EP1155549B1 (es) |
| AT (1) | ATE293861T1 (es) |
| DE (1) | DE50010109D1 (es) |
| ES (1) | ES2241587T3 (es) |
| WO (1) | WO2000052706A2 (es) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU1940199A (en) * | 1997-12-24 | 1999-07-19 | America Online, Inc. | Asynchronous data protocol |
| FR2844946B1 (fr) * | 2002-03-15 | 2004-10-22 | Thales Sa | Procede de selection et de tri de paquets mis a disposition d'un equipement par un reseau de transmission de donnees par paquets |
| FR2847751B1 (fr) * | 2002-11-22 | 2005-04-01 | Peugeot Citroen Automobiles Sa | Systeme de transmission securisee d'informations entre des stations raccordees par un reseau de transmission d'informations embarque a bord d'un vehicule automobile |
| ES2239537B1 (es) * | 2004-03-05 | 2006-11-16 | Seat, S.A. | Sistema de monitorizacion y control de elementos de un vehiculo. |
| US8774215B2 (en) * | 2006-09-01 | 2014-07-08 | Emulex Corporation | Fibre channel over Ethernet |
| US8396009B2 (en) * | 2007-08-21 | 2013-03-12 | International Business Machines Corporation | Method and apparatus for an adapter in a network device to discover its adapter name in a network system |
| US8176208B2 (en) * | 2009-11-04 | 2012-05-08 | Hitachi, Ltd. | Storage system and operating method of storage system |
| CN102255800B (zh) * | 2011-06-24 | 2014-04-02 | 中国人民解放军国防科学技术大学 | Can总线上ip数据包和can消息之间数据格式相互转换的方法 |
| KR102004926B1 (ko) * | 2012-11-06 | 2019-07-29 | 한국전자통신연구원 | 캔-이더넷 프레임 변환장치 및 이의 프레임 변환 방법 |
| DE102015200301A1 (de) * | 2015-01-13 | 2016-07-14 | Robert Bosch Gmbh | Verfahren zum Klassifizieren eines Datensegments bezüglich dessen Weiterverarbeitung |
| CN111131520B (zh) * | 2020-01-09 | 2021-06-01 | 山东超越数控电子股份有限公司 | 一种基于边缘云环境的虚拟can口多路复用技术的实现方法 |
| US20220303642A1 (en) * | 2021-03-19 | 2022-09-22 | Product Development Associates, Inc. | Securing video distribution |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2891146B2 (ja) * | 1995-10-23 | 1999-05-17 | 日本電気株式会社 | ネットワークサーバ |
| US5745685A (en) * | 1995-12-29 | 1998-04-28 | Mci Communications Corporation | Protocol extension in NSPP using an acknowledgment bit |
| US5917820A (en) * | 1996-06-10 | 1999-06-29 | Cisco Technology, Inc. | Efficient packet forwarding arrangement for routing packets in an internetwork |
| US6041358A (en) * | 1996-11-12 | 2000-03-21 | Industrial Technology Research Inst. | Method for maintaining virtual local area networks with mobile terminals in an ATM network |
| US6111888A (en) * | 1997-05-27 | 2000-08-29 | Micro Motion, Inc. | Deterministic serial bus communication system |
| US6584122B1 (en) * | 1998-12-18 | 2003-06-24 | Integral Access, Inc. | Method and system for providing voice and data service |
| US6654355B1 (en) * | 1999-12-14 | 2003-11-25 | Schneider Automation Inc. | Bridge for CAN to TCP/IP connection |
-
2000
- 2000-02-14 WO PCT/DE2000/000420 patent/WO2000052706A2/de active IP Right Grant
- 2000-02-14 AT AT00914029T patent/ATE293861T1/de not_active IP Right Cessation
- 2000-02-14 DE DE50010109T patent/DE50010109D1/de not_active Expired - Fee Related
- 2000-02-14 ES ES00914029T patent/ES2241587T3/es not_active Expired - Lifetime
- 2000-02-14 EP EP00914029A patent/EP1155549B1/de not_active Expired - Lifetime
-
2001
- 2001-08-24 US US09/935,573 patent/US7443853B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000052706A3 (de) | 2001-01-04 |
| DE50010109D1 (de) | 2005-05-25 |
| EP1155549B1 (de) | 2005-04-20 |
| WO2000052706A2 (de) | 2000-09-08 |
| EP1155549A2 (de) | 2001-11-21 |
| ATE293861T1 (de) | 2005-05-15 |
| US7443853B2 (en) | 2008-10-28 |
| US20020034180A1 (en) | 2002-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101213817B (zh) | 从终端的原始mac地址到唯一的本地管理虚拟mac地址的映射 | |
| ES2241587T3 (es) | Procedimiento para la transmision de cuadros de ethernet. | |
| US8406227B2 (en) | Hybrid wired and wireless communication system and a communication method thereof | |
| US6405247B1 (en) | Method and apparatus for operating the internet protocol over a high-speed serial bus | |
| US6438128B1 (en) | Alternate use of data packet fields to convey information | |
| CN100574272C (zh) | 自动虚拟局域网标识符发现的方法和网络终端 | |
| CN1739276B (zh) | 用于以太网mac地址管理的系统、方法和功能 | |
| CN100508480C (zh) | 一种涉及以太网接入系统的设备和方法 | |
| CN101160850B (zh) | 一种转发报文的方法及装置 | |
| CN100581177C (zh) | 获得互联网协议地址及建立操作维护链路的方法和系统 | |
| CN100471162C (zh) | 一种发布及处理虚线路信息的方法和供应商边缘设备 | |
| EP4231597A1 (en) | Method for forwarding bier message, and device and system | |
| CN100364289C (zh) | 在基于弹性分组环的网络中实现二层设备互连的方法 | |
| TWI491231B (zh) | 網型網路之代理機制 | |
| CN107645433B (zh) | 报文转发方法及装置 | |
| CN101115004B (zh) | 阻止主机访问网络设备的方法及阻断服务器 | |
| JP2000506295A (ja) | アプリケーションとバス間の非同期データ転送を自動的に管理する非同期データパイプ | |
| CN103597780B (zh) | 用于多接口网络节点的通信机制 | |
| CN113114576B (zh) | 报文发送的方法、设备和系统 | |
| CN107277190A (zh) | 一种sdn设备自动上线的方法、sdn设备和控制器 | |
| US20020061025A1 (en) | Data transmitting and receiving apparatus and data transmitting and receiving method | |
| US20040202185A1 (en) | Multiple virtual local area network support for shared network adapters | |
| CN106487677B (zh) | 运营商边缘设备及数据转发方法 | |
| US7580420B2 (en) | Interface circuit connecting a device with a bridge portal function to a communication bus | |
| ES2251920T3 (es) | Procedimiento para la asignacion de direcciones ip en redes de comunicaciones. |