ES2244012T3 - Aparato para integracion de varios medios fisicos para comunicacion de datos. - Google Patents
Aparato para integracion de varios medios fisicos para comunicacion de datos.Info
- Publication number
- ES2244012T3 ES2244012T3 ES97950022T ES97950022T ES2244012T3 ES 2244012 T3 ES2244012 T3 ES 2244012T3 ES 97950022 T ES97950022 T ES 97950022T ES 97950022 T ES97950022 T ES 97950022T ES 2244012 T3 ES2244012 T3 ES 2244012T3
- Authority
- ES
- Spain
- Prior art keywords
- ivi
- controller
- network
- communication
- layer
- 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
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
SE DESCRIBEN UN PROCEDIMIENTO Y APARATO QUE EJECUTAN COMUNICACIONES BIDIRECCIONALES CON EL USO DE LOS MISMOS SOPORTES FISICOS O SOPORTES DIFERENTES, QUE ENLAZAN DOS CUALESQUIERA SISTEMAS DE CALCULO, NODOS, EMPLEANDO PROTOCOLOS ENCAMINABLES COMO TCP/IP, IPX, ETC., CONECTADOS A UNA RED COMUN, PERMITIENDO LA COMUNICACION BIDIRECCIONAL ENTRE ELLOS. UNO DE LOS SOPORTES FISICOS TIENE PREFERENTEMENTE UNA ANCHURA DE BANDA MAYOR EN UNA DIRECCION QUE EN OTRA DE LOS SOPORTES FISICOS QUE OPERAN EN LA OTRA DIRECCION. LA PRESENTE INVENCION PERMITE IGUALMENTE OPTIMIZAR EL TRAFICO ENTRE DOS NODOS CUALESQUIERA POR SELECCION APROPIADA DE VIAS DE COMUNICACION BASANDOSE EN LA ANCHURA DE BANDA O EN LOS COSTES. LA COMUNICACION ENTRE DOS NODOS CUALESQUIERA PUEDE DIVIDIRSE ENTRE VARIAS VIAS FISICAS O LOGICAS DIFERENTES, PARA AUMENTAR LA ANCHURA DE BANDA DE TRANSMISION EFECTIVA O PARA PROPORCIONAR REDUNDANCIA A LA COMUNICACION. UN PROCEDIMIENTO Y SISTEMA EJECUTAN UN INTERFAZ VIRTUAL INTEGRADO (IVI) QUE COMBINA, ENUN UNICO INTERFAZ VIRTUAL, AL MENOS DOS INTERFACES FISICOS POR NODO DE COMUNICACION (UNO PARA CADA DIRECCION DE COMUNICACION) DE MANERA TRANSPARENTE, DE MODO QUE LAS OPERACIONES DE NIVEL NUMERO 3 EN EL MODELO ISA (INTERCONEXION DE SISTEMAS ABIERTOS) DE LA ISO (ORGANIZACION INTERNACIONAL PARA LA NORMALIZACION), PARA PROTOCOLOS DE COMUNICACION DE DATOS, Y LOS NIVELES POR ENCIMA DEL NUMERO 3 ACTUEN COMO SI EXISTIERA UN UNICO INTERFAZ DE COMUNICACION BIDIRECCIONAL, MIENTRAS QUE LOS NIVELES ISA NUMEROS 1 Y 2 MANTIENEN TODA SU FUNCIONALIDAD ESTANDAR.
Description
Aparato para la integración de varios medios
físicos para comunicaciones de datos.
La presente invención se refiere a un aparato
para efectuar una comunicación bidireccional entre sistemas de
cómputo, y más particularmente, a un aparato para efectuar
comunicaciones por múltiples canales de datos de diferentes anchos
de banda en el que el ordenador del usuario envía datos por un canal
de ancho de banda estrecho y el servidor devuelve datos por un canal
de ancho de banda ancho. El aparato funciona de una manera
transparente a las capas nº 3 y superiores del modelo OSI al tiempo
que también es transparente a las capas nº 1 y nº 2.
Hay productos disponibles para comunicaciones de
datos interactivas entre sistemas de cómputo mediante los cuales los
usuarios solicitan y reciben un gran volumen de información, pero
generan muchos menos datos, tal como es el caso habitual de la
navegación y comunicación por Internet. Por lo general, los usuarios
demandan cantidades de datos mucho mayores, por ejemplo, páginas web
multimedia, que lo que ellos mismos generan. Los usuarios generan
normalmente sólo unos pocos clics de ratón y los acuses de recibo de
la recepción de paquetes TCP/IP a cambio de las páginas web
multimedia. Este hecho ha provocado la discusión e implementación de
comunicaciones bidireccionales que son "asimétricas" con
respecto a las capacidades de transmisión en los dos sentidos de
comunicación.
Ejemplos de los productos anteriormente
mencionados son los denominados "módems de cable", los cuales
le permiten a un abonado de la TV por cable que desea navegar
("surfear") por Internet recibir los datos de Internet a una
velocidad muy rápida (de 500 Kbps a 5-10 Mbps) de
una red de cables coaxiales de TV por cable, mientras envía las
solicitudes a Internet a través de una línea telefónica normal. Una
implementación similar para comunicaciones asimétricas a alta
velocidad es el sistema conocido como DirectPC, de Hughes
Corporation, que proporciona una navegación rápida por Internet
utilizando un enlace descendente por satélite como canal de banda
ancha y una tarjeta de interfaz que lleva embebido un módem
unidireccional de alta velocidad.
Sin embargo, los protocolos interactivos de
transmisión de datos estándar tales como TCP/IP están concebidos
para ocuparse de las comunicaciones simétricas utilizando una sola
interfaz física de comunicaciones y un solo identificador lógico por
nodo (por ejemplo, en TCP/IP, la denominada "dirección IP").
Los protocolos no pueden ocuparse del hecho de que, para tales
comunicaciones asimétricas, dos medios de transmisión diferentes
están más capacitados para la tarea de la comunicación
bidireccional, tales como un canal unidireccional de emisión de gran
ancho de banda del servidor de la red al usuario, tal como fibra
óptica, cable coaxial, satélite, microondas, etc., y un canal
bidireccional de banda estrecha del usuario a la red, tal como
líneas telefónicas estándar. Tal comunicación demanda el uso de dos
interfaces físicas por nodo, una para cada sentido de comunicación
y, en consecuencia, dos identificaciones lógicas de red o
direcciones IP (en TCP/IP) por nodo.
Por tanto, existe una necesidad de un método y un
sistema abiertos capaces de acomodar dos enlaces de comunicación en
protocolos de transmisión de datos estándar, tales como TCP/IP, sin
alterar en ninguna manera perceptible la interfaz a los niveles
superiores de los protocolos que están relacionados más directamente
con aplicaciones de usuario, tales como los niveles nº 3 y
superiores en el modelo OSI. Esto resulta necesario para permitir
que cualquier software de aplicación comercial, tal como los
navegadores web estándar, pueda ejecutarse en un entorno de
comunicación de doble vía sin modificación y asimismo sin alterarlos
en ninguna manera perceptible con respecto a interconectarse con los
niveles inferiores que se ocupan de las comunicaciones físicas, los
niveles nº 1 y nº 2, para permitir el uso de protocolos de
comunicación estándar que se ocupan del enlace físico y lógico entre
dos ordenadores en comunicación.
El documento WO 95/34153 da a conocer un terminal
híbrido que asigna dos direcciones IP a cada único
identificador/dirección, una de ellas es para enviar paquetes de
datos del usuario al destino y la otra para recibir paquetes de
datos procedentes del destino a través de una red de satélite, por
tanto, cada tipo de canal es unidireccional.
El documento US 4.793.813 da a conocer que un
usuario emplea uno o más enlaces dedicados basados en una red de
comunicación por tierra para comunicarse con un servidor de destino
de una manera unidireccional. El usuario recibe información de datos
del destino a través de un canal de satélite; además, el canal se
utiliza de manera unidireccional.
Por consiguiente, es un objeto de la invención
proporcionar un aparato para la comunicación bidireccional que
resuelve las desventajas de la técnica anterior.
Es un objeto más de la invención proporcionar un
aparato que permita el uso de distintos medios de transmisión para
cada sentido de comunicación, pero una sola identificación de nodos
en la capa nº 3 del modelo OSI, a través de una Interfaz Virtual
Integrada (IVI) que controla dos o más interfaces físicas (o
virtuales) en conjunción con una sola identificación del nivel de
capa nº 3, sin modificar las características del protocolo empleado,
permitiendo la identificación de un nodo de procesamiento de
información a través de un nombre o dirección independiente de las
varias identificaciones de interfaz de conexión.
Estos objetos son satisfechos por un aparato para
ejecutar una comunicación bidireccional entre más de dos redes según
las características de la reivindicación 1.
Los anteriores y otros objetos, características y
ventajas de la presente invención resultarán evidentes a partir de
la siguiente descripción leída en conjunción con los dibujos
adjuntos, en los que números de referencia similares designan los
mismos elementos.
La figura 1 es el modelo de referencia ISO OSI
para el funcionamiento de un sistema informático.
La figura 2 es un plan de arquitectura de sistema
de las cuatro capas más bajas del modelo OSI en sistemas NDIS
(Especificación de Interfaz de Controlador de Red) para Windows 95,
Windows NT, algunas versiones de Unix, OS/2, entre otros.
La figura 3 es un plan de arquitectura de sistema
de una realización de la presente invención que incorpora una IVI en
el modelo OSI.
La figura 4 es un plan de arquitectura de sistema
de una realización de la presente invención que
incorpora la IVI en las cuatro capas OSI más bajas en sistemas NDIS 3 para el sistema operativo Windows 95 proporcionado por Microsoft Corporation.
incorpora la IVI en las cuatro capas OSI más bajas en sistemas NDIS 3 para el sistema operativo Windows 95 proporcionado por Microsoft Corporation.
La figura 5 es un plan de arquitectura de sistema
de una realización de la presente invención que incorpora la IVI en
las cuatro capas OSI más bajas en sistemas NDIS 4 con la IVI para
Windows NT proporcionado por Microsoft Corporation.
La figura 6 es un plan de arquitectura de sistema
detallado de la incorporación de los controladores de la figura 4 en
el sistema de la figura 5.
La figura 7 es un plan de arquitectura de sistema
para la presente invención que muestra la IVI que unifica varias
interfaces bajo una sola dirección de red.
La figura 8 es un esquema que muestra un flujo de
datos que utiliza la IVI desde los puntos de vista del proceso del
sistema y los enlaces físicos.
La figura 9 presenta esquemas que muestran un
flujo de datos que utiliza la IVI desde los puntos de vista del
procesador del sistema y los enlaces físicos.
La figura 10 es un diagrama de bloques sobre cómo
puede controlarse la IVI desde cualquier aplicación.
La figura 11 es un digital de sistema que muestra
cómo es controlado el funcionamiento de la IVI desde una base de
datos (para el servidor de información) o desde la información
transmitida por los otros nodos (para el servidor de información o
el cliente) por un controlador IVI.
La figura 12 muestra un sistema
multi-IVI para un servicio de datos en el que puede
transmitirse información de un cierto nodo a otro(s)
nodo(s) a través de distintos medios físicos.
La figura 13 muestra varios módulos IVI
diferentes implementados para un servicio de comunicación
multiusuario que utiliza la IVI.
La figura 14 muestra un sistema para un acceso a
Internet de alta velocidad dotado de un servicio de TV digital que
utiliza la IVI para integrar un canal de banda ancha y un canal de
retorno telefónico.
La figura 15 muestra un montaje de sistema con
una IVI a través de un enlace físico bidireccional, tras el cual se
utilizan dos enlaces físicos diferentes que llevan tráfico
unidireccional durante la duración de las comunicaciones
subsiguientes.
La figura 16 es un esquema lógico de un flujo de
datos en un servicio de información comercial que utiliza una IVI
que combina dos vías físicas en un solo canal bidireccional
virtual.
La figura 17 es un diagrama de flujo que detalla
el funcionamiento del Controlador de Transporte IVI en un entorno
NDIS 3.
La figura 18 es un diagrama de flujo que detalla
el funcionamiento del Controlador NIC Virtual IVI en un entorno NDIS
3.
La figura 19 es un diagrama de flujo que detalla
el funcionamiento del Controlador NIC Intermedio IVI en un entorno
NDIS 4.
La figura 20 es un diagrama de flujo que detalla
el funcionamiento de un procedimiento para abrir una conexión entre
un cliente y unos nodos del servi-
dor.
dor.
La presente invención proporciona un método que
efectúa una comunicación de datos bidireccional y un sistema
informático configurado para implementar el método para la
comunicación bidireccional. Se entiende que un sistema informático
así incluye un
procesador central y una memoria para almacenar programas que configuran el sistema informático y otros datos a transmitir, recibidos o sobre los que se actúa.
procesador central y una memoria para almacenar programas que configuran el sistema informático y otros datos a transmitir, recibidos o sobre los que se actúa.
Con referencia a la figura 1, el modelo de
referencia ISO OSI para las comunicaciones de datos presenta todas
las tareas y niveles necesarios implicados en una comunicación entre
dos aplicaciones informáticas divididas en un conjunto jerárquico de
capas. El software que constituye cada capa realiza un subconjunto
relacionado de las funciones requeridas para la comunicación con
otro sistema informático y se basa en la siguiente capa inferior
para realizar funciones más primitivas y ocultar los detalles de
esas funciones al tiempo que proporciona servicios a la capa
inmediatamente superior. De la mayor importancia en la presente
invención es la capa nº 3 (la capa de red, o IP en el protocolo
TCP/IP, que se ocupa del tipo de tráfico de Internet), la cual
asigna a cada ordenador en comunicación, conectado por una interfaz
física bidireccional, una dirección de red única (el nodo
"dirección IP" en TCP/IP).
Se reconoce que, en situaciones que implican
comunicaciones entre ordenadores que utilizan Internet, las cuales
resultan en pautas de tráfico que normalmente requieren un ancho de
banda mucho mayor en una vía del servidor al usuario que viceversa,
una conectividad interactiva orientada a la red y una naturaleza a
ráfagas del tráfico, el canal de comunicación más rentable es uno en
el que una interacción bidireccional es el resultado de combinar: i)
un canal unidireccional punto a multipunto de ancho de banda ancho
del servidor al usuario (tal como un satélite, fibra/cable coaxial o
sistemas punto a multipunto por microondas tales como en MMDS/LMDS),
el cual es compartido por muchos usuarios simultáneos; e ii) un
enlace punto a punto de ancho de banda más estrecho, tal como una
línea telefónica estándar, X.25 o líneas de retransmisión de tramas
(frame relay), de cada usuario al servidor.
El uso simultáneo de dos vías de comunicación
diferentes presenta dos problemas cuando se emplean los protocolos
actuales. El primero es que tal comunicación de doble vía que emplea
dos interfaces físicas de comunicación por nodo da como resultado
que la capa nº 3 estándar asigna dos direcciones de red/IP por nodo
y potencialmente deshabilita ciertas aplicaciones estándar que
tratan directamente con el nivel nº 3, tales como FTP (Protocolo de
Transferencia de Archivos) o navegadores web. El segundo problema es
cómo manejar canales unidireccionales utilizando protocolos
concebidos para interfaces de canal bidireccionales. La presente
invención solventa los problemas anteriores para establecer
comunicaciones de datos interactivas de ancho de banda elevado,
rentables, utilizando una comunicación de doble vía.
Una realización de un método y aparato
proporcionados por la presente invención solventa los problemas
anteriores proporcionando una capa intermedia adicional de
operaciones controladas por software, debajo del nivel nº 3 (que es
el nivel inferior direccionado directamente por las aplicaciones
informáticas actuales) y dentro del nivel nº 2 (que controla la
interfaces físicas de datos de entrada/salida), entre subcapas del
nivel nº 2, que oculta la existencia de dos o más interfaces de
comunicación físicas empleadas en una cierta sesión de comunicación
de datos de una manera transparente de manera que ninguno de los
procesos de protocolo estándar (la pila de protocolo) sea alterado
y/o reaccione ante la presencia de múltiples interfaces físicas. En
la presente memoria se hace referencia a la nueva capa intermedia
como "Interfaz Virtual Integrada" (en lo sucesivo, IVI) porque
implementa mediante software una sola interfaz bidireccional virtual
que combina varias interfaces físicas de comunicación que son
unidireccionales o bidireccionales.
Para establecer con más detalle dónde se insertan
las operaciones IVI dentro de la pila de protocolo estándar para
implementaciones prácticas, de aquí en adelante se hará referencia a
la arquitectura NDIS (Especificación de Interfaz de Controlador de
Red) debido a sus ventajas y uso extendido para las comunicaciones
de datos. Sin embargo, la implementación de la operación IVI de la
presente invención para cualquier protocolo encaminable de
comunicación de datos que siga el modelo OSI se encuentra dentro del
alcance y espíritu de la presente invención.
En los sistemas NDIS, existen tres tipos
distintos de controladores de red: servicios de red, controladores
de transporte de red y controladores de adaptador de red (referidos
también como controladores NIC (Tarjeta de Interfaz de Red). Los
servicios de red son los controladores de nivel más alto en la pilas
de protocolo de NDIS, los cuales implementan protocolos de la capa
nº 5 e interfaces inferiores de la capa nº 5 - capa nº 4. Los
controladores de transporte de red se encuentran debajo de los
servicios de red, implementando los protocolos de la capa nº 4, la
capa nº 3 y la subcapa Nº 2.2, las interfaces superiores de la capa
nº 5 - capa nº 4 y las interfaces inferiores de la subcapa nº 2.2 -
subcapa nº 2.1. Los controladores de adaptador de red son los
controladores inferiores en las pilas de protocolo de NDIS,
implementando los protocolos de la capa nº 2.1 y las interfaces
superiores de la subcapa nº 2.2 - subcapa nº 2.1.
Bajo esta arquitectura, hay dos posibles
ubicaciones para los controladores de red IVI: entre los servicios
de red y los controladores de transporte de red o entre los
controladores de transporte de red y los controladores de adaptador
de red. La presente invención implementa la segunda alternativa a
fin de permitir la existencia de un identificador de red único para
cada nodo de comunicación (existe un identificador de red único para
cada enlace entre un controlador de transporte de red y un
controlador de adaptador de red).
Con referencia a la figura 2, los cuatro niveles
inferiores del modelo OSI (las capas implicadas en el transporte de
datos propiamente dicho) se ilustran en un entorno en el que se
utiliza la arquitectura NDIS. NDIS es un estándar que permite a los
desarrolladores de software escribir controladores de dispositivo
que son independientes del sistema operativo (SO) empleado. Por
tanto, puede usarse con Windows 95, Windows NT y algunas versiones
de Unix, OS/2, etc. NDIS ensambla las capas nº 1 a nº 4 en tres
bloques "monolíticos" que se comunican entre sí a través de las
primitivas NDIS: el controlador 50 de transporte que agrupa las
capas 2.3, 3 y 4, el controlador 52 NIC (Tarjeta de Interfaz de Red)
que incluye la capa 2.1, y la propia NIC 53. Puesto que el
controlador 52 NIC sólo se ocupa de la escritura/lectura de los
datos en y del NIC 53 dado, las operaciones de IVI están
configuradas para interconectarse entre las operaciones del
controlador 50 de transporte y las operaciones del controlador 52
NIC.
Cada capa en el modelo OSI implementa un cierto
protocolo. Por ejemplo, el protocolo TCP en la capa nº 4, el
protocolo IP en la capa nº 3, el protocolo Ethernet II en la capa nº
3. A fin de comunicarse entre dos sistemas, resulta necesario que
ambas tengan controladores que implementen los mismos protocolos en
las mimas capas.
Entre dos capas adyacentes cualesquiera en el
modelo OSI, existe un conjunto predefinido de interfaces. Cada
controlador de cualquiera de las capas debe "comprender" a al
menos una de dichas interfaces para ser capaz de comunicarse con los
controladores de las capas superiores y las capas inferiores
adyacentes (interfaces "superiores" e interfaces
"inferiores", respectivamente).
Un sistema operativo permite la instalación de
varios controladores para cada una de las capas. El programa de
instalación para cada controlador proporciona información al sistema
operativo sobre cuáles son las interfaces superiores e inferiores
que son "comprendidas" por un controlador instalado. Según esta
información, el sistema operativo crea una base de datos que
almacena todas las vías posibles a través de las cuales puede fluir
la información de programas de aplicación a los medios físicos de
transmisión y viceversa. El sistema operativo permite a un
administrador del sistema habilitar o deshabilitar cualquiera de
tales vías de información en la base de datos anteriormente
mencionada.
Cada una de las vías de información viene
descrita por una serie de controladores a través de los cuales debe
fluir la información. Puesto que cada controlador implementa un
protocolo para cada una de las capas que engloba, a tal vía puede
llamársela "pila de protocolo".
Por tanto, una vista muy sencilla del marco del
modelo OSI puede ser la siguiente:
- Hay un controlador diferente para cada
capa.
- Cada controlador de un nº n posterior (para n
entre 1 y 6) tiene una interfaz superior con la capa nº n+1.
- Cada controlador de una capa nº n (para n entre
2 y 7) tiene una interfaz inferior con la capa nº
n-1.
No obstante, resulta posible instalar
controladores con interfaces superiores que correspondan a capas que
son inferiores a las de sus interfaces inferiores. De este modo, es
posible crear "pilas de protocolo" en las que la funcionalidad
corresponda a un cierto conjunto de controladores, mientras que se
fuerza a la información a fluir a través de un conjunto distinto de
controladores. Tal como se explica con más detalle posteriormente,
la capa IVI de la presente invención funciona de esta manera,
conservando la funcionalidad total de las capas superiores nº 7 a nº
2.2 y las capas inferiores, nº 2.1 a 1, pero forzando a que la
información fluya a través de la capa IVI intermedia que tiene una
interfaz superior, nº 2.1, que es inferior a su interfaz inferior,
nº 2.2.
Con referencia a la figura 3, un módulo 60 IVI
(controlador) de operaciones se muestra incorporado en el modelo OSI
general. El módulo 60 IVI está formado por dos controladores
secundarios. El controlador 62 de transporte IVI incluye una capa
IVI 2.2 para realizar operaciones de las funciones de la capa nº 2.2
y es un controlador de transporte de red vinculado a los
controladores de adaptador de red que existen en el sistema. El
controlador 64 NIC virtual IVI incluye una capa IVI 2.1 para
realizar operaciones de las
funciones de la capa nº 2.1. El controlador 64 NIC virtual IVI está vinculado a los controladores de transporte de red que existen en el sistema (normalmente, TCP/IP y controlador de transporte IVI). Cuando ha de enviarse un paquete a la red, un controlador de transporte de red los envía al controlador 64 NIC virtual IVI. El controlador 64 NIC virtual IVI simplemente envía el paquete al controlador 62 de transporte IVI, el cual lo reenvía al (a los) correspondiente(s) controlador(s) real(es). Cuando se recibe un paquete procedente de la red, el controlador 62 de transporte IVI lo envía al controlador 64 NIC virtual IVI, el cual lo envía a su vez al controlador de transporte de red apropiado.
funciones de la capa nº 2.1. El controlador 64 NIC virtual IVI está vinculado a los controladores de transporte de red que existen en el sistema (normalmente, TCP/IP y controlador de transporte IVI). Cuando ha de enviarse un paquete a la red, un controlador de transporte de red los envía al controlador 64 NIC virtual IVI. El controlador 64 NIC virtual IVI simplemente envía el paquete al controlador 62 de transporte IVI, el cual lo reenvía al (a los) correspondiente(s) controlador(s) real(es). Cuando se recibe un paquete procedente de la red, el controlador 62 de transporte IVI lo envía al controlador 64 NIC virtual IVI, el cual lo envía a su vez al controlador de transporte de red apropiado.
En el modelo OSI, la capa nº 2.2 (el protocolo
que controla un cierto controlador de interfaz física) espera
comunicarse con la capa nº 2.1 de sistemas (el controlador de la
tarjeta de interfaz de red) y viceversa, por tanto, el controlador
60 virtual IVI está dispuesto en modo inverso al flujo de
comunicación real para que las operaciones de las capas nº 2.1 y nº
2.2 reales sean transparentes al controlador intermedio (IVI): el
controlador 64 NIC virtual IVI (una capa similar a la nº 2.1) está
colocada "entre" la capa nº 2.2 real y el controlador 62 de
transporte IVI (una capa similar a la nº 2.2) está colocado
"sobre" tantos controladores NIC reales como interfaces físicas
puedan utilizarse para la comunicación, puesto que el controlador 62
de transporte IVI puede controlar varios controladores NIC reales
para los diversos medios físicos empleados en la comunicación de
datos, comportándose para cada controlador NIC por debajo de él como
su "controlador de transporte". Por tanto, cuando el sistema
informático realiza operaciones de acuerdo con la capa nº 2.2, en
vez de ejecutarse las operaciones de la capa nº 2.1 en respuesta
directa a las llamadas de las operaciones de la capa nº 2.2, en su
lugar se realizan operaciones de la capa IVI 2.1. Del mismo modo,
cuando el sistema informático realiza operaciones de acuerdo con la
capa nº 2.1, en vez de ejecutarse las operaciones de la capa nº 2.2
en respuesta directa a las llamadas de las operaciones de la capa nº
2.1, en su lugar se realizan operaciones de la capa IVI 2.2. La capa
IVI 2.1 y la capa IVI 2.2 se comunican entre sí, salvando la
interacción de las capas nº 2.1 y nº 2.2. El controlador 62 de
transporte IVI incluye la capa IVI 2.2, la cual es capaz de
controlar dos controladores NIC y es por tanto un interruptor
bidireccional para transferir datos de una o varias interfaces
físicas/vías de comunicación a una sola dirección IP/capa real y
para transferir datos de una sola dirección IP/capa "real" a
una o varias interfaces físicas/vías de comunicación. Por tanto, el
módulo 60 IVI es un interruptor bidireccional para transferir datos
de una o varias interfaces físicas/vías de comunicación a una sola
dirección IP/capa nº 3 "real" y para transferir datos de una
sola dirección IP/capa nº 3 "real" a una o varias interfaces
físicas/vías de comunicación.
La configuración mostrada en la figura 3 muestra
el módulo 60 IVI, que tiene la interfaz superior subcapa nº 2.2 -
subcapa nº 2.1 y la interfaz inferior subcapa nº 2.2 - subcapa nº
2.1 para conectarse tanto a los controladores de transporte de red
como a los controladores NIC existentes. Sin embargo, no es
necesario que el módulo 60 IVI implemente nuevos protocolos para la
capa 2. En una realización, el sistema IVI implementa una interfaz
superior Ethernet II y varias interfaces inferiores. Si ha de
enviarse un cierto paquete de red a través de un adaptador de red
Ethernet, el paquete se envía al controlador inferior sin más
modificaciones. Si el adaptador a través del cual va a enviarse el
paquete no es un adaptador Ethernet, el módulo 60 IVI deshace la
acción de la subcapa nº 2.2 superior, es decir, la implementación
del protocolo Ethernet, e implementa un protocolo distinto de
subcapa nº 2.2.
Con referencia a las figuras 4 y 5, las cuatro
capas inferiores del modelo OSI con la arquitectura NDIS se muestran
con la inserción de una capa IVI. En la figura 4, la arquitectura
del sistema corresponde a nodos que ejecutan NDIS 3, tal como es el
caso de sistemas operativos como Windows 95. Debido a las
características de NDIS 3, las comunicaciones internas IVI entre el
controlador 62 de transporte IVI y el controlador 64 NIC virtual IVI
han de implementarse sorteando el entorno NDIS. En los nodos que
ejecutan NDIS 4, tal como es el caso de los sistemas Windows NT, las
comunicaciones internas IVI también pueden implementarse a través
del entorno NDIS, tal como se muestra en la figura 5. En la figura 6
se muestra un esquema de cómo se encapsulan los controladores
internos IVI, el controlador 62 de transporte IVI y el controlador
64 NIC virtual IVI en el caso de sistemas NDIS 3. Tanto el
controlador 62 de transporte IVI como el controlador 64 NIC virtual
IVI se comunican dentro del entorno del controlador 60' intermedio
IVI.
Toda la comunicación entre los controladores de
red NDIS es transportada por el sistema NDIS. Así que la realización
anterior, dos controladores de red distintos para el sistema IVI,
crea algunas operaciones auxiliares de sistema. En los sistemas NDIS
4.0, existe un nuevo tipo de adaptador de red llamado controlador
intermedio de red. Los controladores intermedios de red implementan
interfaces superiores subcapa nº 2.2 - subcapa nº 2.1 e interfaces
inferiores subcapa nº 2.2 - subcapa nº 2.1. El nuevo tipo de
controlador de red puede emplearse por tanto para implementar el
sistema IVI en sólo un controlador para sistemas NDIS 4.0,
reduciendo las operaciones auxiliares de sistema (los controladores
NIC virtuales y de transporte IVI no tienen que enviar paquetes de
unos a otros si son el mismo controlador). Esta es la razón por la
que, en los sistemas NDIS 4.0, el sistema IVI se implementa a través
del controlador 60' intermedio IVI, el cual encapsula la
funcionalidad tanto del controlador 62 de transporte IVI como del
controlador 64 NIC virtual IVI.
Con referencia a la figura 7, se ilustran las
primeras cuatro capas OSI y se muestra el flujo de datos procesado
por el controlador 60' intermedio IVI entre el controlador 70 de
transporte y dos controladores 72 NIC distintos y sus NIC 74
correspondientes. El número de direcciones IP procesadas por el
nivel IP por nodo en la arquitectura NDIS es el número de enlaces
entre el controlador 70 de transporte y el nivel inmediatamente
inferior. En la arquitectura NDIS "clásica", el nivel
inmediatamente inferior es el controlador NIC. Sin embargo, la
presente invención interpone el controlador intermedio IVI y sus
operaciones correspondientes entre el controlador 70 de transporte y
los controladores 72 NIC. Por tanto, aunque existen al menos dos NIC
74 reales y sus correspondientes controladores 72 NIC, el
controlador 70 de transporte sólo tiene un enlace con su nivel
inmediatamente inferior, el controlador 60' intermedio IVI, el cual
combina así varios NIC y sus controladores como una sola entidad
desde el punto de vista del controlador 70 de transporte. Esto
permite usar interfaces físicas unidireccionales que comienzan o
terminan canales de comunicación unidireccional (tales como canales
de TV digital/difusión de datos por satélite, fibra óptica/cable
coaxial o microondas) a usar para comunicaciones de datos
interactivas, siempre y cuando cada nodo tenga al menos una interfaz
de entrada de datos y una de salida de datos.
Con referencia a las figuras 8 y 9, desde el
punto de vista de los procesadores del sistema, el controlador 60
intermedio IVI ha combinado dos enlaces IF:A1 e IF:A2 físicos en un
solo cable 85 virtual bidireccional, identificando así a cada nodo
por una sola dirección de red (dirección IP en TCP/IP), a pesar del
hecho de que, desde el punto de vista de los enlaces físicos, se
emplean dos interfaces IF:A1 e IF:A2 físicas (la interfaz A y la
interfaz B) diferentes por nodo: una para cada enlace de
comunicación. La interfaz 60 IVI funciona basándose en la diferencia
entre un controlador de una interfaz y la interfaz real. Cuando un
procesador 80 del sistema necesita leer/escribir de/en una interfaz
(una interfaz de red), el procesador del sistema lee/escribe de/en
el controlador (controlador de interfaz). Esta operación de
controlador es implementada por un software (el controlador de
interfaz) que controla el sistema informático para escribir y leer
los datos en y de la interfaz real. El sistema IVI pasa una entrada
de datos (DI) procedente de la interfaz A real directamente del
controlador A al controlador 60 IVI (controlador NDIS). El
procesador 80 del sistema sólo puede leer y escribir de y en un
controlador, no una interfaz. Por tanto, el procesador 80 del
sistema lee los datos en el controlador 60 IVI. A continuación, los
datos se procesan como si procediesen de la interfaz 60 IVI, que
tiene una sola dirección ID:C IP asociada, aunque hay dos interfaces
subyacentes, IF:A, para recibir datos, e IF:B, para transmitir
datos. Para la transmisión de datos, los datos del procesador 80 se
envían al controlador 60 IVI, que actúa como si hubiese escrito los
datos en la interfaz IVI, que no existe físicamente, pero es emulada
por operaciones máquina que efectúan una simulación informática de
una interfaz bidireccional real de acuerdo con el controlador 60
IVI. En realidad, el controlador 60 IVI escribe los datos en
("pasa los datos a") el controlador de la interfaz B, que a su
vez coloca los datos en la interfaz B real.
El controlador 60 IVI se controla desde cualquier
aplicación estándar a través de la pila de protocolo y los
controladores del sistema de archivos que operan en una arquitectura
NDIS, tal como se muestra en la figura 10. Más específicamente, está
controlado por un controlador 66 IVI, el cual es una aplicación
escrita para gestionar un servicio IVI, como un acceso a Internet de
alta velocidad, junto con TV digital desde un receptor decodificador
integrado IV, tal como se muestra en la figura 11, desde una base de
datos o desde la información transmitida desde otro nodo.
Con referencia a la figura 12, la presente
invención también prevé la capacidad de combinar tantos
controladores IVI como se deseen, utilizando todos dos interfaces de
red reales para cada uno. Las interfaces de red reales pueden
pertenecer a varios controladores IVI en el sistema de la figura 12;
hay 4 controladores IVI y por tanto 4 direcciones IP para el
procesador del sistema:
1. IVI1. ID: 194.2.1.1. Este controlador
identifica un sistema al que se accede empleando una línea
telefónica, y los datos del mismo se transmiten por difusión por
satélite.
2. IVI2. ID: 194.3.1.1. Este controlador
identifica un sistema al que se accede empleando una línea
telefónica, y los datos del mismo se transmiten por "cable"
(normalmente, una red de distribución híbrida de fibra óptica/cable
coaxial).
3. IVI3. ID: 194.4.1.1. Este controlador
identifica un sistema al que se accede empleando una línea
telefónica, y los datos del mismo son transmitidos por un sistema de
difusión MMDS/LMDS.
4. IVI4. ID: 194.5.1.1. Este controlador
identifica un sistema al que se accede empleando una línea
telefónica, y los datos del mismo se transmiten por la misma línea
telefónica.
Si el funcionamiento de los controladores 1, 2 y
3 IVI se interrumpe porque el sistema de difusión no funciona o se
encontró un gran número de errores, el sistema pasa automáticamente
al controlador 4 IVI, el cual proporciona una capacidad de
tolerancia de fallos de apoyo que resulta muy valiosa para
comunicaciones críticas.
Por último, la figura 13 resume un conjunto
completo de aplicaciones/módulos basados en la noción IVI para
proporcionar una funcionalidad plena a los servicios comerciales que
implican conexiones de red de datos asimétricas de alta
velocidad.
Con referencia a la figura 14, se muestra el
funcionamiento de un servicio de acceso rápido a Internet,
proporcionado por un proveedor de servicios de TV digital, que
emplea uno o varios de los siguientes medios de transmisión de
difusión unidireccional para las comunicaciones descendentes: fibra
óptica/cable coaxial, satélite, MMDS. El PC 70 de usuario recibe los
datos de Internet en casa (a velocidades de hasta varios Mbps) de un
puerto de datos en un receptor DVB decodificador integrado de TV
digital estándar. Para las comunicaciones ascendentes (canal de
retorno), se utiliza la línea telefónica con un módem estándar
(también podría ser X.25 o una línea de retransmisión de tramas para
un usuario corpora-
tivo).
tivo).
Cuando comienzan las operaciones (el caso A en la
figura 15), una vía física, por ejemplo, una línea 74 telefónica, se
utiliza bidireccionalmente, y la conexión se establece como una
conexión normal con unas direcciones ID:C1 y ID:C2 IP privadas.
Cuando se identifica al usuario como un usuario especial con dos
vías de comunicación diferentes para enviar datos/solicitudes y
recibir datos por una línea telefónica y conexiones por
satélite/cable/microondas, entonces el sistema IVI intenta abrir una
segunda interfaz real según el medio 75 de banda ancha específico
para cada usuario (un abonado de un servicio de satélite, un abonado
de MMDS, etc.), y si tiene éxito, se establece la comunicación
bidireccional que utiliza dos vías 74 y 75 físicas para las
comunicaciones en régimen permanente, tal como se muestra en el caso
B en la figura 15 (dos vías diferentes establecidas), dotando al
usuario de la recepción de datos a alta velocidad proporcionada por
el canal de banda ancha para la información solicitada del
servidor.
Si la vía 75 de difusión está cortada, entonces
el sistema pasa a la configuración del caso A, en la que la
velocidad normalmente es inferior a la proporcionada por la
configuración bidireccional del caso B, pero el sistema funciona sin
que el usuario pierda la conexión.
Con referencia a la figura 16, cuando el cliente
solicita una información IU, ésta es recogida por el propio
procesador 80b. Según la clase de servicio preestablecida por el
usuario (tipo de prioridad, ancho de banda contratado, etc.), el
ancho de banda solicitado por todos los usuarios conectados en
cualquier momento dado y ancho de banda total disponible para todos
los usuarios, el procesador 80a asigna una ranura de tiempo en el
múltiplex de datos a difundir para cada usuario a fin de garantizar
un rendimiento final según las respectivas características de
servicio de los usuarios. La cuenta de facturación para cada usuario
conectado se actualiza en este instante, si el servicio se factura
según el tiempo de conexión o las cantidades de datos
solicitadas.
La operación anterior se realiza integrando un
sistema con capacidades de gestión de ancho de banda (tal como un
conmutador ATM) con una aplicación de base de datos (con la
información necesaria sobre los usuarios, canales, ancho de banda,
etc., que trabaja en tiempo real) y el sistema IVI. En el nodo
cliente, no hay gestión del ancho de banda (la gestión del ancho de
banda se ejecuta en el nodo servidor), pero resulta posible asignar
un canal específico al usuario final a fin de realizar una
distribución eficiente del tráfico empleando todos los canales
disponibles.
Cuando el ancho de banda garantizado para todos
los usuarios conectados sobrepasa la capacidad de difusión total,
puede producirse un desbordamiento en algunos instantes de tiempo.
Este evento puede predecirse mediante modelos estadísticos, y en
estos casos, el recurso saturado se reasigna a los diferentes
usuarios según sus niveles de prioridad, distribuyendo uniformemente
la producción inferior entre usuarios con la misma clase de servicio
y realizando al mismo tiempo correcciones (bonificaciones,
descuentos) en las cantidades facturadas a los usuarios.
Con referencia a la figura 17, se describe el
funcionamiento del controlador 62 de transporte IVI en un entorno
NDIS 3. Cuando ha de enviarse un paquete de datos a la red, el
controlador 64 NIC virtual IVI lo envía al controlador 62 de
transporte IVI. En la etapa 110 se detecta si un paquete de datos
está listo, la cual se reejecuta en el caso de que ningún paquete
esté listo. Cuando un paquete de datos está listo, en la etapa 112
se determina si procede del controlador 64 NIC virtual IVI. El
controlador 64 NIC virtual IVI tiene una tabla con información sobre
distintos intervalos de direcciones de red. Cuando la etapa 112 es
afirmativa, entonces en la etapa 114 se determina si la dirección de
red a la que ha de enviarse el paquete está en la tabla. Si la
dirección de red no se encuentra en ninguno de los intervalos
incluidos en la tabla, el controlador 64 NIC virtual IVI selecciona
un NIC por defecto en la etapa 116 y envía el paquete al NIC por
defecto en la etapa 118. El NIC por defecto se determina en el
proceso de instalación. Si la dirección está dentro de uno de los
intervalos de direcciones de red contenidos en la tabla, el
controlador 64 NIC virtual IVI busca en la tabla el adaptador al que
hay que enviar el paquete, y selecciona el adaptador adecuado en la
etapa 120. Esta elección depende de la lista de adaptadores a través
de los cuales puede contactarse con esa dirección y el estado
(funciona/no funciona) de esos adaptadores. Cuando el adaptador por
el que está enviándose el paquete no es el NIC por defecto, en la
etapa 122 se modifica la cabecera y/o la cola de la subcapa nº 2.2
en el paquete para que correspondan
a las del adaptador, y en la etapa 118 se envían al adaptador.
a las del adaptador, y en la etapa 118 se envían al adaptador.
Cuando se recibe un paquete de la red, un
controlador de adaptador de red lo envía al controlador 62 de
transporte IVI. Esto tiene como resultado un resultado negativo en
la etapa 112. El controlador 62 de transporte IVI determina entonces
en la etapa 124 si el paquete ha venido del NIC por defecto. Si el
paquete procede del NIC por defecto, el controlador 62 de transporte
IVI sencillamente lo envía al controlador 64 NIC virtual IVI en la
etapa 126. Si el adaptador del que vino el paquete no es el NIC por
defecto, en la etapa 128 se modifica la cabecera y/o la cola de la
subcapa nº 2.2 en el paquete para que correspondan con las del NIC
por defecto, y luego se envían en la etapa 126 al controlador 64 NIC
virtual IVI.
Con referencia a la figura 18, el funcionamiento
del controlador 62 NIC virtual IVI se describe como viene a
continuación. Cuando ha de enviarse un paquete de datos a la red, un
controlador de transporte de red lo envía al controlador 64 NIC
virtual IVI a través del controlador 62 de transporte IVI. En la
etapa 130 se detecta si el paquete está listo, la cual se reejecuta
en el caso de que no esté listo ningún paquete. Cuando está listo un
paquete, en la etapa 132 se determina si el paquete procede del
controlador 62 de transporte IVI. Un resultado afirmativo en la
etapa 132 significa que el paquete ha de enviarse a la red, y el
controlador 64 NIC virtual IVI sencillamente envía el paquete al
controlador 62 de transporte IVI en la etapa 134, el cual a su vez
lo reenvía al (a los) correspondiente(s)
controlador(s) NIC real(es). Cuando se recibe un
paquete de la red, tal como queda determinado por un resultado
negativo en la etapa 132, el controlador 62 de transporte IVI lo
envía al controlador 64 NIC virtual IVI en la etapa 136, y el
controlador 64 NIC virtual IVI lo envía al controlador de transporte
de red apropiado.
Tras la instalación del sistema IVI en un
ordenador, existen dos modos de funcionamiento, un modo de reposo,
en el que el sistema IVI realiza una sencilla tarea de reenviar
datos, y un modo de conmutación, en el que el sistema IVI conmuta
datos a/desde las interfaces físicas deseadas.
Basándose en las operaciones anteriores descritas
con referencia a las figuras 17 y 18, resulta evidente que en el
modo de reposo, cuando hay que enviar un paquete de datos a la red,
un controlador de transporte de red lo envía al controlador 64 NIC
virtual IVI, el cual a su vez lo envía al controlador 62 de
transporte IVI para enviarlo al controlador de adaptador de red del
NIC por defecto. Por tanto, el rendimiento de la red es el mismo que
si el sistema IVI no estuviera instalado y el paquete se enviase
directamente del controlador de transporte de red al controlador de
adaptador de red del NIC por defecto. Por otra parte, cuando el
paquete llega de la red, el paquete es enviado al controlador 62 de
transporte IVI por el controlador de adaptador de red. El
controlador 62 de transporte IVI modifica el paquete para que
parezca que hubiese llegado a través del NIC por defecto y lo envía
al controlador 64 NIC virtual IVI para reenviarlo al controlador de
transporte de red apropiado. Por tanto, la entrada desde la red es
la misma que si el sistema IVI no estuviese instalado y el paquete
se hubiese recibido directamente del controlador de adaptador de red
del NIC por defecto y transferido a un controlador de transporte de
red (la única diferencia es que la(s) entrada(s) de
adaptadores distintos que el NIC por
defecto se envía/n a los controladores de transporte de red). En el modo de conmutación, el sistema IVI detecta si un paquete de datos ha de enviarse a través de, o se recibe de, un controlador NIC distinto que el NIC por defecto y modifica la cabecera y/o la cola tal como se ha tratado anteriormente, y cuando los datos han de enviarse a través de la red, elige un adaptador NIC apropiado distinto que el adaptador del NIC por defecto.
defecto se envía/n a los controladores de transporte de red). En el modo de conmutación, el sistema IVI detecta si un paquete de datos ha de enviarse a través de, o se recibe de, un controlador NIC distinto que el NIC por defecto y modifica la cabecera y/o la cola tal como se ha tratado anteriormente, y cuando los datos han de enviarse a través de la red, elige un adaptador NIC apropiado distinto que el adaptador del NIC por defecto.
Con referencia a la figura 19, el funcionamiento
del controlador 60' intermedio IVI en el entorno NDIS 4 comienza en
la etapa 140 con la determinación de si se detecta que un paquete de
datos está listo, la cual se reejecuta en el caso de que no esté
listo ningún paquete. Cuando hay que enviar un paquete a la red, un
controlador de transporte de red lo envía al controlador 60'
intermedio IVI. Por tanto, tras la detección de un paquete que está
listo, el controlador intermedio IVI determina a continuación en la
etapa 142 si el paquete procede de un controlador de transporte de
red. El controlador 60' intermedio IVI tiene una tabla con
información sobre diferentes intervalos de direcciones de red. Si el
resultado de la etapa 142 es afirmativo, en la etapa 144 se
determina si la dirección de red a la que ha de enviarse el paquete
está en la tabla. Si la dirección de red no está en ninguno de los
intervalos incluidos en la tabla, el controlador 62 de transporte
IVI selecciona un NIC por defecto en la etapa 146 y envía el paquete
al NIC por defecto en la etapa 148. El NIC por defecto se determina
en el proceso de instalación. Si la dirección de red se encuentra en
uno de los intervalos de direcciones de red contenidos en la tabla,
el controlador 62 de transporte IVI busca en la tabla el adaptador
al que ha de enviarse el paquete, y selecciona el adaptador
apropiado en la etapa 150. Esta elección depende de la lista de
adaptadores a través de los cuales puede conectarse a esa dirección
y el estado (funciona/no funciona) de esos adaptadores. Cuando el
adaptador por el que está enviándose el paquete no es el NIC por
defecto, en la etapa 152 se modifica la cabecera y/o la cola de la
subcapa nº 2.2 para que correspondan a las del adaptador, y en la
etapa 148 se envían al adaptador.
Cuando se recibe un paquete de la red, un
controlador de adaptador de red lo envía al controlador 60'
intermedio IVI. Esto tiene como resultado un resultado negativo en
la etapa 142. El controlador 60' intermedio IVI determina entonces
en la etapa 154 si el paquete ha venido del NIC por defecto. Si el
paquete procede del NIC por defecto, el controlador 60' intermedio
IVI sencillamente lo envía al controlador de transporte de red en la
etapa 156. Si adaptador del que vino el paquete no es el NIC por
defecto, en la etapa 158 se modifica la cabecera y/o la cola de la
subcapa nº 2.2 para que correspondan con las del NIC por defecto, y
luego se envían en la etapa 156 al controlador de adaptador de red.
Por tanto, el sistema resultante es similar a los sistemas IVI NDIS
3.0.
Con referencia de nuevo a las figuras 10 y 11, el
mecanismo empleado para controlar el sistema se obtiene mediante un
controlador 65 de dispositivo virtual IVI. El controlador 65 de
dispositivo virtual IVI crea un dispositivo virtual en el espacio de
nombre del sistema de archivos. Cualquier aplicación puede
comunicarse con el controlador 65 de dispositivo virtual IVI
mediante operaciones genéricas de lectura de archivos/escritura de
archivos. El controlador 65 de dispositivo virtual IVI trata
cualquier información
escrita en el controlador 65 de dispositivo virtual IVI como comandos, y las aplicaciones reciben una respuesta leyendo de ese dispositivo. Por ejemplo, cualquier aplicación con derechos de acceso apropiados podría escribir un "comando estadístico de pregunta" al dispositivo y, tras ello, leer el número de bytes/paquetes enviados a un cierto intervalo de direcciones de red.
escrita en el controlador 65 de dispositivo virtual IVI como comandos, y las aplicaciones reciben una respuesta leyendo de ese dispositivo. Por ejemplo, cualquier aplicación con derechos de acceso apropiados podría escribir un "comando estadístico de pregunta" al dispositivo y, tras ello, leer el número de bytes/paquetes enviados a un cierto intervalo de direcciones de red.
Tanto el controlador 65 de dispositivo virtual
IVI como el controlador 60' intermedio IVI están encapsulados en el
controlador 60 IVI. Al estar en el mismo controlador, el controlador
65 de dispositivo virtual IVI puede acceder a los datos de
controlador intermedio IVI, tal como la tabla de conmutación, las
estadísticas y la información de estado, etc. La aplicación
utilizada para controlar el sistema IVI escribiendo en/leyendo del
controlador 65 de dispositivo virtual IVI es el controlador 66
IVI.
Al producirse un arranque del sistema desde un
nodo cliente, el controlador 66 IVI comienza a escuchar a un
conector UDP en un puerto del servidor IVI (la dirección de red del
servidor IVI es suministrada por un usuario en el momento de la
instalación). El controlador 60 IVI trabaja en el modo de reposo
definido anteriormente. Siempre que al menos uno de los adaptadores
de red del controlador 60' intermedio IVI esté conectado a un
controlador de entrada de difusión, el nodo cliente podrá recibir
datos del nodo servidor a través del conector UDP. Si recibe un
comando del nodo servidor IVI que ordena al nodo cliente IVI que
abra la conexión, el controlador 66 IVI empieza el procedimiento de
apertura de conexión descrito más adelante. El sistema IVI está
configurado opcionalmente para pedir una configuración antes de
comenzar el procedimiento de apertura de conexión. El procedimiento
de apertura de conexión también puede abrirse mediante una solicitud
manual del usuario.
Al arrancarse el sistema desde un nodo servidor,
el controlador 66 IVI abre un conector UDP de salida utilizado para
enviar información a los nodos cliente IVI. El controlador 60 IVI
trabaja en el modo de reposo anteriormente definido. El usuario
puede ordenarle al controlador 66 IVI que envíe un comando para
ordenarle a un cierto nodo cliente IVI que empiece un procedimiento
de apertura de conexión descrito más adelante.
Una vez está abierta una conexión, el controlador
66 IVI le ordena al controlador 60' intermedio IVI a través del
controlador 65 de dispositivo virtual IVI que pase todos los
paquetes dirigidos al intervalo de direcciones de red del nodo
cliente IVI a un adaptador de red distinto que el NIC por defecto.
Hasta que se cierra la conexión, el controlador 66 IVI lee
periódicamente del controlador 60' intermedio IVI, a través del
controlador 65 de dispositivo virtual IVI, estadísticas sobre la
cantidad de paquetes enviados a o recibidos de ese intervalo de
direcciones de red.
El controlador 66 IVI utiliza una base 67 de
datos para almacenar información sobre los usuarios. La información
consiste en un identificador único profesional de cada nodo cliente
IVI (por ejemplo, el número de serie del receptor decodificador
integrado) utilizado para enviarle el comando de apertura de
conexión; información sobre el servicio IVI para ese cliente (ancho
de banda garantizado, lista de adaptador de salida a los que está
escuchando el nodo cliente IVI, direcciones físicas de adaptadores
de entrada de nodo cliente IVI, etc.); e información de facturación
(bytes/paquetes enviados/recibidos, número de conexiones, tiempo
total de conexión, etc.).
El nodo cliente IVI es siempre el que empieza el
procedimiento de "apertura de conexión" tras una solicitud de
cliente o una orden del nodo servidor IVI. Con referencia a la
figura 20, una primera etapa 160 es para abrir una conexión de red
estándar al servidor. Esta etapa es necesaria sólo si la
comunicación entre el nodo servidor IVI y el nodo cliente IVI es a
través de una WAN. Para abrir la conexión de red, el controlador 66
IVI en el nodo cliente IVI utiliza mecanismos estándar de sistema
operativo (conexión por llamada, por ejemplo). El sistema operativo
del nodo servidor IVI verifica el usuario y contraseña para
establecer la conexión de red estándar. El nodo servidor IVI empieza
a prestar servicio en la etapa 164 tras verificar el permiso de
entrada para el servicio. Una vez se abre una conexión de red
estándar al servidor, el controlador 66 IVI en el nodo cliente IVI
trata de abrir en la etapa 162 un servicio proporcionado por un
servicio encapsulado en el controlador 66 IVI en el nodo servidor
IVI, servicio de servidor IVI. El
mecanismo empleado para abrir el servicio de servidor IVI es el mecanismo estándar para hacer eso proporcionado por el sistema operativo (el sistema operativo comprueba los derechos de acceso del usuario sobre ese servicio a través del nombre de usuario empleado para abrir la conexión). El servidor IVI le ordena al controlador 66 IVI que comience a prestar servicio al nodo cliente IVI en la etapa 166 utilizando la información en la base de datos IVI para ese usuario. El controlador 60' intermedio IVI se configura entonces para proporcionar un servicio IVI en la etapa 168 basado en información obtenida de la base 67 de datos. El sistema trabaja entonces en el modo de conmutación definido anteriormente hasta que se cierra la conexión estándar entre el nodo servidor IVI y el nodo cliente IVI.
mecanismo empleado para abrir el servicio de servidor IVI es el mecanismo estándar para hacer eso proporcionado por el sistema operativo (el sistema operativo comprueba los derechos de acceso del usuario sobre ese servicio a través del nombre de usuario empleado para abrir la conexión). El servidor IVI le ordena al controlador 66 IVI que comience a prestar servicio al nodo cliente IVI en la etapa 166 utilizando la información en la base de datos IVI para ese usuario. El controlador 60' intermedio IVI se configura entonces para proporcionar un servicio IVI en la etapa 168 basado en información obtenida de la base 67 de datos. El sistema trabaja entonces en el modo de conmutación definido anteriormente hasta que se cierra la conexión estándar entre el nodo servidor IVI y el nodo cliente IVI.
Tras haberse descrito las realizaciones
preferidas de la invención con referencia a los dibujos adjuntos,
debe entenderse que la invención no se limita a esas realizaciones
específicas y que un experto en la técnica puede efectuar varios
cambios y modificaciones en la misma sin apartarse del alcance de la
invención tal como se define en las reivindicaciones adjuntas.
Claims (6)
1. Aparato para ejecutar una comunicación
bidireccional entre más de dos redes, en el que el aparato tiene un
procesador y memoria, estando configurado el aparato para ejecutar
operaciones de acuerdo con el modelo OSI ISO para las comunicaciones
de datos que incluye medios de la capa nº 3 de red, en el nivel IP
en TCP/IP, para ejecutar un conjunto de operaciones de capa de red
para conmutar comunicaciones de más de dos redes;
caracterizado porque el aparato incluye un medio (60)
intermedio de capa para transferir datos de un sola capa de red de
identificador IP a al menos una interfaz física perteneciente a una
capa inmediatamente inferior y viceversa utilizando un solo
identificador IP de capa de red y varias interfaces físicas de la
capa nº 2 inferior en paralelo.
2. Aparato según la reivindicación 1, en el que
el medio (60) intermedio de capa es un interruptor
bidireccional.
3. Aparato según la reivindicación 2, en el que
el medio (60) intermedio de capa se encuentra dentro de la capa nº
2, entre las subcapas de dicha capa nº 2.
4. Aparato según la reivindicación 3, en el que
el medio (60) intermedio de capa está adaptado para comunicarse con
una capa superior intermedia y una capa inmediatamente inferior
perteneciente a un modelo OSI.
5. Aparato según la reivindicación 1, en el que
cada interfaz física está asociada con una vía de comunicación
disponible de una red de comunicación.
6. Aparato según la reivindicación 5, en el que
cada vía de comunicación disponible puede pertenecer a una red de
comunicación diferente con un ancho de banda diferente.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES9602244 | 1996-10-23 | ||
| ES9602244 | 1996-10-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2244012T3 true ES2244012T3 (es) | 2005-12-01 |
Family
ID=8296467
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES97950022T Expired - Lifetime ES2244012T3 (es) | 1996-10-23 | 1997-10-23 | Aparato para integracion de varios medios fisicos para comunicacion de datos. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6377992B1 (es) |
| EP (1) | EP0944981B1 (es) |
| AT (1) | ATE298959T1 (es) |
| AU (1) | AU5313498A (es) |
| DE (1) | DE69733658D1 (es) |
| ES (1) | ES2244012T3 (es) |
| WO (1) | WO1998018247A1 (es) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09510596A (ja) * | 1994-06-08 | 1997-10-21 | エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス | ハイブリッドネットワークアクセスのための装置および方法 |
| US6701370B1 (en) | 1994-06-08 | 2004-03-02 | Hughes Electronics Corporation | Network system with TCP/IP protocol spoofing |
| US6339087B1 (en) | 1997-08-18 | 2002-01-15 | Syntex (U.S.A.) Llc | Cyclic amine derivatives-CCR-3 receptor antagonists |
| US6484210B1 (en) | 1997-11-10 | 2002-11-19 | General Instrument Corporation | Packet processing relay agent to provide link layer forwarding in one-way cable/wireless/satellite modems |
| US20010052084A1 (en) * | 1998-11-10 | 2001-12-13 | Jiandoug Huang | Apparatus and methods for providing fault tolerance of networks and network interface cards |
| US6934255B1 (en) * | 1999-02-02 | 2005-08-23 | Packeteer, Inc. | Internet over satellite apparatus |
| US6970473B1 (en) * | 1999-02-18 | 2005-11-29 | Sony Corporation | Communication method and communication apparatus |
| GB2348787B (en) * | 1999-04-10 | 2003-10-29 | Roke Manor Research | Improvements in or relating to data transmission |
| GB9918043D0 (en) | 1999-07-30 | 1999-10-06 | Nokia Telecommunications Oy | Internal roaming |
| US7177952B1 (en) * | 1999-10-01 | 2007-02-13 | Nortel Networks Limited | Method and system for switching between two network access technologies without interrupting active network applications |
| US6983330B1 (en) * | 1999-12-29 | 2006-01-03 | Emc Corporation | Method and apparatus for using multiple paths for processing out of band commands |
| BR0109068B1 (pt) * | 2000-03-08 | 2013-12-31 | Método para aglomerar e sinterizar minério e concentrados de minério de ferro e zinco, resíduo ferroso da usina de aço e resíduo da usina de zinco | |
| US6895403B2 (en) * | 2000-03-31 | 2005-05-17 | James Cardwell | Method and software for identifying and creating connections and accountability in a business organization |
| DE60144335D1 (de) * | 2000-08-31 | 2011-05-12 | Goldpocket Interactive Inc | Systeme und verfahren für die interaktion mit benutzern in einem kommunikationsnetzwerk |
| JP2002215585A (ja) * | 2000-11-16 | 2002-08-02 | Fuji Xerox Co Ltd | 個人証明書サブジェクト名処理装置および方法 |
| JP2005500720A (ja) * | 2001-06-05 | 2005-01-06 | マルコニ インテレクチュアル プロパティー （リングフェンス） インコーポレイテッド | イーサネット保護システム |
| US7991006B2 (en) * | 2001-08-02 | 2011-08-02 | Oracle America, Inc. | Filtering redundant packets in computer network equipments |
| US7213044B2 (en) * | 2001-08-31 | 2007-05-01 | Microsoft Corporation | Point-to-point data communication implemented with multipoint network data communication components |
| US7653736B2 (en) * | 2001-12-14 | 2010-01-26 | Nxp B.V. | Data processing system having multiple processors and a communications means in a data processing system |
| US6963932B2 (en) * | 2002-01-30 | 2005-11-08 | Intel Corporation | Intermediate driver having a fail-over function for a virtual network interface card in a system utilizing Infiniband architecture |
| US7447778B2 (en) | 2002-05-06 | 2008-11-04 | Qlogic, Corporation | System and method for a shared I/O subsystem |
| US7356608B2 (en) * | 2002-05-06 | 2008-04-08 | Qlogic, Corporation | System and method for implementing LAN within shared I/O subsystem |
| US7404012B2 (en) * | 2002-05-06 | 2008-07-22 | Qlogic, Corporation | System and method for dynamic link aggregation in a shared I/O subsystem |
| US7127601B2 (en) * | 2002-05-30 | 2006-10-24 | Sun Microsystems, Inc. | System and method for delivering FPGA programming |
| US7076787B2 (en) * | 2002-05-30 | 2006-07-11 | Sun Microsystems, Inc. | Supporting multiple protocols with a single device driver |
| US20030225916A1 (en) * | 2002-05-30 | 2003-12-04 | David Cheon | Implementing a data link layer protocol for multiple network interface devices |
| US7636371B2 (en) * | 2002-12-27 | 2009-12-22 | Intel Corporation | Communication subsystem for wireless devices or the like |
| US20040203739A1 (en) * | 2003-01-22 | 2004-10-14 | Jun Li | Mobile communication system |
| US7321555B2 (en) * | 2003-04-16 | 2008-01-22 | International Business Machines Corporation | Multilevel analysis of self-similar network traffic |
| CN100574259C (zh) * | 2003-05-08 | 2009-12-23 | 日本电信电话株式会社 | 通信控制方法和通信控制设备 |
| US7132953B2 (en) * | 2003-06-26 | 2006-11-07 | Lear Corporation | Spring sensor assembly for a vehicle seat cushion |
| US7839843B2 (en) * | 2003-09-18 | 2010-11-23 | Cisco Technology, Inc. | Distributed forwarding in virtual network devices |
| US7751416B2 (en) | 2003-09-18 | 2010-07-06 | Cisco Technology, Inc. | Virtual network device |
| US7363600B1 (en) | 2003-10-21 | 2008-04-22 | Xilinx, Inc. | Method of simulating bidirectional signals in a modeling system |
| US8526427B1 (en) | 2003-10-21 | 2013-09-03 | Cisco Technology, Inc. | Port-based loadsharing for a satellite switch |
| US8990430B2 (en) | 2004-02-19 | 2015-03-24 | Cisco Technology, Inc. | Interface bundles in virtual network devices |
| US8208370B1 (en) | 2004-03-31 | 2012-06-26 | Cisco Technology, Inc. | Method and system for fast link failover |
| US7889733B2 (en) * | 2004-04-28 | 2011-02-15 | Cisco Technology, Inc. | Intelligent adjunct network device |
| US7710957B2 (en) * | 2004-05-19 | 2010-05-04 | Cisco Technology, Inc. | System and method for implementing multiple spanning trees per network |
| US7706364B2 (en) * | 2004-05-19 | 2010-04-27 | Cisco Technology, Inc. | Virtual network device clusters |
| US7436836B2 (en) * | 2004-06-30 | 2008-10-14 | Cisco Technology, Inc. | Method and apparatus for detecting support for a protocol defining supplemental headers |
| US7808983B2 (en) | 2004-07-08 | 2010-10-05 | Cisco Technology, Inc. | Network device architecture for centralized packet processing |
| US9264384B1 (en) | 2004-07-22 | 2016-02-16 | Oracle International Corporation | Resource virtualization mechanism including virtual host bus adapters |
| US8730976B2 (en) * | 2004-08-17 | 2014-05-20 | Cisco Technology, Inc. | System and method for preventing erroneous link aggregation due to component relocation |
| US7873683B2 (en) * | 2005-07-01 | 2011-01-18 | Qnx Software Systems Gmbh & Co. Kg | File system having transaction record coalescing |
| US8959125B2 (en) * | 2005-07-01 | 2015-02-17 | 226008 Ontario Inc. | File system having inverted hierarchical structure |
| US7809777B2 (en) * | 2005-07-01 | 2010-10-05 | Qnx Software Systems Gmbh & Co. Kg | File system having deferred verification of data integrity |
| US7970803B2 (en) * | 2005-07-01 | 2011-06-28 | Qnx Software Systems Gmbh & Co. Kg | Optimized startup verification of file system integrity |
| US9813283B2 (en) | 2005-08-09 | 2017-11-07 | Oracle International Corporation | Efficient data transfer between servers and remote peripherals |
| US7515596B2 (en) * | 2006-06-30 | 2009-04-07 | Sun Microsystems, Inc. | Full data link bypass |
| DE102006037243B4 (de) * | 2006-08-09 | 2010-06-02 | Siemens Ag | Netzwerk zur drahtlosen Übertragung von Daten |
| US20080059510A1 (en) * | 2006-08-31 | 2008-03-06 | Daniel Cardamore | Multimedia system framework having layer consolidating access to multiple media devices |
| US8566503B2 (en) * | 2006-08-25 | 2013-10-22 | Qnx Software Systems Limited | Multimedia filesystem having unified representation of content on diverse multimedia devices |
| US7908276B2 (en) | 2006-08-25 | 2011-03-15 | Qnx Software Systems Gmbh & Co. Kg | Filesystem having a filename cache |
| KR100826670B1 (ko) * | 2006-11-16 | 2008-05-02 | 한국전자통신연구원 | Ｉｐ 이동성 지원을 위한 이동 단말의 터널링 방법 |
| US20080147747A1 (en) * | 2006-12-14 | 2008-06-19 | Dan Cardamore | Media system having synchronization with preemptive prioritization of synchronization order |
| CN102006334B (zh) * | 2007-06-11 | 2013-01-02 | 华为技术有限公司 | 安装软件组件的方法、系统及装置 |
| US7917614B2 (en) * | 2008-06-10 | 2011-03-29 | International Business Machines Corporation | Fault tolerance in a client side pre-boot execution |
| US9973446B2 (en) | 2009-08-20 | 2018-05-15 | Oracle International Corporation | Remote shared server peripherals over an Ethernet network for resource virtualization |
| US8717878B2 (en) * | 2010-03-25 | 2014-05-06 | Canon Kabushiki Kaisha | Providing feedback information when network streaming over multiple physical interfaces |
| US8369349B2 (en) * | 2010-03-25 | 2013-02-05 | Canon Kabushiki Kaisha | Network streaming over multiple physical interfaces using feedback information |
| US8375139B2 (en) | 2010-06-28 | 2013-02-12 | Canon Kabushiki Kaisha | Network streaming over multiple data communication channels using content feedback information |
| US9331963B2 (en) * | 2010-09-24 | 2016-05-03 | Oracle International Corporation | Wireless host I/O using virtualized I/O controllers |
| US9083550B2 (en) | 2012-10-29 | 2015-07-14 | Oracle International Corporation | Network virtualization over infiniband |
| US10803044B1 (en) | 2017-03-07 | 2020-10-13 | The United States Of America, As Represented By The Secretary Of The Navy | Technical data flexibility index |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4793813A (en) * | 1985-10-15 | 1988-12-27 | The Board Of Trustees Of The University Of Illinois | Computer-based education system |
| JPH09510596A (ja) * | 1994-06-08 | 1997-10-21 | エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス | ハイブリッドネットワークアクセスのための装置および方法 |
| US5659615A (en) * | 1994-11-14 | 1997-08-19 | Hughes Electronics | Secure satellite receive-only local area network with address filter |
| US5925117A (en) * | 1994-12-28 | 1999-07-20 | Intel Corporation | Method and apparatus for enabling application programs to continue operation when an application resource is no longer present after undocking from a network |
| US5586121A (en) * | 1995-04-21 | 1996-12-17 | Hybrid Networks, Inc. | Asymmetric hybrid access system and method |
| US6041356A (en) * | 1997-03-31 | 2000-03-21 | Intel Corporation | Method and apparatus for detecting network traffic and initiating a dial-up connection using separate upstream and downstream devices |
-
1997
- 1997-10-23 EP EP97950022A patent/EP0944981B1/en not_active Expired - Lifetime
- 1997-10-23 ES ES97950022T patent/ES2244012T3/es not_active Expired - Lifetime
- 1997-10-23 US US08/956,562 patent/US6377992B1/en not_active Expired - Fee Related
- 1997-10-23 WO PCT/EP1997/005867 patent/WO1998018247A1/en active IP Right Grant
- 1997-10-23 AT AT97950022T patent/ATE298959T1/de not_active IP Right Cessation
- 1997-10-23 AU AU53134/98A patent/AU5313498A/en not_active Abandoned
- 1997-10-23 DE DE69733658T patent/DE69733658D1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO1998018247A1 (en) | 1998-04-30 |
| EP0944981B1 (en) | 2005-06-29 |
| EP0944981A1 (en) | 1999-09-29 |
| ATE298959T1 (de) | 2005-07-15 |
| US6377992B1 (en) | 2002-04-23 |
| WO1998018247B1 (en) | 2001-04-12 |
| DE69733658D1 (de) | 2005-08-04 |
| AU5313498A (en) | 1998-05-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2244012T3 (es) | Aparato para integracion de varios medios fisicos para comunicacion de datos. | |
| CN203206278U (zh) | 通用网络接口控制器 | |
| US7039720B2 (en) | Dense virtual router packet switching | |
| US7242665B2 (en) | Network device virtual interface | |
| US20030018828A1 (en) | Infiniband mixed semantic ethernet I/O path | |
| US7093024B2 (en) | End node partitioning using virtualization | |
| US7233570B2 (en) | Long distance repeater for digital information | |
| US7633937B2 (en) | Methods and apparatus for switching between Metro Ethernet networks and external networks | |
| US6584109B1 (en) | Automatic speed switching repeater | |
| CN113169928A (zh) | 包括分解式网络元件的逻辑路由器 | |
| WO1998018247A9 (en) | Method and system for integration of several physical media for data communications | |
| JPH0619785A (ja) | 分散共有仮想メモリーとその構成方法 | |
| ES2244557T3 (es) | Central de conmutacion modular y escalable y metodo para la distribucion de tramas de datos en una red ethernet rapida. | |
| US20100002714A1 (en) | PCI express network | |
| US12072823B2 (en) | Flexible high-availability computing with parallel configurable fabrics | |
| JPH0851468A (ja) | ネットワークにおける分散処理用アプリケーションプログラミングインタフェース | |
| Cisco | Release Notes for Cisco IOS Release 11.2 P | |
| Cisco | Release Notes for Cisco IOS Release 11.2 P | |
| Cisco | Release Notes for Cisco IOS Release 11.2 P | |
| Cisco | Release Notes for Cisco IOS Release 11.2 P | |
| Cisco | Release Notes for Cisco IOS Release 11.2 BC | |
| Cisco | Release Notes for Cisco 3600 Series For Cisco IOS Release 11.2P | |
| Cisco | Rel Notes for Cisco 2500 Series Routers/Cisco IOS Rel 11.2(12) | |
| Cisco | Rel Notes for Cisco 1000 Series Routers/Cisco IOS Rel 11.2(12) | |
| Cisco | Release Notes for Cisco IOS Release 11.2 BC |