ES2340954T3 - Motor multi-protocolo para procesamiento de corriente de bits reconfigurable en redes de alta velocidad. - Google Patents
Motor multi-protocolo para procesamiento de corriente de bits reconfigurable en redes de alta velocidad. Download PDFInfo
- Publication number
- ES2340954T3 ES2340954T3 ES06802072T ES06802072T ES2340954T3 ES 2340954 T3 ES2340954 T3 ES 2340954T3 ES 06802072 T ES06802072 T ES 06802072T ES 06802072 T ES06802072 T ES 06802072T ES 2340954 T3 ES2340954 T3 ES 2340954T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- processor
- stage
- protocol
- bit
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
- G06F13/385—Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices
-
- 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/12—Protocol engines
-
- 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Abstract
Un motor de procesamiento de paquete de datos multi-protocolo para manejar comunicación de paquete de paquetes de datos entre un procesador y una producción/estructura de red de alta velocidad que tiene una velocidad de línea de al menos 10 Gb/segundo, el motor de procesamiento de paquete de datos comprende: una porción de ingreso del motor de procesamiento de paquete de datos que incluye: una pluralidad de procesadores de etapa de corriente de bit de ingreso, cada procesador de etapa de corriente de bit de ingreso tiene una memoria de control programable única para aquel procesador de etapa de corriente de bit de ingreso; una interfase de procesador de ingreso al procesador; una interfase de red de ingreso a la producción de red; y una memoria de paquete de flujo de datos multi-puerto operablemente conectada a la pluralidad de procesadores de etapa de corriente de bit de ingreso, la interfase de procesador de ingreso y la interfase de red de ingreso; y una porción de egreso del motor de procesamiento de paquete de datos que incluye: una pluralidad de procesadores de etapa de corriente de bit de egreso, cada procesador de etapa de corriente de bit de egreso tiene una memoria de control programable única a aquella del procesador de etapa de corriente de bit de egreso; una interfase de procesador de egreso al procesador; una interfase de red de egreso a la producción de red; y una memoria de paquete de flujo de datos multi-puerto operablemente conectada a la pluralidad de procesadores de etapa de corriente de bit de egreso, la interfase del procesador de egreso y la interfase de red de egreso; en donde la memoria de control de cada uno de los procesadores de etapa de corriente de bit es individualmente, selectivamente, dinámicamente programable con base en una de una pluralidad de protocolos determinados para un flujo de datos dado de uno o más paquetes de datos y el proceso de los procesadores de etapa de corriente de bit del flujo de datos dado como un flujo de los datos de corriente de bit a través de la memoria de paquete de flujo de datos multi-puerto de tal manera que el procesamiento del flujo de datos dado por la pluralidad de procesadores de etapa de corriente de bit es temporizado de acuerdo al flujo de datos de corriente de bit y el flujo de datos de corriente de bit se establece a una velocidad que posibilita la operación continua del motor de procesamiento de paquete de datos para toda la pluralidad de protocolos sustancialmente a una velocidad que es al menos igual a la velocidad de línea de la producción de red de alta velocidad.
Description
Motor multi-protocolo para
procesamiento de corriente de bits reconfigurable en redes de alta
velocidad.
La presente invención se relaciona de manera
general con el campo de las comunicaciones de datos en una red. Más
específicamente, la presente invención se relaciona con un motor de
procesamiento de corriente de bits indiferente del protocolo
reconfigurable, y con sistemas relacionados y metodologías de
comunicación de datos, adaptadas para redes de alta velocidad que
operan a velocidades de al menos 10 gigabits por segundo.
Tradicionalmente, las redes se han dividido en
diferentes clases de infraestructuras o estructuras basadas en el
propósito de una red dada. Como resultado, se han desarrollado
diferentes clases de redes para almacenar redes, redes de
comunicación y redes de procesador, que tiene cada una diferentes
protocolos y diferentes requisitos de red y cada designado para
cumplir con requisitos particulares de comunicación de datos en esa
estructura.
En el caso de redes de procesador, el desempeño
de la red es un elemento crítico en aplicaciones de computo de
controladores de alto desempeño (HPCC). Típicamente, las
aplicaciones HPCC corren durante períodos extendidos de tiempo y
requieren I/O sostenidos de conjuntos de datos grandes sobre la red
entre los procesadores así como también entre el cliente y el
servidor. De manera predecible, la infraestructura debe ser capaz de
soportar servicios de ancho de banda multi-gigabit,
de baja latencia, muy altamente disponibles que son un requisito
absoluto para comunicaciones interproceso de gama alta.
Convencionalmente, las redes HPCC utilizan Ethernet de Gigabit
Conmutado. Los protocolos de propietario tales como, por ejemplo,
Myrinet, InfiniBand y Quadrics también encuentran un uso amplio al
conectar controladores de procesamiento en un ambiente HPCC.
La necesidad de cantidad es masivas de datos
necesita que los procesadores en red en una aplicación HPCC, por
ejemplo, estén eficientemente conectados a una estructura de red de
almacenamiento. convencionalmente, el HPCC que soporta la
infraestructura incluye una red anexada de almacenamiento (SAN) que
conmuta la estructura tal como un interruptor de Canal de Fibra, o
una red basada en Ethernet de Gigabit unida a amiente de
almacenamiento (NAS). El Canal de Fibra es el protocolo dominante y
el transporte para una estructura SAN en razón de las velocidades
multi-gigabit y los protocolos de transporte que se
optimizan para mover cantidades masivas de datos de almacenamiento
de bloque entre clientes y dispositivos de almacenamiento.
Las redes de comunicación con Protocolo de
Internet (IP) tienden a dominar la estructura para comunicaciones
entre diferentes aplicaciones HPCC, así como también las
comunicaciones generales entre clientes y servidores sobre una
estructura de Internet más amplia. Algunas redes de almacenamiento
han adoptado protocolos "piggyback" adecuados para mover datos
de almacenamiento de bloque sobre redes de almacenamiento IP tales
como SCSI Internet (iSCSI), Protocolo de Canal de Fibra de Internet
(iFCP), y Canal de Fibra sobre IP (FCIP). Estos protocolos
"piggyback", sin embargo, no permiten necesariamente la
inter-operabilidad directa entre las redes de
comunicaciones y las redes de almacenamiento.
La meta de suministrar interoperabilidad entre
estructuras a través de estas diferentes clases de estructuras de
red es una meta bien conocida. Aunque esta meta se puede lograr
directamente en el contexto de redes de baja velocidad en donde
todo el procesamiento requerido en la red se podría lograr con
procesadores programables estándar, tal solución simplemente no es
viable en altas velocidades de comunicación requeridas que operan a
10 gigabits por segundo y superiores. Para la mayor parte, los
adaptadores especializados se han utilizado para hacer la
transición entre un protocolo específico en la estructura y un
protocolo común en un nodo interruptor central. Aunque esta
aproximación puede ser transparente para el usuario final, es
fácilmente evidente para un experto en la técnica de que tal como
cuadros de adaptadores presentes en un problema de explosión
exponencial en términos del número de protocolos siempre
crecientes. La capacidad de suministrar un conmutador de red de
alta velocidad que sería capaz de manejar múltiples protocolos es
una solución que al menos algunos elaboradores de equipo de red no
creen que sea posible. Silvano Gai, "Toward a unified architecture
for LAN/WAN/WLAN/SAN suites and routers", pp. 23, HSPR 2003,
Cisco Systems, Inc. (notar la no disponibilidad de un conmutador LAN
barato de 10 Gb/s). De acuerdo con esto, subsiste la necesidad de
encontrar una solución a la meta de suministrar interoperabilidad
interestructura entre redes que sean tanto eficientes como
escalables para redes de alta velocidad.
El documento WO 2004/013759 describe porciones
de ingreso/egreso de datos un motor de procesamiento de paquete que
comprende procesadores independientes conectados en un cable de
datos.
La presente invención suministra un motor de
procesamiento de corriente de bits indiferente del protocolo
reconfigurable, y sistemas relacionados y metodologías de
comunicación de datos, que se adaptan para lograr la meta de
suministrar interoperabilidad inter-estructura entre
redes de alta velocidad que operan a velocidades de al menos 10
gigabits por segundo. El motor de procesamiento de corriente de
datos opera como un procesador multi-protocolo,
multi-etapa que se puede configurar con conmutadores
apropiados y elementos de red relacionados para crear una
estructura de red sin costuras que permiten la interoperabilidad no
solamente entre los protocolos de comunicación existentes, sino
también con la capacidad de acomodar futuros protocolos de
comunicación. El método y los sistemas de la presente invención son
aplicables a redes que incluyen redes de almacenamiento, redes de
comunicación y redes de procesador.
En una realización de la invención, el motor de
procesamiento multi-protocolo opera como un motor de
procesamiento de flujo de datos que incluye tanto una porción de
ingreso como una porción de egreso, teniendo cada porción al menos
un procesador de etapa de corriente de bits. Preferiblemente, cada
procesador de etapa se optimiza durante una etapa particular en el
flujo de datos. Conceptualmente, el motor de procesamiento de flujo
de datos trabaja muy similarmente a una línea de montaje de
producción en la que en la medida en que el flujo de datos se mueve
a través del motor de procesamiento se logra un procesamiento
diferente como diferentes etapas de la línea de montaje, y todo el
procesamiento es temporizado al flujo de los datos. El flujo de
datos a través del motor de procesamiento se establece a una
velocidad que permitirá la operación continúa del motor de
procesamiento en la velocidad de línea de la o las redes a las
cuales se conecta el motor de procesamiento. El modelo de flujo de
datos utilizado en esta realización evita la necesidad de un manejo
de buffer profundo y extenso con el fin de mantener el seguimiento
de los datos tal como sería necesario en un procesador de protocolo
convencional. Adicionalmente, los motores en cualquier etapa están
inherentemente en cascada para soportar la escalabilidad.
En una realización del motor de procesamiento
multi-protocolo (OPE), las etapas múltiples incluyen
al menos un procesador de corriente de bits de etapa de ingreso,
una máquina de estado de etapa secundaria, un procesador de
tráfico, un programador y un procesador de corriente de datos en
etapa de egreso. El procesador de corriente de bits en etapa de
ingreso hace interfase con la capa física del flujo de datos y
establece marcos y/o flujos para la corriente de bits de acuerdo
con un protocolo determinado para la corriente de bits. La máquina
de estado de etapa secundaria analiza los marcos/flujos de acuerdo
con el protocolo determinado, preferiblemente utilizando un
clasificador de flujo de Palabra con Instrucción Muy Larga
programable (VLIW) que procesa en cadena la generación clave. El
procesamiento del marco/flujo se maneja por el procesador de
tráfico. El programador maneja la salida del flujo de datos desde
el procesador de tráfico y el procesador de la corriente de bits de
etapa de egreso hace interfase con la capa física del flujo de datos
por fuera del motor de procesamiento
multi-protocolo. Todas las etapas son dinámicamente
reconfigurables y reprogramables para permitirle al OPE ser
indiferente al protocolo.
En una realización, la máquina de estado de
etapa secundaria y el procesador de tráfico utilizan una disposición
de observación clave novedosa para mejorar la eficiencia del OPE.
El procesador de tráfico se puede implementar como una disposición
del procesador de flujo de datos multi-segmentado
donde los segmentos en el procesador de tráfico se implementan
dependiendo del protocolo dado de un marco/flujo. En la realización
del procesador de tráfico, los procesadores de flujo de datos
multi-segmentados implementan una aproximación de
multiplexación arbitrada y/o con división de tiempo (TDM) para a
acceder a una memoria buffer compartida común donde reside el flujo
de datos del marco/flujo. De esta manera, no existe necesidad de que
cada procesador de flujo de datos copie algunos o todos los datos
en el marco/flujo hacia un buffer interno en aquel procesador con el
fin de procesar aquellos datos. Más aún, los procesadores de flujo
de datos pueden generar una cascada y ser extensibles como
resultado tanto de la abstracción de etapa como de la abstracción de
reloj.
En una realización de la presente invención, se
implementa un conmutador de Gigabit QoS sin bloque de 48 puertos
multi-protocolo utilizando cuatro OPE en interfase
con un conmutador digital SPI 4.2. En esta realización, cada OPE
hace interfase con 12 puertos SerDes para conexiones externas y tres
puertos SPI 4.2 para conexión con el conmutador digital SPI 4.2.
Cuando se localiza en la mitad de una red de almacenamiento, el
controlador del procesador HPCC, la red de comunicación de intranet
e Internet, tal como un conmutador operan efectivamente como una
estructura convergente que permite las conexiones de red
indiferentes del protocolo entre cualquiera o todas estas redes.
Esta realización de la presente invención suministra una solución de
conmutación inteligente porque el conmutador es programable al
vuelo así como también reconfigurable permitiendo que cada paquete
sea manejado de manera diferente (es decir, 100% de enrutamiento
paquete por paquete a 10 Gbps por ejemplo) de acuerdo con las OPE
reprogramadas/reconfiguradas instantáneamente que comprenden los
"procesadores de puerto", o los conmutadores digitales que
forman la estructura de conmutación central. De esta manera, la
solución de conmutación suministra un protocolo de alto desempeño
(>=10 Gbps por ancho de banda de puerto), baja latencia (<5
usec de conmutación), protocolo independiente, política basada en
conmutación que es escalable a cientos de nodos, interoperable con
la infraestructura de red existente, suministra tolerancia
confiabilidad/falla telco (es decir, disponibilidad cinco de nueve)
de una manera efectiva en costos.
En otra realización de la presente invención,
las OPE y los elementos de red asociados son todos dinámicamente
reconfigurables y programables utilizando una disposición de control
de acceso de registro (RAC) y un control de acceso
sub-módulo (SAC) con un sistema de manejo GUI que
maneja la generación de código, el control de flujo, perfil y
estadísticas de desempeño, así como también los diagnósticos y el
mantenimiento para el sistema. En una realización específica, el
sistema de manejo GUI incluye un módulo para diseñar virtualmente el
sistema, un motor de simulación capaz de simular el desempeño
esperado de la arquitectura tal como se diseñó en una forma de
"Lo que Usted Ve es lo que Usted Consigue" y un Generador de
Código (Manejador Micro Código) que genera el
micro-código para reprogramar el OPE y cualquier
otro dispositivo de red reprogramable/reconfigurable si se
requiere.
Las Figs. 1A y 1B son diagramas de bloque
funcionales de un Motor Multi-protocolo de acuerdo
con una realización de la presente invención.
La Fig. 2 es un diagrama de bloque más detallado
del Flujo de Datos de Ingreso del OPE de la Fig. 1.
La Fig. 3 es un diagrama de estado de una
Máquina de Estado Empaquetada implementada como parte del Flujo de
Datos de Ingreso como se muestra en la Fig. 2.
La Fig. 4 es un diagrama de bloque más detallado
del Flujo de Datos de Egreso del OPE de la Fig. 1.
La Fig. 5 y 6 son representaciones esquemáticas
de un sistema de cuadro de paquete pre- procesador que comprende
una porción inicial del motor multi-etapa de acuerdo
con una realización de la presente invención.
La Fig. 7 es un diagrama de bloque de una
realización de un procesador de etapa de corriente de bit de acuerdo
con la presente invención que implementa un
pre-procesador.
Las Figs. 8A y 8B son ilustraciones esquemáticas
del Formato Ethernet General de XGMII y el formato General de
Ethernet.
Las Figs. 9-11 son diagramas
esquemáticos de las porciones seleccionadas del OPE
multi-etapa.
La Fig. 12 es un diagrama esquemático de la
máquina de estado programable de una realización de la presente
invención.
La Fig. 13 es una tabla extensible de ejemplo
para la máquina de estado programable de la Fig. 12.
La Fig. 14 es un diagrama de estado de ejemplo
para la máquina de estado programable de la Fig. 12.
La Fig. 15 es una tabla de ejemplo para la tabla
de decodificación programable.
La Fig. 16 muestra una figura más completa del
bloque de funciones básicas del estructurador
pre-procesador.
La Fig. 17 ilustra un método para incrementar la
selección de entrada, y la capacidad de tener
sub-estado dentro de los estados.
La Fig. 18 ilustra un método para expandir el
control de salida que viene de la máquina de estado.
La Fig. 19 muestra el lógico de comparación de
máscara que se puede seleccionar por la máquina de estado.
La Fig. 20 es un ejemplo de un diagrama de flujo
Ethernet que se podría programar mediante esta máquina de
estado.
La Fig. 21 es un diagrama de bloque del control
de flujo total de acuerdo con una realización de la presente
invención.
La Fig. 22 es un esquema que ilustra la
operación del RAC/SAC para monitorear y controlar la operación de
las Etapas del OPE inter-conectadas.
La Fig. 23 es un esquema de una Estructura
Ethernet estándar encontrada en el dispositivo de ingreso de acuerdo
con la presente invención.
La Fig. 24 y 25 son representaciones
esquemáticas que ilustran la configuración operacional de la Máquina
de Estado Programable y el Circuito de Máscara y Comparación de
acuerdo con una realización de la presente invención.
La Fig. 26 describe esquemáticamente un
clasificador de marco de ejemplo de acuerdo con una realización de
la presente invención.
La Fig. 27 ilustra los motores
Etapa-0 y Etapa-1 que operan en un
ciclo de retro alimentación de acuerdo con una realización de
ejemplo de la presente invención.
La Fig. 28 es un esquema de un procesador de
marco extendible de acuerdo con una realización específica de la
invención donde el procesador de marco incluye motores
P-SerDes y de núcleo.
Las Figs. 29, 30 y 31 describen esquemáticamente
una tarjeta de puerto HPC que caracteriza el Motor
Multi-protocolo de la presente invención.
La Fig. 32 es una realización de un conmutador
de ejemplo que utiliza la tercera parte de los FPGA para implementar
una estructura de conmutación.
La Fig. 33 es un esquema de un interruptor de
acuerdo con una realización general de de la presente invención.
Las Figs. 34A y 34B son esquemas que ilustran un
"Pipe Switch" ATMCAmTCAFAT de acuerdo con una realización
específica de la presente invención.
Las Figs. 35A y 35B son ejemplos del modelo de
ambiente y programación.
Las Figs. 36A y 36B muestran un diagrama de
bloques que ilustran el controlador de manejo de estante (ShMC) de
acuerdo a una realización primaria de la presente invención.
La Fig. 37A ilustra una implementación de una
maquina de estado finito de equipo I2C de ejemplo (HFSM) de acuerdo
con la presente invención.
La Fig. 37B es un diagrama de bloque que ilustra
una implementación de ejemplo de un puente entre los dispositivos
que utilizan varias interfases.
La Fig. 38 ilustra un diagrama de bloque de una
realización de un procesador de protocolo de corriente de bit de
acuerdo con una realización de la presente invención.
La Fig. 39 ilustra un diagrama de bloque de otra
realización de un procesador de protocolo de corriente de bit de
acuerdo con una realización de la presente invención.
La Fig. 40 es un diagrama de bloque de una
disposición de flujo de datos de acuerdo con una realización de la
presente invención.
La Fig. 41 es un diagrama de bloque de la
abstracción de la presente invención en términos de diferentes
niveles OSI.
La presente invención comprende aparatos,
sistemas y métodos novedosos para procesamiento de senda de datos a
velocidad de cable en una red. La Fig. 1A ilustra un diagrama de
bloque de una realización de un sistema de acuerdo con la presente
invención. La parte central de esta realización es un Motor
Multi-protocolo (OPE). El OPE es un procesador
multi-etapa de corriente de bits indiferente al
protocolo que incluye una función doble de: 1) montar los bits en
la corriente de bits hacia unas unidades de datos de protocolo
definidas apropiadamente de acuerdo con el protocolo relevante, y
2) procesar las unidades de datos de protocolo ensamblado para
suministrar rendimiento de velocidad de cable sin importar el
protocolo encontrado. A diferencia de los adaptadores especializados
prevalentes en la técnica anterior, ambas funciones en el OPE se
programan de manera dinámica. Así, cualquiera o ambas unidades de
datos de protocolo para un protocolo dado o las reglas de
procesamiento que aplican a las unidades de datos del protocolo son
cambiables de una manera dinámica.
Para los propósitos de la presente invención a
menos que se indique otra cosa, el término protocolo se refiere a
un protocolo de comunicación con paquete serializado que tiene
agrupamiento(s) definido de bits de control y datos o bits
de información (que puede ser nulo), todos los cuales siguen un
conjunto de instrucciones o reglas estándar. La Tabla 1 suministra
un perfil de algunos de los atributos de una realización del motor
multi-protocolo de la presente invención.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
Como se muestra en la Fig. 1b, el OPE es una
disposición de procesador multi-etapa porque éste
comprende varios bloques de procesamiento único. Cada bloque se
optimiza para funciones de procesamiento de flujo
multi-protocolo. Cada bloque de procesamiento
suministra "Puertas" junto con la senda de datos para el
procesamiento adicional a velocidad de cable. La puerta hace
interfase con el uso tanto de Carriles I/O en Serie de Alta
Velocidad así como también de Carriles en Paralelo de Alta
Velocidad para cumplir con los requisitos de latencia de los
bloques de procesamiento. Los estados, características y el
parámetro funcional de cada bloque de procesamiento se programan
preferiblemente "al vuelo" como se describirá. Como resultado,
los OPE son tanto re-programables como
re-configura-
bles.
bles.
En referencia a la Fig. 41, a un nivel básico
cada etapa o bloque de procesamiento se puede abstraer en términos
de componentes constituyentes, dependencias de flujo de datos entre
los componentes y las estructuras de control que alteran las
dependencias de flujo de datos. En el nivel más alto de abstracción,
cada etapa implementa una interfase genérica que implementa las
estructuras de control para posibilitar la etapa para aceptar un
objeto de flujo de paquete de entrada y una salida de un objeto de
flujo de paquete procesado así como también un objeto de meta datos
asociado con cualquiera o ambos de los flujos de paquete de entrada
y procesados. Cada etapa es un miembro de una clase base. Cada
clase base implementa una interfase que está especificada por el
conjunto de métodos que éste implementa para la clase base. A un
nivel intermedio de abstracción, cada clase base se puede extender
al agregar módulos adicionales que extienden las capacidades de la
clase base y forman una subclase. Cada subclase implementa su
propia interfase de subclase que suministra métodos adicionales que
extienden la funcionalidad de los métodos de clase base. Al nivel
más bajo de abstracción, la interfase suministrada mediante la
subclase se puede extender adicionalmente al suministrar otros
métodos y/o al agregar sub-módulos para suministrar
componentes que no existían en la clase base. La clase y sus
subclases son re-configurables al cambiar los
métodos y los objetos sobre los cuales los métodos actuarán. De esta
manera, cada etapa del procesador de corriente de bits se puede
reconfigurar de manera programable para suministrar recursos y
servicios diferenciados. De esta manera, las varias etapas se
configuran en una máquina de flujo de datos (paquete) con una
arquitectura independiente del protocolo.
El marco se define como una corriente de bits,
donde el significado de cada uno de los bits se define por una o
más reglas de estructura de protocolo pre-definida.
El modelo de abstracción tiene un método para aceptar como entrada
una corriente de bits. El significado de cada uno de los bits se
abstrae por el método de tal manera que cada etapa es capaz de
aceptar una corriente de bits. El procesamiento de protocolo se
define por otro método que efectúa un conjunto de acciones con base
en la información en uno o más bits de la corriente de bits,
localizados en cualquier parte de la corriente de bits. Cualquier
clase o subclase que se pueda implementar tal como el método puede
llevar a cabo potencialmente la etapa de procesamiento del
protocolo. En una realización alternativa, cada clase o subclase se
puede programar para procesar un protocolo particular al implementar
un método en una interfase genérica presentada por la clase o
subclase. Los detalles de la implementación se pueden así
"ocultar" detrás del método o los métodos para permitir la
reutilización del código y el componente. El resultado de la
abstracción es que la arquitectura de flujo de datos es
esencialmente una serie de etapas de latencia predecibles
encadenadas dispuestas de tal manera que el procesamiento en una
etapa dada se completa en el intervalo de espacio
inter-paquete, es decir, antes de que llegue el
siguiente paquete.
La abstracción de cada etapa permite la adición
de una o más sub-etapas en cadena a cada etapa. Cada
sub-etapa en una etapa de la cadena completa su
acción sobre el paquete en un momento igual al tiempo de llegada del
paquete dividido por el número de sub-etapas con
una etapa. Así, la primera etapa puede comprender subclases que
implementan métodos para decodificar el paquete -es decir, crea meta
datos a cerca del paquete de datos. Los meta datos pueden contener
información relacionada con la localización de ciertos patrones de
bit específicos del protocolo dentro de una corriente de paquete de
entrada. A este respecto, el decodificador del paquete
"analiza" el marco (una corriente de bits definida). Nótese que
el término "implementa" se utiliza aquí para significar una
implementación en términos de uno o más del "firmware" y el
hardware. Cualquier "firmware", hardware o combinación de
"firmware" y hardware que implemente las funciones básicas
descritas anteriormente se pueden utilizar para implementar los
métodos referenciados anteriormente. Por ejemplo, la etapa
decodificadora de paquete se puede implementar como una máquina de
estado programable con aceleradores de comparación. Dado un tipo de
protocolo, el PSM extracta los campos en el paquete necesarios por
los procesadores de etapa para manejar por ejemplo el
"look-up". El decodificador del paquete efectúa
Layer2/Layer3/Layer4 analizando para extraer información de los
encabezamientos de estas tres capas. Por lo tanto, los métodos que
implementan esta funcionalidad se pueden ajustar para procesar los
protocolos de estas tres capas y así extender la clase de base.
En una realización, una porción de ingreso y una
porción de egreso del motor de procesamiento de flujo de datos
tiene cada una múltiples procesadores de etapa de corriente de bits
que están en interfase con una memoria de paquete de flujo de datos
multi-puerto. Cada procesador de etapa de corriente
de bit se suministra con una única memoria de instrucción. En una
realización, un primer bus de conmutación está conectado entre la
memoria del paquete de flujo de datos y una interfase de estructura
y la interfase del procesador y un segundo bus de conmutación está
conectado entre la memoria del paquete de flujo de datos y los
procesadores de etapa de corriente de bits múltiples. En esta
realización, un tercer bus de conmutación está conectado entre los
procesadores de etapa de corriente de bit múltiples y una interfase
de memoria común. La interfase de memoria común se puede conectar
con la memoria externa o con una interfase de memoria manejable de
contenido (CAM).
En una realización, el OPE soporta el conjunto
de bloques de procesamiento común que son necesarios para la
mayoría de protocolos comúnmente encontrados. Características
adicionales, como procesamiento de protocolo intensivo de computo,
se pueden implementar al agregar bloques de procesamiento
multi-función programable por el propietario. Estos
bloques de procesamiento de computo también son capaces de
programabilidad "al vuelo" que dota el OPE con la
extensibilidad requerida para operar en cualquier ambiente de
protocolo sin incurrir en el tipo de costos o la pena de desempeño
que es característica de los intentos de la técnica anterior para
lograr una estructura de red convergida. En efecto, el OPE
posibilita una estructura convergida al suministrar una capacidad
de procesamiento multi-protocolo, es decir, la
capacidad de mezclar componentes no similares de un centro de
computo sin la necesidad de puertas e interruptores entre los
diferentes protocolos de alta velocidad. La solución OPE trabaja
sobre Capas OSI 2-7.
En una realización, los bloques de procesamiento
del OPE se programan preferiblemente por medio de un generador de
código basado en GUI como se describe en la Patente U.S. No.
6,671,869 titulada "Method and Apparatus for Graphically
Programming a Programmable Circuit". Las plantillas del protocolo
se presentan y las acciones sobre los campos específicos se
arrastran y se dejan caer a los colectores de acción por medio del
cual el sistema genera un Código de Motor de Comunicación.
Adicionalmente, el GUI muestra el desempeño esperado del motor, en
la forma de "Lo que Usted Ve es lo que Usted Consigue". El
sistema le solicita al usuario las acciones necesarias para
conseguir el máximo desempeño. En un ambiente de chip estas
capacidades se utilizan para seleccionar las velocidades de enlace
apropiadas. En un ambiente de plataforma programable, tal como por
ejemplo el FPGA, se puede seleccionar un chip con mayor
capacidad.
En una realización específica de este generador
basado en GUI como se ilustra en las Figs. 35A y 35B, están
presentes las plantillas del protocolo y las acciones sobre los
campos específicos se arrastran y se dejan caer en los colectores
de acción. El sistema genera un Código de Motor de Comunicación y
muestra el desempeño esperado del motor, en la forma de "Lo que
Usted Ve es lo que Usted Consigue". Este sistema le solicita al
usuario acciones necesarias para conseguir el máximo desempeño. En
un ambiente de chip estas capacidades se podrían utilizar para
seleccionar las velocidades de enlace apropiadas. En un ambiente de
plataforma programable (como el ejemplo anterior del FPGA) se
podría seleccionar un Chip con Mayor Capacidad.
La funcionalidad "al vuelo" se puede
suministrar mediante, por ejemplo, una disposición de puerta
programable de campo en conjunto con uno o más procesadores de
propósito general (CPU) que comparten un bus local común. Una de
tales aproximaciones se describe en la Patente U.S. No. 6,721,872
titulada "Reconfigurable Network Interface Architecture". Una
aproximación alternativa para suministrar tal funcionalidad "al
vuelo" se describe en "Media Processing with Field-
Programmable Gate Arrays on a Microprocessors Local Bus", Bove
Jr. et. al., MIT Media Lab, Cambridge, MA 02139 USA.
En referencia ahora a la Fig. 2, se describirá
una realización de la Operación de Ingreso del OPE mostrado en la
Fig. 1. La Agregación de Puerto involucra entramado de protocolo de
capa física típico de los dispositivos PHY y MAC y traduce los
datos de paquete específicos de medio hacia marcos de ráfaga SPI4.2.
Las pequeñas ráfagas SPI4.2 de los múltiples puertos se pasan al
Motor SPI4.2 de manto redondo en forma Multiplexada por División de
Tiempo. El canal SPI4.2 se divide en franjas de tiempo con base en
el número de puertos que se agregan; un agregador de puerto 8
divide el canal SPI4.2 en 8 divisiones iguales. Ráfagas en reposo se
generan en el bus para franjas para puertos que están inactivas o
no tienen datos que transferir.
Los dispositivos MAC para esta realización son
el chip 8xIGbE MAC ("chip MAC"). El chip MAC se configurará
para lo que se denomina modo "intercalado de ráfaga", que
significa que un número configurable de bytes (32 bytes, por
ejemplo) de los datos del paquete Ethernet de cada IGbE MAC se
programará, en forma de manto redondo (puerto 0 a puerto 9) para la
transmisión de la interfase SPI-4.2. Las ráfagas del
IGbE MAC se intercalan y transmiten entonces sobre el bus
SPI-4.2. Las ráfagas Runt (ráfagas más pequeñas de
32 bytes) son posibles al inicio y al final de los delimitadores de
paquete. Las operaciones sobre el Paquete Ethernet efectuadas por
el chip MAC incluyen: (1) eliminar el preámbulo y el Inicio del
Delimitador de Marco (SFD) y (2) retener el FCS.
El Motor SPI-4.2 incluye
preferiblemente un núcleo que suministra la funcionalidad material
del Motor SPI-4.2 que convierte el entramado
SPI-4.2 a un formato de entramado interno similar al
SPI4.1. Los datos que llegan del bus SPI4.2 en ráfagas de 16 bits,
la primera palabra de 16 bits de la ráfaga contiene una palabra de
control que contiene la información a cerca de la ráfaga;
incluyendo si la ráfaga es el inicio de un paquete, el final de un
paquete o la continuación de un paquete y un número de canal del
cual fue fuente la ráfaga. Hasta ocho palabras de datos de 16 bits
de un canal se ensamblan en palabras de 64 bits y pasadas, mientras
los 16 bits de la palabra de control se convierten en una Etiqueta
de Enrutamiento Interno.
En esta realización, las Etiquetas de
Enrutamiento Interno se pasan sobre el bus interno junto con los
datos en ráfaga del paquete como marcos que se mueven a trabes del
lógico de avanzada. La Etiqueta de Enrutamiento Interno contiene un
bit para Dato Válido, uno para Inicio de Paquete, uno para Fin de
Paquete, un bit para Error de Datos, 3 bits para tamaño de ráfaga
(0 a 7 indica el tamaño de la ráfaga de 1 a 8 respectivamente) y 3
bits para la Dirección del Canal. La Dirección del Canal indica el
puerto la ráfaga con la que está asociada. En otra realización, la
Etiqueta de Enrutamiento Interno puede incluir información QOS/COS
con base en la priorización de la capa de red o las prioridades
designadas VLAN.
El procesamiento de marco por el Procesador de
Marco requiere identificar características interesantes del paquete
de red. Esas características incluyen las direcciones de destino y
fuente, el tipo de paquete, el programa de datos capa 3 y capa 4 y
la dirección de la sesión. Además el Procesador de Marco mantiene
una máquina de estado para cada paquete procesado por el lógico de
avanzada.
Como se muestra en la Fig. 3, la Máquina de
Estado de Paquete le hace seguimiento a la composición de la
corriente de datos. Para la solución HPC, la corriente de datos
esta compuesta de múltiples ráfagas de datos en paquete que se
clasificarán con base en los campos de bit en la palabra de control
SPI4.2. Se inicia una máquina de estado de paquete para cada
paquete recibido en o trasmitido desde el SPI4.2. Un paquete ingresa
el estado VALIDO cuando se declara la señal SPI Valido
(PACKET_VALID). Cuando la señal de Inicio de Paquete SPI se declara
el paquete ingresa al estado de START_OF_PACKET y un Fin de Paquete
SPI origina una transición al estado END_OF_PACKET. Si el estado de
error indica un error el estado de máquina ingresa al estado ERROR
de lo contrario el estado de máquina hace transición a INIT.
En referencia de nuevo a la Fig. 2, la
responsabilidad del Motor de Análisis (Analizador) es construir una
Clave Clasificadora de tupla múltiple de la información suministrada
por el Procesador Marco. En una realización, solamente es necesaria
la dirección de destino para la generación de la Clave
Clasificadora. En realizaciones alternativas, el Motor
"Lookup" se puede mejorar para también incluir cualquier número
de características de paquete o estados de paquete/puerto cuando se
construyen las Claves Clasificadoras modificando así el
comportamiento del conmutador en la medida en que éste envía un
paquete individual o una corriente de paquete.
Utilizando la Clave Clasificadora generada por
el Analizador, el Motor Lookup se mezclará en el CAM de Envío para
encontrar el puerto de destino de egreso. El puerto de destino de
egreso está ubicado en el Encabezador de Enrutamiento Interno. En
una realización, el Encabezador de Enrutamiento Interno está
compuesto completamente de un número de puertos de egreso.
Alternativamente, el Encabezador de Enrutamiento Interno puede
incluir información adicional. Las entradas del CAM de Envío serán
accesibles a entidades de manejo tal como estaciones de manejo
basadas en SNMP.
El Director de Tráfico es responsable por enviar
y/o copiar marcos al CPU con base en la dirección de puerto
encontrada en el Encabezador de Enrutamiento Interno. Se suministra
la lógica de interfase apropiada entre la lógica de envío y el
microprocesador en el FPGA.
Manejar el flujo de datos entre la estructura de
conmutación y la lógica de procesamiento de marco de la Tarjeta de
Puerto es la responsabilidad del Motor de Cola. El Motor de Cola
contiene una cola virtual para cada IGbE MAC en la estructura de
conmutación, en una conmutación de Tarjeta de Puerto 8 que se agrega
hasta las colas virtuales. Cada cola virtual es suficientemente
grande para mantener múltiples paquetes jumbo (9K). Se mantiene un
índice para cada cola virtual para hacer seguimiento donde en la
cola virtual los siguientes 64 bits de datos deben ser colocados,
ese índice se denomina el índice de puesta en cola VQ. La sacada de
cola VQ se consulta para determinar los siguientes 64 bits de datos
que necesitan pasarse al programador. Así, los datos provenientes
del Director de Tráfico se coloca en el VQ del puerto de destino en
el descentrado indicado por el índice de puesta en cola VQ. Por el
contrario, el índice de sacada de cola VQ se utiliza para determinar
que datos pasaron al Programador. El Motor de Cola también
suministra un Cambio de Velocidad FIFO entre la estructura de
conmutación y las Colas Virtuales y un mecanismo de control de flujo
que se presenta entre la presión trasera la estructura de
conmutación y la lógica de envío.
El Programador utiliza el mecanismo de sacado de
cola del Motor de Cola cuando pasan marcos a la estructura de
conmutación. Los marcos se programan para manejarse descentrados de
la estructura de conmutación en una forma de manto redondo, desde
el puerto 0 al puerto 31. La sacada de cola involucra encapsular el
marco en XGMII antes de que el Núcleo XAUI convierta el marco a
XAUI. La Etiqueta de Enrutamiento Interno y el Encabezador de
Enrutamiento Interno se utilizan durante la conversión.
En referencia ahora a la Fig. 3, se describirá
una realización de la Operación de Egreso del OPE. El Motor de Cola
suministra cola sobre el lado de Egreso que es el inverso de
Ingreso. Los marcos XAUI provenientes de la estructura de
conmutación se convierten a XGMII mediante el Núcleo XAUI. Los
marcos XGMII son puestos en cola a una Cola Virtual con base en un
número de puerto en el marco XGMII.
El Programador logra programar egresos de la
misma manera que los ingresos. Los marcos se sacan de cola en una
forma de manta redonda pero los marcos de datos de egreso se deben
convertir a la interfase de bus local y a la Etiqueta de
Enrutamiento Interna generada. En una realización, el Programador se
diseña para ser adaptativo y heurístico con el fin de reducir las
actualizaciones CAM de envío fuera de banda al solo buscar
radiodifusiones y actualizar el CAM con la dirección de la
fuente.
La conversión SPI4.2 de Egreso como se muestra
en la Fig. 4 es la reserva del ingreso. El formato de marco local
se convierte a SPI4.2 utilizando el núcleo de propietario. El
agregado de puerto de egreso involucra montar los datos en ráfaga
del marco SPI4.2 en paquetes de medio y transmitirlos hacia fuera a
través de sus interfases de egreso dirigidas. De nuevo, estas
preferiblemente son el chip MAC referenciado anteriormente. La
operación de egreso es el inverso del ingreso. Los datos del paquete
Ethernet se reciben en el FIFO de Egreso proveniente del
SPI-4.2 en ráfagas de datos de paquete de Ethernet
intercalados (puerto 0 a puerto 9). Cuando el FIFO de Egreso recibe
5 ráfagas (o cuando el EOP llega dependiendo de la longitud del
paquete) el FIFO de Egreso iniciará la transferencia a los IGbE
MAC. Preferiblemente, el manejo de marco de egreso también mantiene
una máquina de estado de puerto que efectúa las revisiones de estado
de marco tal como el envejecimiento del marco, eliminación de
encabezado VLAN, remoción de encabezado de envío interno, y la
operación similar. Las operaciones sobre el Paquete Ethernet
efectuadas por el chip MAC incluyen: (1) agregar el preámbulo, (2)
agregar el inicio del detector de marco (SFD), y, opcionalmente, (3)
agregar el FCS.
En una realización de ejemplo ilustrada en las
Figs. 5 y 6, el OPE suministra una secuencia seleccionada de
motores de etapa encadenados denominada Etapa-0,
Etapa-1, Etapa-2...
Etapa-n. Cada motor de etapa puede tener una
arquitectura extensible reprogramable diferente, con base en la
funcionalidad del OPE para el que es utilizado. Por lo tanto, a
diferencia de los procesadores de la técnica anterior donde se
caracterizan los paquetes en términos de las instrucciones de
software que toman, la presente invención es una arquitectura de
flujo de datos con una línea de montaje de etapas especializadas
que se puede instantanizar al vuelo para reflejar cambios en el
flujo de datos hacia abajo de la línea.
Aunque la invención no restringe el número de
puertos en el ingreso, la invención se describe mejor en términos
de paquetes de datos que llegan a un puerto único y el seguimiento
de la vida del paquete a lo largo de la senda de datos a través del
OPE. Es importante notar que de cada una de estas corrientes de bit
de datos puede tener varios bits de ancho. El ancho suministra una
medida del tiempo de procesamiento (o ciclos de reloj) disponibles
en cada motor de etapa de la cadena con el fin de posibilitar el
rendimiento de la velocidad de cable. Cada motor de etapa esta
restingido a operar dentro de la cubierta de tiempo particular al
incrementar el número de motores que comprenden cada etapa si
parece probable que el procesamiento en cualquier etapa no se pude
lograr dentro de las restricciones de tiempo establecidas en la
etapa preliminar.
La Fig. 7 describe una de las realizaciones de
la presente invención que suministra para el motor de
Etapa-0 que es esencialmente un estructurador de
paquete pre-procesador que incluye en parte una
máquina de estado programable (PSM). En la medida en que el paquete
viene de un ancho de 64 bit a la vez, el estructurador identifica y
distingue entre varios tipos de marco como se ilustra en la Fig. 1.
El estructurador consiste de una máquina de estado de base de
memoria programable, una tabla de revisión de base de memoria
rápida, varios comparadores junto con valores cargables, y un
lógico seleccionado. La máquina de estado selecciona campos de
paquete de interés los compara contra el conjunto de valores u
otros datos de marco, que manejan el algoritmo de la máquina de
estado que marca los marcos de interés así como también determina el
tipo de marco. Esta información se pasa entonces al analizador
donde éste ayuda a instruir al analizador sobre como analizar el
marco.
Para una descripción más detallada de esta
realización del procesador de corriente de bits
pre-procesador, se hace referencia al Apéndice A,
cuya descripción se incorpora aquí mediante referencia. La
referencia también se hace al Apéndice B, cuya descripción se
incorpora aquí mediante referencia, lo que define una realización
del Archivo de Registro Lógico de Envío.
\newpage
El OPE preferiblemente incluye al menos unas
Máquinas de Estado Programables predecibles (PSM). En una
realización, cada PSM es una máquina de estado 32 con 50 ns/PSM en
el reloj interno de 156 MHz equivalente a 5 ns por 10
instrucciones. Cada PSM, sin embargo, puede tener un número variable
de relojes. El motor de Etapa-0 establece el tiempo
de mantenimiento del procesamiento de ancho de banda al convertir la
corriente de bits en serie relativamente rápidas a una corriente de
datos amplios de n bits paralela relativamente lenta. El tiempo de
mantenimiento del procesamiento de ancho de banda se ajusta a la
velocidad de la línea. Por ejemplo, para el procesamiento a una
velocidad de 10 Mbps, el tiempo de mantenimiento es 50ns por etapa
del OPE.
Preferiblemente, la base registradora consiste
de una tabla de revisión programable preestablecida con valores
cargados como parte de la configuración. Estos registros se
seleccionan entonces para uso con la máscara, comparadores y
contadores que son integrales a la operación del motor de etapa. Una
configuración de ejemplo de la configuración del motor de etapa se
ilustra como sigue: La tabla de revisión programable contiene hasta
34 valores de 16 bits que se van a comparar. La tabla saca los bits
que corresponden a la coincidencia si alguno es hecho. En el
ejemplo, puede haber 4 comparadores con un ancho de 8 bits, dos
contadores hacia atrás con un valor cargable máximo de 8 bits para
un conteo hacia atrás máximo de 256. El ancho de selección de datos
de paquete puede ser un byte y el tamaño del campo de valor de
registro representado por 16, registradores
pre-establecidos con un ancho de 8 bits. La
instrucción de la máquina de estado puede ser una instrucción de
palabra única (SWI). El conjunto de instrucciones de palabra única
se puede seleccionar del conjunto que comprende de conjunto,
prueba, y ramificación donde cada campo de cada instrucción puede
tomarse sobre múltiples sub-campos como se muestra
por debajo donde cada sub-campo se separa por coma y
cada campo principal se separa por un punto y coma, por ejemplo,
SWI: conjunto 1, conjunto 2, conjunto 3,... conjunton; prueba 1,
prueba 2, prueba 3,..., prueban; br 1, br 2, br
3,... brn;
3,... brn;
En Operación, la máquina de estado tomaría la
ramificación condicional con base en las entradas de vector
seleccionables. Así, por ejemplo, la condición (byte Marco 2 = = R2)
compararía el byte de localización del paquete 2 de 8 contra el
valor R2 del registrador pre-establecido. La
ramificación determinaría normalmente el siguiente estado de
control, pero se podría utilizar para cambiar el modo de operación
del estado habitual de la máquina de estado programable.
En referencia ahora a las Figs. 8A y 8B, se
ilustra una aplicación del método de estructuración de paquete
pre-procesador a un paquete de Ethernet de entrada
desde la interfase XGMII. Desde éste, el Bloque de Interfase XGMII
elimina el preámbulo y convierte la interfase de 32 bit en una
representación interna de 64 bit como se muestra en la Fig. 8B:
Formato General de Ethernet.
En la medida en que los paquetes de 64 bit de
ancho fluyen a través de la cadena, la máquina de estado selecciona
cual campo de 16 bit quiere enviar la decodificación programable
ram. Ver Fig. 9: Selección TYPE de Paquete y Fig. 10:
decodificación programable RAM.
La máquina de estado también selecciona otra
información desde el paquete para compararse contra los
registradores programables con la retroalimentación de resultados a
la máquina de estado como se muestra en la Fig. 10. La Fig. 10 por
ejemplo muestra la entrada VLAN y SNAP que se seleccionan y se
comparan contra los registradores seleccionados con los resultados
de retroalimentación a la máquina de estado para análisis.
El propósito de la Máquina de Estado de acuerdo
con una realización de la presente invención es controlar la
extracción de la información del encabezado de la capa de protocolo.
Esta máquina de estado consiste de una memoria de bloque
programable con 5 líneas de datos de salida retroalimentadas hacia 5
entradas de dirección para la siguiente activación de entrada de
reloj. Las otras salidas de la máquina de estado controlan varias
funciones por ejemplo, los datos de marco para capturar, la
detección desfasada de la capa de marco y varia selección de
entrada para el lógico de comparación, así como también la siguiente
entrada a la máquina de estado misma. Esta máquina de estado se
muestra en la Fig. 12. La Fig. 13 muestra un ejemplo de la tabla de
máquina de estado para ayudar a ilustrar
ésta.
ésta.
Un objetivo de esta Máquina de Estado
Programable es controlar la decodificación y extracción de los datos
de paquete. El diagrama de estado en la Fig. 14 ilustra como esta
máquina de estado se podría configurar para manejar el Paquete
Ethernet. En este ejemplo la máquina de estado solamente hizo la
Capa Ethernet 2 pero podría también continuar todo el camino hasta
la Capa 4 por ejemplo.
El Ram de Decodificación suministra un método
para hacer decodificaciones programables rápidas de campos
seleccionados. La entrada en este circuito RAM de Decodificación es
un campo de 16 bits seleccionable que viene del paquete, y la
salida es una decodificación TYPE de 4 bits como se ilustró
anteriormente en la Fig. 10. Un método para hacer esto sería
primero llenar la memoria con todos los ceros luego escribir los
bits de decodificación para los Tipos que usted quiere decodificar.
La dirección de 16 bit corresponde al "Tipo" y los datos
corresponden al valor de decodificación que se desea para aquel
tipo. Bajo una situación normal solamente se establecen 2 bits, 1
bit para el Puerto B, y el mismo para el Puerto A. Los bits de
decodificación deben ser el mismo valor para ambos el Puerto B y el
Puerto A. Un ejemplo de esto podría ser si se desea tener un
AppleTalk Phase 0x809B, para ser un valor de decodificación
"1", 0x8137 IPX (Novell Netware) para ser un valor de
decodificación "2", 0x8847 IMPLS Unicast para ser un valor de
decodificación "3", y 0x8848 MPLS Multicast para tomar un valor
de decodificación "4". Los resultados de esto se muestran en
la Fig. 15.
\newpage
La Fig. 18 muestra una figura más completa del
bloque de funciones básicas del Estructurador
Pre-procesador.
La Fig. 17 ilustra un método para incrementar la
selección de entrada, y la capacidad para tener
sub-estado dentro de los estados.
La Fig. 18 ilustra un método de expandir el
control de salida que viene de la máquina de estado.
La Fig. 19 muestra el lógico de comparación de
máscara que se puede seleccionar por la máquina de estado.
La Fig. 20 es un ejemplo de gráfica de flujo
Ethernet que se podría programar mediante esta máquina de
estado.
Con referencia de nuevo a las Figs. 5 y 6, el
Estructurador Pre-procesador se puede configurar
para suministrar más flexibilidad al hacer la selección del
paquete, o la capacidad para hacer una etapa de regreso
seleccionable en la selección de cadena. Si se desea una mayor
capacidad, siempre se podría suministrar al agregar una o más
máquinas de estado adicionales y/o RAM de decodificación
programable. También se nota que los RAM que se muestran están
incrustados en el XILINX como un bloque RAM que se puede configurar
y agrupar de manera diferente, etc., y que este diseño solamente
mostró 2 bloques RAM que se utilizan uno para la Máquina de estado
y el otro para la decodificación TYPE. El Xilinx XC2VP2 más pequeño
tiene 12 Bloques RAMS, el siguiente tamaño tiene 28 y el más grande
XC2VP125 tiene 556 Bloques RAMS.
En una realización general de la invención
ilustrada en la Fig. 26, la senda de datos de las cadenas OPE desde
el motor de Etapa-0 al motor de
Etapa-1. El motor de Etapa-1 efectúa
una clasificación de paquetes a base de regla. Un número de motores
puede estar en cascada para obtener los resultados deseados en razón
de que ha ocurrido la clasificación dentro del intervalo de tiempo
definido en la Etapa-0 de tal manera que hay un
rendimiento de velocidad de cable real. Cada motor está basado en el
modelo de flujo de datos en lugar del modelo de almacenamiento y
envío convencional. Una de las salidas de esta etapa es la
generación clave establecida como premisa en el conocimiento previo
de los contenidos relevantes del paquete. En la implementación
corriente, esta etapa requerirá dos ciclos de instrucción. Cada
motor emplea un buffer único. A diferencia de un coprocesador de
punto flotante, todos los motores son dinámicamente programables, es
decir, las instrucciones son re-programables de tal
manera que ellas se pueden adaptar para aplicaciones específicas.
Típicamente, la Etapa-1 comprenderá al menos un
procesador de trabajo de instrucción muy larga (VLIW). En una
realización alternativa, el motor de Etapa-1 se
puede configurar de manera que los procesadores adecuen las tareas
como se describió previamente.
En una realización de especificación de la
invención ilustrada en la Fig. 27 los motores de
Etapa-0 y Etapa-1 operan en un
ciclo de retro alimentación con la información de estado de la
corriente de bits Etapa-0 que se procesa utilizando
el PSM que se pasa hacia el motor de clasificación de
Etapa-1 y la información desde el clasificador que
es retroalimentada para informar la operación del motor de
Etapa-0. La arquitectura del motor de adelanto de
alimentación/retraso de alimentación hace posible tomar una
corriente de bits de los contenidos de cualquier flujo dado, desde
los flujos múltiples que se pueden soportar por el OPE, analizar (o
clasificar) los contenidos en la medida en que los datos fluyen a
través del motor y la información de alimentación obtenida por la
operación de regreso a la etapa previa de tal manera que la
siguiente operación se basa en el estado anterior así como también
el resultado de la clasificación del estado anterior.
Tal aproximación se puede utilizar
ventajosamente, por ejemplo, para procesar paquetes de longitud
variable/proto-
colo variable, reordenar dinámicamente hacia fuera los paquetes de secuencia o para otra funcionalidad de control de error. La unidad elemental de datos se vuelve un bit con la alimentación hacia atrás y la alimentación hacia delante que suministra la memoria del sistema o goma que permite que cada bit se relacione con cada bit que ha ido antes de éste y lo ha seguido. Este paradigma se puede escalar para inyectar una "memoria" hacia al sistema de estructuras de dato macro-elemental tal como un byte, palabra, un marco o una sesión completa dependiendo del objetivo particular de la etapa pero sin que incurra la latencia y la sobre carga de hardware de las arquitecturas de almacenamiento y envío. Tales estructuras de datos macro-elementales podrían ser efímeras porque ellas persisten aunque los datos tengan una característica particular y se utilizan para reprogramar el comportamiento del OPE para todos los flujos de datos subsecuentes. De esta manera, a diferencia de los procesadores de protocolo convencionales cuya operación es alambrada, el OPE es un dispositivo de hardware adaptable que se adapta a un flujo de datos de evolución pero de una manera determinística, es decir, la "explosión de estado" que caracteriza los intentos de la técnica anterior para suministrar una solución al expandir el número de máquinas de estado y estados para manejar los flujos de datos crecientes se resuelve en la solución suministrada por la presente invención.
colo variable, reordenar dinámicamente hacia fuera los paquetes de secuencia o para otra funcionalidad de control de error. La unidad elemental de datos se vuelve un bit con la alimentación hacia atrás y la alimentación hacia delante que suministra la memoria del sistema o goma que permite que cada bit se relacione con cada bit que ha ido antes de éste y lo ha seguido. Este paradigma se puede escalar para inyectar una "memoria" hacia al sistema de estructuras de dato macro-elemental tal como un byte, palabra, un marco o una sesión completa dependiendo del objetivo particular de la etapa pero sin que incurra la latencia y la sobre carga de hardware de las arquitecturas de almacenamiento y envío. Tales estructuras de datos macro-elementales podrían ser efímeras porque ellas persisten aunque los datos tengan una característica particular y se utilizan para reprogramar el comportamiento del OPE para todos los flujos de datos subsecuentes. De esta manera, a diferencia de los procesadores de protocolo convencionales cuya operación es alambrada, el OPE es un dispositivo de hardware adaptable que se adapta a un flujo de datos de evolución pero de una manera determinística, es decir, la "explosión de estado" que caracteriza los intentos de la técnica anterior para suministrar una solución al expandir el número de máquinas de estado y estados para manejar los flujos de datos crecientes se resuelve en la solución suministrada por la presente invención.
Una realización de una disposición de flujo de
datos que implementa una realización de la presente invención para
procesadores de corriente de bits multi-etapa se
muestra en la Fig. 40.
Una de las características atractivas de la
metodología multietapa es que los parámetros de los varios motores
de Etapa se desacoplan de manera efectiva. Por ejemplo, no existe
necesidad de un reloj común entre varias etapas. Esto simplifica
significativamente el diseño del OPE. Cada etapa se puede poblar con
uno o más motores que se ajustan a la necesidad operacional de
aquella etapa en cualquier momento dado. Cada motor se puede
reprogramar al vuelo para dotarlo con funcionalidad que caza con las
características del flujo de datos encontrado por el OPE en el
punto de tiempo particular.
En una realización general de la invención, el
motor de Etapa-2 es seguido por un motor de
Etapa-3. El motor de Etapa-3
suministra funcionalidades de plano de control del nivel superior
tal como enrutamiento, señalización, apilado de protocolo,
definición de política, mantenimiento de tabla, interfase con el
plano de datos y así sucesivamente. Como en las etapas previas, la
Etapa-3 tiene motores especializados que se pueden
replicar para hacer coincidir el tiempo de procesamiento y los
requisitos de funcionalidad impuestos sobre el OPE. Las Figs.
28-31 ilustran un procesador de marco extensible con
motores P-SERDES y Core y una tarjeta de puerto HPC
que caracteriza el OPE de la presente invención.
En una realización, ilustrada en las figuras
anteriormente mencionadas por ejemplo, una entrada 32 por un CAM de
48 bits en cada Tarjeta de Puerto en el conmutador. Cada entrada
representa un puerto particular en el conmutador. Así, la primera
entrada en una Tarjeta de Puerto que envía el CAM representa el
puerto uno del conmutador. Se notará que estos CAM se pueden
incrementar en tamaño para acomodar múltiples nodos en los
segmentos LAN unidos. Preferiblemente, se define un mecanismo de
envejecimiento el cual mantendrá solamente entradas prácticas en
una Tarjeta de Puerto que envía el CAM. En razón a que el HPCC no
utiliza los segmentos LAN, el mecanismo de envejecimiento puede no
ser necesario.
Como una de las metas de diseño es permitir el
acceso a los CAM de envío por vía del SNMP, el agente SNMP que
corre sobre el Manejador de Estante necesitará acceso de
lectura/escritura para el envío del cache CAM residente en la
Tarjeta Portadora. Los cambios para enviar el cache de tabla serán
empujados hacia abajo por las Tarjetas de Puerto por vía del
mensaje CAM IPMI actualizado y procesado como se describió
anteriormente.
Aprendizaje de las Direcciones MAC Dinámicas.
Con el fin de que un conmutador envíe paquetes entre cualquiera de
dos puertos de conmutación se debe efectuar una revisión en la
dirección MAC de destino para encontrar un puerto de conmutación de
destino donde será enviado el paquete de entrada. La tabla de
revisión (también conocida como tabla de envío) contendrá
preferiblemente un valor de 28 bits que contiene una dirección MAC
de destino junto con un identificador de puerto conmutador de 6 bit.
La tabla de envío mantenida por el conmutador se distribuye entre
las tablas de envío manejadas sobre las Tarjetas de Puerto
individuales. Estas tablas de envío (que se implementarán en
hardware por los CAM) necesitarán ser pobladas. Existen dos métodos
para poblar las tablas de envío: dinámicamente y estáticamente. La
población estática de estos CAM se logrará al exponer los CAM de
envío a una entidad de manejo por vía de una empresa SNMP MIB
similar a las bases de datos de envío descritas en el
RFC 1493.
RFC 1493.
Una de las metas de este diseño es moderar el
uso de los paquetes de radiodifusión y
multi-difusión. Esto es porque los marcos de
radiodifusión son costosos en términos de ancho de banda y los
recursos de conmutación y los marcos de
multi-difusión son aún más costosos. Se efectuó una
búsqueda exhaustiva para encontrar un método para esta conmutación
para aprender dinámicamente la o las direcciones MAC sobre los
segmentos LAN unidos a cada puerto de conmutación sin importar que
topología podía desplegar el conmutador y hacer esto sin utilizar
os paquetes de radiodifusión o multi-difusión y sin
modificaciones al lógico de red del puerto anexo. En el presente,
no existe un método único o conjunto de etapas que permitirá la
conmutación para determinar dinámicamente, en todos los casos,
todas las direcciones MAC que se pueden conectar al puerto de
conmutación. En resumen, la Internet o una intranet como se definió
por los IETF RFC esperan que el conmutador/puente/enrutador aprenda
pasivamente la dirección MAC del anexo o que el
conmutador/puente/enrutador suministre un mecanismo para el manejo
de poblar estadísticamente las tablas de envío.
Así, la conmutación de acuerdo con esta
realización de la presente invención emulará el comportamiento de
un puente de aprendizaje. Las radiodifusiones de entrada, tal como
la Estructura de Ethernet estándar ilustrada en la Fig. 23, serán
analizadas y las direcciones de fuente colocadas en los envíos
apropiados CAM. Esto se logrará mediante los microprocesadores FPGA
incrustados independientes del lógico de envío de paquete dentro de
los FPGA. Lo siguiente ilustra el descubrimiento de la dirección MAC
dinámica:
Se recibe un paquete de radiodifusión en un
puerto de ingreso de conmutación. El paquete se pasa a través del
lógico de envío hasta que el Director de Tráfico maneja el marco al
Controlador de Manejo Móvil (MMC) por vía del FIFO de marco.
El MMC extraerá la dirección de fuente del
encabezador de capa de enlace de datos.
El MMC encapsulará la dirección de fuente y el
número de puerto de conmutación de ingreso en un mensaje IPMI y
enviará el mensaje por vía del SPI con base en el bus IPMI al
microprocesador sobre la Tarjeta Portadora
(IPMC).
(IPMC).
El IPMC capturará la dirección de fuente y el
número de puerto de conmutación en un cache de tabla de envío que
será evaluable mediante una entidad de manejo basada en SNMP por vía
RAC.
El IPMC radiodifundirá el mensaje de
actualización CAM a todos los otros MMC en el conmutador.
El microprocesador interno recibirá el mensaje
de actualización CAM y actualizará su CAM de envío al colocar la
dirección MAC del mensaje de actualización CAM en la entrada CAM en
el desfase representado por el número del puerto de
conmutación.
\newpage
Se notará que este procedimiento de tabla de
envío completa puede necesitar ser modificado extensivamente para
soportar más topologías robustas, es decir, múltiples nodos sobre
segmentos LAN anexos.
Preferiblemente, un FIFO de ancho de 32 bits que
es leído por el microprocesador interno para acceder a los marcos
seleccionados en la corriente de datos. El FIFO será escrito por el
lógico de envío con la Etiqueta de Enrutamiento Interna y los
primeros 32 bytes del paquete de entrada. Un registro de estado se
lee para determinar cuando esta vacío el FIFO.
Como se describió previamente, el control FPGA y
los archivos de registradora de estado son accesibles a través del
Mecanismo de Control de Acceso de Registradora por medio del cual
los mensajes encapsulados IPMI se dirigen al microprocesador en el
FPGA quien luego efectúa la lectura o escritura del registrador
actual. En una realización, el microprocesador actúa como un
Controlador de Acceso de Registradora (RAC) que interpreta el
mensaje RAC, determina que elemento lógico de envío/Controlador de
Acceso Sub-módulo (SAC) es dirigido al mensaje y
facilita el acceso de registradora con el SAC. El estado/respuesta
resultante se regresa al originador del mensaje. La Fig. 22 muestra
un diagrama de bloque de una realización del bus SAC. Se entenderá
que el bus SAC es único al sub-módulo y puede tomar
muchas formas.
El estado de las especificaciones IEEE de que la
dirección de destino del paquete PAUSE se puede ajustar a el DA
único de la estación que se va a pausar, o a la dirección
multi-difusión globalmente asignada
01-80-C2-00-00-01
(hex). Además, los paquetes con la dirección
multi-difusión de paquete PAUSE no se enviarán por
un puente lo cual asegura que el marco no se puede propagar más
allá del segmento de enlace local. El campo de los Parámetros de
Control MAC designa el número de veces de bit para pausar, desde 0 a
65535. Una PAUSE recibida antes de la expiración del período de
PAUSE previo, resulta en el nuevo valor de tiempo de bit que
reemplaza el valor del período de PAUSE habitual. Esto le permite
al período de PAUSE reestablecerse a cero, permitiendo que el
tráfico se
reasuma.
reasuma.
Preferiblemente, el chip MAC acomoda dos modos
de control de flujo. Cuando se configura en un modo
full-duplex el chip MAC puede generar
automáticamente los paquetes PAUSE. La retro presión desde el bus
SPI-4.2 origina que el chip MAC ingrese al FIFO
para llenar, al establecer marcas de agua altas y bajas apropiadas
el chip MAC manejará la señalización de PAUSE de inicio y
detención. El segundo modo de puenteado de los FIFO están basados
en el control de flujo SPI-4.2 que envía mensajes
para generar los paquetes de inicio y detención de PAUSE.
Una máquina de estado de puerto se mantendrá
para cada puerto de conmutación sobre una Tarjeta de Puerto. La
máquina de estado será accesible mediante tanto el lógico FPGA como
el microprocesador. La máquina de estado como se explica en este
documento contiene tres elementos básicos; un evento, un estado
definido y una acción efectuada cuando se ingresa a ese estado. Los
eventos definidos anteriormente disparan las transiciones de estado
en estados que a su vez efectúan acciones como lo muestra el
diagrama en la Fig. 24 y el diagrama de estado en la
Fig. 25.
Fig. 25.
La Fig. 32 ilustra una realización donde el
dispositivo de hardware adaptable, es decir, el motor de
comunicación Virtex LX 200, se configura en una conmutación de
puerto 48 al acoplarlo con los motores de comunicación Virtex Pro 4
que constituyen los "puertos" de ingreso y egreso. El problema
con esta configuración es que la disposición de conmutación se
limita a manejar un protocolo único para los paquetes de datos
conmutados a través de la disposición de conmutación que estaría
soportada por los motores de comunicación Virtex Pro 4.
La Fig. 33 ilustra una arquitectura específica
de un conmutador de acuerdo a la presente invención donde los OPE
forman los motores de procesador de puerto y el conmutador digital
puede ser un motor de comunicación Virtex LX 200 o un OPE de
propósito especial que forma una estructura de conmutación
re-programable inteligente. A diferencia de la
disposición de conmutación mostrada en la Fig. 32, la realización de
la Fig. 33 que utiliza el OPE de acuerdo con la presente invención
suministra para una disposición de conmutador/ puente
multi-protocolo capaz de manejar paquetes de datos
de cualquiera de una pluralidad de protocolos soportados por los
OPE. La Fig. 33 ilustra esquemáticamente una configuración
específica del conmutador de la presente invención.
Además de los eventos generados cuando se
ingresa a un estado el microprocesador necesitará monitorear el
chip MAC, los SFP y escuchar a los eventos IPMI y los mensajes con
el fin de suministrar los eventos que originan transiciones del
estado de puerto de conmutación. Nótese que cualquier evento puede
ocurrir en cualquier estado y debe ser tomado y manejado
apropiadamente. En el interés de claridad el diagrama de estado no
muestra todas las transiciones de estado potencial. También, la
mayoría de los eventos de transición originan mensajes de evento
IPMI para ser generados y potencialmente trampas SNMP.
El estado INIT es el estado inicial del puerto
de conmutación en la instantación de la máquina de estado de
puerto. Cuando este estado es ingresado la primera vez el SFP es
posibilitado y el evento TX_ENABLE generado a menos que el puerto
se haya deshabilitado administrativamente.
Cuando un puerto de conmutación ingresa al
estado ENABLED, se efectúa una revisión para determinar si existe
el SFP. Si existe el SFP se genera un evento MOD_DETECT.
\newpage
Un puerto de conmutación que ingresa al estado
FAULTED se considera caído. Se requiere la intervención humana para
la transición hacia fuera de este estado.
MOD_EXISTS - se efectúa una revisión sobre la
señal óptica cuando ingresa a este estado. Si la señal es normal
entonces se genera un evento SIGNAL_DETECT.
Se verifica la sincronización de palabra en el
estado SIGNAL. Si la señal ha sincronizado se genera un evento
SIGNAL_SYNC.
SYNCed. Después de que se ha sincronizado la
señal se efectúa una revisión para determinar si se ha completado
la auto-negociación Ethernet. Si la
auto-negociación Ethernet se ha completado se genera
un evento AUTO_NEG_
DONE.
DONE.
En el estado UP, el puerto de conmutación es UP
y es capaz de enviar marcos a la estructura de conmutación. Sin
embargo, no se ha aprendido la dirección MAC del nodo conectado.
En el estado READY el puerto de conmutación es
operacional.
En otra realización de la presente invención, la
conmutación de paquete sin pérdidas se implementa a lo largo de las
mismas líneas que la discusión del enrutamiento de flujo discutió en
The Next Generation of IP-Flor Routing, por el Dr.
Lawrence G. Roberts, Fundador de, CTO Caspian Networks en la
Conferencia Internacional SSGRR 2003S, L'Aquila Italia, Julio 29,
2003, pero utilizando configuraciones de motor
multi-protocolo como se han descrito.
Adicionalmente, los conceptos descritos en el documento se pueden
extender para implementar el control de flujo de extremo a extremo
en el OPE de la presente invención de acuerdo con las
recomendaciones de la fuerza de tarea IEEE 802.3 AR sobre el
control de flujo y el manejo de congestión.
Aplicado a las etapas que comprenden una
realización del OPE descrito aquí, se puede implementar una Pausa
por nivel de QOS con un Motor (que consiste de tres Procesadores de
Etapa: (a) un Procesador de Corriente de Bit unido a cada una de
las dos interfases XAUI requeridas; (b) una Generación Clave de
Revisión para identificación de Flujo o Etapa de Clasificación de
Flujo de Identificación de Prioridad de Tráfico basado en Regla; (c)
una etapa de procesador para generar una notificación de retro
presión apropiada a un Apilado de Protocolo de capa superior o a un
pesebre buffer, para cumplir con las recomendaciones de prospección
de la Fuerza de tarea IEEE802.3 AR sobre el Manejo de Control y
Congestión de Flujo. La necesidad de identificación de prioridad
esta subrayada en P802.3ar "Congestion Management Why Priorityl
Class Based PAUSE is Required?", Asif Hazarika
(ahazirik@fma.fujitsu.com) y Bob Brunner (Robert.
Brunner@ericsson.com).
El Bloque entonces, tiene dos interfases XAUI y
una o dos interfases SPI 4.2 implementadas con procesadores de
etapa. Con la adición del Director de Tráfico de la Etapa de
Conmutación, el Bloque también se podría utilizar para
identificación de Tráfico entrante y Dirigirla al motor Crypto o
motor de procesamiento con base en la etiqueta VLAN o cualquier
otra identificación de banda. Esto se podría implementar con un 8
SerDes Port Xilinx (FX-40). Alternativamente, se
podría utilizar un AMC. Esta tarjeta también cumple el tercer
requisito (seleccionar el XAUI para I/O desde el RTM o el Panel
frontal).
Se entenderá que en términos de procesamiento de
flujo por el OPE de la presente invención, se denomina circuito
programable si la funcionalidad se puede cambiar cada ciclo de
reloj. Esto es lo que se denomina normalmente como un procesador.
El procesador se define por la arquitectura de conjunto de
instrucción (ISA) y el archivo de registro (RF). Esto es lo que se
denomina el punto de vista del programador de un procesador y que es
la interfase entre el hardware que constituye el procesador y el
software que se puede ejecutar en el procesador. Ver, Thomas
Henriksson, "Intra-Packet DataFlow Protocol
Processor", Linkoping Studies in Science and Technology,
Dissertation No. 813; y John L. Henessy y David A. Patterson,
"Computer Architecture: A Quantitative Approach", Morgan
Kaufman Publishers, Inc., ISBN
1-55860-329-8,
Segunda Edición 1996. En el contexto de la presente invención, cada
Ciclo se convierte en - un intervalo de arrivo de dato - en donde
los datos se deben procesar. Analogizando a un ISA, las etapas del
OPE se pueden definir como Flujo PSA - Arquitectura de Conjunto de
Procesamiento de Flujo - y el RF como el Archivo de Registro de
Cadena. Un ISA, es un conjunto de Micro Código, que efectúa la
Traída (Instrucción y/o Dato), Decodificación, Diferimiento (para
conseguir más datos), Ejecución (las instrucciones sobre los Datos),
Secuencia de Almacenamiento (Modelo Von Newman). La funcionalidad
del Flujo PSA se puede denotar similar-
mente.
mente.
Se describirá una realización de la extensión
IPMI que se utiliza para conectar todos los controladores IPM al
chasis en una realización de la presente invención. Para una
descripción más detallada de este aspecto de la realización de la
presente invención, se hace referencia a la Patente US 2 007 255 430
titulada "Shelf Management Controller with Hardware/Software
Implemented Dual Redundant Configuration".
Las Figs. 36A y 36B describen un diagrama de
bloque que ilustra un controlador de auto manejo o ShMC 230 de
acuerdo con una realización de la presente invención. Como se
describió en el diagrama de bloque de las Figs. 36A y 36B, la
presente invención suministra un primer ShMC 310 acoplado de manera
comunicativa con un segundo ShMC 315 en una disposición simétrica
para suministrar una funcionalidad de auto manejo de estante
utilizando una arquitectura activa/de espera con
"fail-over" automático. En una primera
realización, cada uno de los ShMC 310 y 315 son arquitectónicamente
idénticos. Cada ShMC 310(315) incluye un procesador
independiente 320 que corre un sistema operativo de huella pequeño
(OS) 325 tal como por ejemplo, el ucLinux OS con un apilado
delgado. El ShMC 310 (315) opera con energía de espera y obtiene
variables de salud del sistema al consultar autónomamente los
Controladores de Manejo de la Plataforma Inteligente (IPMC) 235. El
ShMC 310(315) se configura para detectar una anomalía,
anotar el evento, generar y transmitir alertas para notificar al
sistema de la anomalía e iniciar las acciones de recuperación.
Como se describió en la Fig. 36A, cada ShMC
310(315) se conecta a por lo menos dos buses I2C/IPMB
IPMB-A 270 e IPMB-B 275. El ShMC
310(315) se puede disponer en un modo "failover"
I2C/IPMB activo-activo o
activo-pasivo. Esta realización de la presente
invención contempla un sistema de mensaje unificado que pasa
mensajes sobre un Canal Abstraído (AbCh). En esta realización de la
presente invención, un canal es un enlace físico tal como por
ejemplo, I2C, JTAG, Canal de Actualización y de Espacio Libre. En la
visión AbCh, cada canal tiene atributos tal como por ejemplo, un
canal cliente servidor, canal homólogo, canal esclavo maestro que
indica la dirección de las consultas y respuestas, capacidad en
términos de ancho de banda, latencia, y CoS o QoS, senda principal,
senda alternativa, canal de retroalimentación, tal como por ejemplo,
reconocimiento de echo o positivo de mensaje. Los atributos se
asumen para ser programables o asistidos por hardware con buffers,
por ejemplo. Todos los estados de atributo se pueden sondear y
pueden así soportar por ejemplo registradores. El AbCh le permite
al sistema de mensaje enrutar los mensajes a deseo o según las
necesidades de un cambio del sistema. Preferiblemente, se puede
utilizar una herramienta de programación GUI para crear uno o más
canales para una plataforma de hardware dada, para pasar atributos
a la plataforma de hardware y medir el desempeño, correr
simulaciones, y así sucesivamente. Un experto en la técnica
reconocerá fácilmente que la capacidad de ejecutar instrucciones
sobre el EEPROM posibilita que sean escaladas las aplicaciones.
En referencia de nuevo a la Fig. 36A, el modelo
del sistema de mensajes IPMI de acuerdo con la presente invención
se describe como un sistema de mensajes
cliente-servidor doble. El esquema de mensajes
cliente-servidor entre múltiples componentes de
estante utiliza una capa de abstracción de canal para mantener la
independencia de capa. El ShMC 310 está acoplado comunicativamente
con el ShMC 315 mediante un canal de actualización dedicado 330 y
un canal de control activo 335. El canal de actualización 330 está
adaptado para transmitir bidireccionalmente la sanidad y la
información de estado entre los ShMC 310(315). Dos casos del
sistema de mensajes basados en cliente-servidor
corren en cada ShMC 310(315). En una realización de ejemplo,
el ShMC 310 activo (por ejemplo) se puede designar el servidor en
el arranque del sistema, por ejemplo, sin partir del alcance de la
invención. El ShMC 315 se designará entonces al cliente. El ShMC
310 activo ejecuta los conjuntos de comandos para efectuar
funciones de auto manejo luego de recibir la información de estado
desde los IPMC 235.
En la realización de ilustración de las Figs.
36A y 36B, el procesador independiente 320 del ShMC 310(315)
está dispuesto en comunicación con un Procesador de Corriente de Bit
(BSP) 340 dispuesto con al menos una interfase de procesador que es
genérica para todos los tipos de interfase incluyendo sin limitación
IPMI 1.5 sobre IPMB, la Interfase de Línea de Comando (CLI) sobre
el Puerto Serial, Telnet, y el Secure Shell SSH. En una
realización, el ShMC 310(315) incluye un puente
RCMP-IPMI 312, implementado utilizando el BSP 340,
por ejemplo, que puentea sobre los mensajes RMCP e IPIM. Cuando se
recibe un paquete de mensajes RMCP desde el manejador del sistema,
el paquete se abre y se examina para el Puerto UDP #. Si el Puerto
UDP # coincide con el mensaje IPMI el paquete se elimina de su
encabezado y se encapsula el encabezado IPMI (si existe alguno).
Entonces el mensaje se envía a la interfase apropiada. El kernel
ShMC puede solicitar una Copia de Regreso. Un mensaje IPMI al
Manejador del Sistema se encapsula y se envía sobre el Puerto Físico
del Manejador del Sistema.
Las Figs. 37A y 37B ilustran una implementación
de ejemplo de la máquina de estado finito de hardware I2C
(HFSM)475 utilizando el BSP 440. En esta realización, el BSP
es el Procesador de Corriente de Bits
Multi-protocolo como se describió de acuerdo con la
presente invención. El BSP se configura para un procesamiento de
senda de datos de paquete con velocidad de cable de la corriente de
bits sobre los buses IPMB-A 270 y el
IPMB-B 275. El BSP se adapta para ensamblar los
bits en la corriente de bits en las unidades de datos (información)
de protocolo definidas y procesar las unidades de datos
(información) de protocolo ensambladas para suministrar un
rendimiento a velocidad de cable sin importar el protocolo
encontrado. Ambas funciones se programan de manera dinámica
utilizando, por ejemplo, el RAC/SAC (487/489) como se discute
adelante. Así, las unidades de información de un protocolo o las
reglas de procesamiento que aplican a las unidades de datos
(información) del protocolo son inherentemente cambiables de una
manera dinámica.
En una realización, el HFSM 475 incluye el BSP
440 configurado con una secuencia seleccionada de los motores en
etapa encadenados. Cada motor de etapa puede tener una arquitectura
diferente, extensible y re-programable que origina
una instanciación de una máquina de estado finito de dispositivo
(DFSM) 480 para cada IPMC 235 que transmite un mensaje (por
ejemplo, sistema de salud, temperatura, revolución de ventilador,
etc.) al HFSM 475. Los DFSM 480 se configuran ventajosamente para
comunicación de flujo de datos a un motor de etapa del BSP 440
adaptado para instanciar la máquina de estado finito de mensajes
(MFSM) 485. De manera general, el FSM (así como también los DFSM y
el MFSM) utilizan tres construcciones básicas. El HFSM mantiene una
tabla de acción que contiene la acción a efectuar cuando los
eventos dados se reciben mientras que el FSM está en un estado
dado, una siguiente tabla de estado que contiene el siguiente estado
para ingresar cuando se recibe el evento dado mientras que el FSM
está en un estado dado y un manejador de evento que maneja el
procesamiento de evento cuando se presente con un evento, revisa y
efectúa las acciones necesarias y actualiza la información de
estado corriente. Los archivos de registro de control y estado de la
máquina de etapa (o el BSP o el FPGA) son accesibles a través de un
mecanismo de Control de Acceso de Registro (RAC), 487 por medio del
cual los mensajes encapsulados IPMI se dirigen al microprocesador
en la máquina de etapa (o BSP o FPGA) que efectúa entonces el
registro de lectura o escritura actual. El microprocesador actúa
como un Controlador de Acceso de Registro (RAC) que interpreta el
mensaje RAC, determina a cual elemento lógico de envío/Controlador
de Acceso Sub-módulo (SAC) 489 se dirige el mensaje
y facilita el acceso de registro con el SAC. El estado/respuesta
resultante se regresa al originador del mensaje. El RAC/SAC 487/489
suministra unos medios para establecer o cambiar los métodos de
mensaje por dispositivo (es decir, IPMC 235) al vuelo, suministrando
así un mecanismo que implementa el nivel de programabilidad y
flexibilidad de la presente
invención.
invención.
En una realización, el HFSM 475 se adapta para
detectar la falla del bus I2C así como también la falla del
dispositivo. Si se determina que la falla va a estar en un
dispositivo monitoreado por uno de los IPMC 235, el ShMC
310(315) deshabilita ese dispositivo de acceso al
retroplano.
En referencia de nuevo a la Fig. 36A, el cliente
315 monitorea las consultas y respuestas del ShMC 310 activo
utilizando el canal de actualización 330 y computa los estados de
las transacciones y sincroniza estos estados con el ShMC activo
310. En caso de que el cliente ShMC 315 detecte una condición de
error en el ShMC 310, éste reporta el evento al manejador del
sistema 265 que actúa como el árbitro y actúa para remover el ShMC
310 activo y posibilita al ShMC 315 de espera para completar la
migración sin una actualización del estado de consumo de tiempo.
Aunque la presente realización está bien adecuada para operación con
sistemas de cumplimiento AdvancedTCA, también trabajará en un
ambiente MicroTCA donde la espera tri-establecida
está prescrita como se ilustra en la
Fig. 36B.
Fig. 36B.
En otra realización, el ShMC 310(315) se
aumenta por medio de una pila de protocolo ayudada por un hardware
delgado. Otra realización del sistema implementa un esquema de
puente OS para asegurar una implementación diminuta y manejable
ShMC. La realización principal incluye un EEPROM para ejecutar
instrucciones, tal como por ejemplo un EEPROM con un TINY CHIP que
utiliza conceptos de sistema sobre chip (SOC), que posibilitaría el
escalamiento inteligente de costos de las capacidades del procesador
ShMC 320.
En una realización, la configuración ShMC
310(315) redundante doble se utiliza para introducir una
operación tolerante de falla del controlador de manejo de estante.
En una primera realización, los puntos de revisión se insertaron al
agregar un estado de punto de revisión adicional en el HFSM 475.
Cuando un estado corriente en el HFSM 475 es el estado de punto de
revisión, se puede iniciar un proceso de punto de revisión. Siendo
indicados los errores, el HFSM 475 puede iniciar una migración al
ShMC 315 sobre el bus de uso exclusivo 335 y se inicia un proceso
de recuperación sobre el ShMC 310 sin introducir una anormalidad en
el estante ATCA. El proceso de recuperación se puede hacer al
reestablecer los estados de falla interna al ShMC 310 al repetir
los estados registrados almacenados en el ShMC 315 en su orden
original para recrear el estado de pre-falla del
ShMC 310. En otra realización, se puede utilizar un ShMC 492
adiconal para aumentar el ShMC 310(315) y se obtiene el
estado correcto al votar entre las tres o más copias de los estados
mantenidos entre los tres o más ShMC. En una realización, los
resultados votados se cargan en los registradores de cada uno de los
HFSM 475 para propósitos de resolver cualquier de los votos
en
conflicto.
conflicto.
En una realización de la presente invención
ilustrada en la Fig. 38, se muestra un procesador de protocolo de
corriente de bit (alternativamente denominado como el procesador de
protocolo de corriente de bit con base en puente o simplemente como
el procesador de protocolo de corriente de bit) que suministra una
arquitectura de puente de dos vías SPI 4.2 a XUAI. El primer tipo
de interfase de transmisión de datos en serie corresponde a una
interfase SPI 4.2 y el segundo tipo de interfase de transmisión de
datos en serie es la interfase XAUI.
El procesador de protocolo de corriente de bit
de esta realización suministra puentes dobles SPI 4.2 a XAUI. El
SPI 4.2 suministra una interfase bidireccional punto a punto
paralela. La Estructura SPI 4.2 soporta hasta un máximo de 256
puertos. Los datos se envían a través de un marco
SPI-4.2 utilizando los 16 carriles de datos LVDS,
como un paquete completo o como unas ráfagas de datos múltiples por
puerto. Un encabezado de palabra de control puesta al final de los
datos sub-canal delinean las ráfagas. El inicio del
bit del paquete (S) y el final de los bits del estado del paquete
(EOPS) en la palabra de control se utilizan para identificar un
paquete completo que se puede hacer de múltiples ráfagas. Los bits
de dirección [0:7] se utilizan para definir un
sub-canal. El control de flujo y la información de
estado se transportan fuera de la banda, por
sub-canal. El ancho de banda de interfase puede
variar desde 10 Gbit/s para aplicaciones de cargo de trabajo bajas
a 20 Gbit/s para aplicaciones tales como estructuras de conmutación
que necesitan aceleración de ancho de banda con el fin de soportar
información de carga
de trabajo.
de trabajo.
Se verá que para 10GigE cada procesador de
protocolo de corriente de bit puede soportar 10Gbps completamente
duplex por puerto. Haciendo posible lograr una capacidad de
rendimiento de conmutación de 2.560Tbps. Para 40GigE, cada
procesador de protocolo de corriente de bit puede soportar 40Gbs de
duplex completo por puerto, haciendo posible lograr una capacidad
de rendimiento de conmutación de 10Tbps. En general, se reconocerá
que la naturaleza reconfigurable y programable del motor
multi-protocolo de acuerdo con la presente invención
le permite a los procesadores ser inherentemente escalables sobre
un rango de velocidades de reloj.
\newpage
Se reconocerá que el procesador de protocolo de
corriente de bit de acuerdo con una realización de la presente
invención puede suministrar N interconexiones entre, por ejemplo, el
procesador del sistema (CPU) del PC y la memoria del sistema. Cada
una de las interconexiones N se pueden configurar para transferir
datos a 10Gbps que resultan en una eficiencia escalada de 10N Gbps.
El SPI 4.2 es una interfase punto a punto entre los dispositivos
localizados con unas pocas pulgadas una de otra. En un sistema es a
menudo deseable interconectar dispositivos SPI 4.2 que se localizan
en diferentes tarjetas con un chasis por vía de un plano trasero
(Intra Chasis) o localizado en diferente chasis (Inter Chasis).
Bajo tales circunstancias es ventajoso utilizar una serie de
enlaces punto a punto de la presente invención que suministran
conexiones de ancho de banda alta en el Intra-Chasis
o en ambientes de Inter-Chasis. Los enlaces en serie
de ejemplo incluyen ASI que utiliza PCI-Express,
Ethernet que utiliza XAUI, e Infiniband que utiliza IB. Esto en
efecto traduce conectar cualquiera de las dos de cientos posibles
dispositivos SPI 4.2 geográficamente separados con una interfase de
"Alambre Virtual". En una realización, la presente invención
se puede configurar como una computadora de tablero única (PC). En
otra realización, la presente invención suministra para una
ubicación de estándares de la industria (tal como picoTCA por
ejemplo) con hojas removiblemente unidas que soportan pago de campo
en la medida en que usted va a actualizaciones de usuario
final.
Para transportar la palabra de control, que
incluye direcciones de puerto, datos y la salida de información de
control de flujo de banda disponible en las interfases SPI 4.2 en
paralelo que utilizan enlaces en serie, o por vía de un alambre
virtual, se utiliza un protocolo de túnel. Para asegurar una
utilidad de ancho de banda alta estos protocolos de túnel son
preferiblemente de peso ligero. Las características del túnel se
pueden incrustar en los dispositivos SPI 4.2 o un chip de puente se
podría utilizar en conjunto con los dispositivos SPI 4.2 apra
suministrar esta conversión. Para soportar este puenteo entre los
dispositivos SPI 4.2 que utilizan varias interfases en serie
utilizando protocolos de túnel de maduración, el puente es
programable. En esta realización, el puente basado en procesador
del protocolo de corriente de bit que suministra las interfases SPI
4.2 a XAUI y otras interfases en serie y los medios flexibles para
varios protocolos de túnel. El procesador de protocolo de corriente
de bit ofrece programación dinámica y extensibilidad de función como
se describe en el Apéndice A que se incorpora aquí en su
totalidad.
En referencia ahora a la Fig. 39, se muestra
otra realización del procesador de protocolo de corriente de bit.
En esta realización, el procesador de protocolo de corriente de bit
hace interfase directamente con el bus lateral frontal (FSB),
eliminando de esta manera ciertos de los procesos de traducción en
el procesador de protocolo de corriente de bit descrito en relación
con la Fig. 38. Además, el procesador de protocolo de corriente de
bit de la Fig. 39 suministra unos traductores paralelos en serie
tanto de tubo de inclinación como de tubo plano, permitiendo así la
agregación selectiva de uno o más puertos Ethernet para las
configuraciones de tubo plano.
En una realización, el procesador de protocolo
de corriente de bit permite la conmutación del paquete QoS con
velocidad de línea que se utiliza para implementar una credencial
simple basada en comunicación en Ethernet. La dirección fuente (SA)
y la dirección destino (DA) y el tipo E como la Etiqueta VLAN se
utiliza para negociar una credencial única entre los puntos finales
sobre un enlace de comunicación. Las extensiones de tipo E pueden
ser, por ejemplo, Solicitud de UNIQUE ID o TOKEN GRANT; comunicación
de datos con el token dado y solicitud para retirar el TOKEN. Una
vez que se ha otorgado el TOKEN, los campos SA y DA se utilizan
junto con el tipo E para pasar a una fecha pronta. Esto también
puede extenderse para incluir grandes bloques de datos para STA, y
SAS. En otras realizaciones, una vez que un UNIQUE ID se negocia
entre los puntos finales y el nodo intermedio que conecta estos
puntos finales, se utiliza un tamaño de marco fijo para dotar el
enlace con un desempeño predecible en transferir el marco fijo y
cumplir consecuentemente varios requisitos de latencia. Por
ejemplo, el par SA/DA se puede utilizar para transmitir 12 bytes de
datos, 2 bytes tipo E y 2 bytes TAG, en lugar de los tradicionales
64 byte de datos útiles para un paquete Ethernet convencional. Para
una descripción más detallada de una realización de esta técnica de
comunicación Ethernet extendida, se hace referencia a la patente US
2 008 056 277 titulada "Enhanced Ethernet Protocol for Shortened
Data Frames Within a Constrained Neighborhood based on
Unique ID".
En otra realización, la misma interfase podría
suministrar una estructura de tamaño de bloque 2K fijo para Disco -
(los datos siguen el Tipo E y TAG). A este respecto, la presente
invención posibilita una construcción Ethernet de tamaño de marco
programable como contraria a la construcción de tamaño de marco
variable conocida en la técnica. Esta capacidad puede ser útil
especialmente en tipo de aplicaciones iTDM en razón a que posibilita
empaquetar el tráfico TDM dentro de la estructura del ATCA.
En una realización, el encabezado VLAN Ethernet
se utiliza como un protocolo de túnel para permitirle a los
Conmutadores Ethernet estándar de la industria utilizarse para
conmutación entre cualquiera de los dos dispositivos SPI 4.2
localizados en un ambiente Intra Chasis o Inter Chasis. La
realización principal de la presente invención utiliza Ethernet
Gigabit (GbE) como el segundo protocolo de transmisión de datos. Se
pueden utilizar otros protocolos sin apartarse del alcance de la
presente invención. La palabra de control de
sub-canal SPI 4.2 y la información de control de
flujo se convierte a un encabezado VLAN Ethernet estándar. Los datos
de sub-canal SPI 4.2 se encapsulan con la
información de encabezado al ingreso. Al egreso, la información del
encabezado se despoja del marco Ethernet y convertida de regreso al
marco SPI 4.2 y la información de control de flujo se traduce a las
señales eléctricas SPI 4.2. Adicionalmente, el procesador de
protocolo de corriente de bit suministra unos medios eficientes
para incrustar la Clase de información de servicio y los medios
programables para generar y propagar los mensajes de Manejo de
Congestión.
\newpage
En una realización, el procesador de protocolo
de corriente de bit se configura para soportar interfases tales
como GbE, PCI-Express, RGMII, bus PCI y bus Serial
para hacerlo un dispositivo universal ideal para uso en los
sistemas ATCA y micro TCA. Un experto en la técnica reconocerá que
otras tecnologías interconectadas tales como por ejemplo, la XS4
Ethernet de 10 Gigabit y el Puente HiGig SPI 4.2 de MorethanIP, para
puentear una interfase SPI4.2 a una interfase XAUI para cumplir
requisitos de diseño múltiple tales como el Puenteado de
dispositivo (por ejemplo, NPU a Conmutador Ethernet), aplicaciones
de Retro-plano en Serie, Paquete sobre SONET/SDH o
Ethernet sobre aplicaciones SONET/SDH.
La capacidad suministrada por la presente
invención para interconectar los dispositivos SPI 4.2 que se
localizan en diferentes tarjetas con un chasis por vía de un retro
plano (Intra Chasis) o localizado en diferente chasis (Inter
Chasis) posibilita una realización de la presente invención para
lograr los estándares basados en PC tales como por ejemplo, un
estándar picoTCA o microTCA basado en arquitectura PC.
Una realización del procesador de protocolo de
corriente de bit ilustrado en las Figs. 38 y 39 utiliza
ventajosamente el controlador RAC/SAC que dota el procesador de
protocolo de corriente de bit con programación dinámica y
extensibilidad de función. La estructura del controlador RAC/SAC se
utiliza para programar el procesador de protocolo de corriente de
bit al vuelo. Esta capacidad se puede utilizar para configurar la
hoja (tarjeta) en la cual reside el procesador de protocolo de
corriente de bit. En una realización, la capacidad de programación
dinámica al vuelo se utiliza para prender o apagar la hoja (tarjeta)
incluyendo o removiendo de esta manera la hoja desde el sistema de
computadora. En otra realización se puede utilizar la capacidad de
programación dinámica al vuelo para cambiar el carácter del puente
de tal manera que éste puentea entre el SPI 4.2 y el
PCI-Express por ejemplo. Aquellos expertos en la
técnica reconocerán que otros cambios de configuración se pueden
afectar con el alcance de la presente invención utilizando el
controlador RAC/SAC. Por ejemplo, la programabilidad se puede
utilizar para implementar un QoS real de extremo a extremo para
varios flujos de tráfico a través del sistema de computadora.
En otra realización, el procesador de protocolo
de corriente de bit posibilita priorizar la conmutación. En
conjunto con la arquitectura picoTCA PC modular y escalable del
párrafo anterior, la presente invención permite la creación de una
jerarquía de capa N de multiprocesadores donde N es tanto
independiente del hardware como dinámicamente seleccionable al
alteraren priorización lograda a diferentes subconjuntos de
procesadores en la estructura mediada por el procesador de
protocolo de corriente de bit. Esta realización le posibilita al PC
ser configurado como una máquina de modelo de memoria compartido así
como también una máquina multiprocesadora con modelo de paso de
mensaje. Alternativamente, el PC de acuerdo con una realización de
la presente invención se puede configurar como un servidor, un
controlador de red de área de almacenamiento, un nodo de red de alto
desempeño en un modelo basado en computación de rejilla, o un
conmutador/enrutador en una red de telecomunicación. Se reconocerá
que la misma máquina básica se puede alterar de manera programática
o manualmente en una o más de las máquinas de propósito especial
anteriormente mencionadas y cuando se desee.
Varias modificaciones al método pueden ser
evidentes para un experto en la técnica leyendo esta descripción.
Lo anterior no se contempla para limitar el alcance de la presente
invención, el cual se limita solamente a las reivindicaciones de
adelante.
\vskip1.000000\baselineskip
Apéndice
A
Referencia de Abogado No.
3510.35WO01
\vskip1.000000\baselineskip
\newpage
\newpage
La salida final tuvo la revisión del protocolo
es para determinar el siguiente estado del FSM. La salida del
LookUp BRAM es 18 bits para cada uno de los 2 puertos. Para
revisiones mayores de 10 bits (por ejemplo, tipo E), los datos de
revisión se dividirán entre puertos. Los vectores de salida de 2
puertos serán un ANDed, y las líneas de resultado se decodificarán
en una forma one-hot, permitiendo 18 protocolos
únicos. (Cambiando el BRAM desde 1 k x 18 a 512 x 36 suministrará
36 posibles protocolos, pero temporizando.) Un bloque de 18
registros que contienen un "siguiente estado" están presentes.
Cada uno corresponde a una línea de salia/protocolo. El inicio del
Paquete (SOP) y el Fin del Paquete (EOP) también tendrán
registradores de estado correspondientes. Alternativamente, la
salida del BRAM de Revisión puede ser un estado directamente en los
5 bits más bajos. Esto se indica al codificar la salida de puerto
superior. Esta codificación se alimenta a un comparador para
revisar contra un registro. Etos dos vectores de estado se alimentan
al Estado Next mux. El siguiente estado que viene del FSM
suministra el tercer estado de entrada al lógico Next State. El SOP
y el EOP tienen correspondientes registros de estado que también
son entradas. Este estado resultante se registra entonces y se
retroalimenta al FSM.
Lo que sigue es una referencia bit/bytepara
"endianess" en el ejemplo de instrucción:
NuII/IdIe may only be inserted between
frames.
Valid Data (not of other types)
Start of L2 and Start of Payload In first 32
bits.
Start of L2 in full 64 bits.
Start of L2 in first 32 bits followed by Start
of L2.5 in letter 32 bits.
Start of L2 in first 32 bits followed by Start
of L3 in latter 32 bits.
Start of L2 in first 32 bits followed by Start
of Payload in latter 32 bits.
\vskip1.000000\baselineskip
L2 Reserved
Start of L2.5 in full 64 bits.
Start of L2.5 in latter 32 bits.
- 0a
- Start of L2.5 in first 32 bits followed by Start of L3 in latter 32 bits.
- 0b
- Start of L2.5 in first 32 bits followed by Start of Payload in latter 32 bits.
- 0c
- L2.5 Reserved
- 0d
- Start of L3 in full 64 bits.
- 0e
- Start of L3 in latter 32 bits.
- 0f
- Start of L3 in first 32 bits followed by Start of L4 in latter 32 bits.
Start of L3 in first 32 bits followed by Start
of Payload in latter 32 bits.
\vskip1.000000\baselineskip
L3 Reserved
Start of L4 in full 64 bits.
Start of L4 in latter 32 bits.
Start of L4 in first 32 bits followed by Start
of Payload in latter 32 bits
\vskip1.000000\baselineskip
L4 Reserved
Start of Payload in first 32 bits
Start of Payload in latter 32 bits
EOPa, all bytes are valid
EOPb, not all bytes are valid. The MSByte (which
is guaranteed to not be valid) contains the number of valid
bytes
- 1a
- EOPa & Start of L4 in first 32 bits
- 1b
- EOPa & Start of L4 in latter 32 bits
- 1c
- EOPb & Start of L4 in first 32 bits
- 1d
- EOPb & Start of L4 in latter 32 bits 1e User Definable
- 1f
- User Definable
\vskip1.000000\baselineskip
Valores SAP
\vskip1.000000\baselineskip
Apéndice
B
Referencia de Abogado No.
3510.35WO01
El IPMB se define como un bus serial doble que
conecta todos los controladores IPM en el chasis. El protocolo IPMB
es un sistema de mensajes tipo solicitud/respuesta que indica la
fuente y destino de una solicitud junto con un valor de comando
predefinido que designa la operación a ser efectuada por la
fuente.
\newpage
Cualquiera de los bytes de datos asociados con
la solicitud de comando, siguen el byte de comando y preceden la
suma de control. Las siguientes tablas muestran el cuerpo de los
mensajes de solicitud y respuesta.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\newpage
Todos los mensajes extendidos IPMI CEN
(solicitud y respuesta) contienen un encabezado de byte que indica
la operación extendida que se va a efectuar basada en la siguiente
tabla:
Se utiliza un mensaje RAC para leer los datos de
registro por fuera de la lógica de envío. La siguiente tabla
muestra el formato del mensaje RAC. El mensaje RAC es
La siguiente tabla identifica los registros
lógicos de envío accesibles vta RAC. Los registros lógicos de envío
son registros de 64 bits, desfasado de la dirección base mapeada a
las funciones/módulos lógicos. La dirección base se traduce hacia
los primeros 4 bits de la dirección de mensaje RAC mientras
permanecen 7 bits de la dirección designada al desfase de registro.
Las direcciones base se traducen de acuerdo a la siguiente
tabla
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Claims (9)
1. Un motor de procesamiento de paquete de datos
multi-protocolo para manejar comunicación de paquete
de paquetes de datos entre un procesador y una
producción/estructura de red de alta velocidad que tiene una
velocidad de línea de al menos 10 Gb/segundo, el motor de
procesamiento de paquete de datos comprende:
una porción de ingreso del motor de
procesamiento de paquete de datos que incluye:
una pluralidad de procesadores de etapa de
corriente de bit de ingreso, cada procesador de etapa de corriente
de bit de ingreso tiene una memoria de control programable única
para aquel procesador de etapa de corriente de bit de ingreso;
una interfase de procesador de ingreso al
procesador;
una interfase de red de ingreso a la producción
de red; y
una memoria de paquete de flujo de datos
multi-puerto operablemente conectada a la pluralidad
de procesadores de etapa de corriente de bit de ingreso, la
interfase de procesador de ingreso y la interfase de red de ingreso;
y
una porción de egreso del motor de procesamiento
de paquete de datos que incluye:
una pluralidad de procesadores de etapa de
corriente de bit de egreso, cada procesador de etapa de corriente
de bit de egreso tiene una memoria de control programable única a
aquella del procesador de etapa de corriente de bit de egreso;
una interfase de procesador de egreso al
procesador;
una interfase de red de egreso a la producción
de red; y
una memoria de paquete de flujo de datos
multi-puerto operablemente conectada a la pluralidad
de procesadores de etapa de corriente de bit de egreso, la
interfase del procesador de egreso y la interfase de red de
egreso;
en donde la memoria de control de cada uno de
los procesadores de etapa de corriente de bit es individualmente,
selectivamente, dinámicamente programable con base en una de una
pluralidad de protocolos determinados para un flujo de datos dado
de uno o más paquetes de datos y el proceso de los procesadores de
etapa de corriente de bit del flujo de datos dado como un flujo de
los datos de corriente de bit a través de la memoria de paquete de
flujo de datos multi-puerto de tal manera que el
procesamiento del flujo de datos dado por la pluralidad de
procesadores de etapa de corriente de bit es temporizado de acuerdo
al flujo de datos de corriente de bit y el flujo de datos de
corriente de bit se establece a una velocidad que posibilita la
operación continua del motor de procesamiento de paquete de datos
para toda la pluralidad de protocolos sustancialmente a una
velocidad que es al menos igual a la velocidad de línea de la
producción de red de alta velocidad.
2. El motor de procesamiento de paquete de datos
de la reivindicación 1 en donde la pluralidad de procesadores de
etapa de corriente de bit para la porción de ingreso del motor de
procesamiento de paquete de datos comprende:
un procesador de corriente de bit de etapa de
entrada que hace interfase con una capa física de la interfase de
red de ingreso y establece marcos para el flujo de los datos de
corriente de bit de acuerdo con una de la pluralidad de protocolos
determinados para el paquete de datos dado.
una máquina de estado de etapa secundaria que
analiza los marcos de acuerdo con una de la pluralidad de protocolos
determinados para el paquete de datos dado;
un procesador de etapa de tráfico que maneja el
procesamiento marco para los marcos analizados por la máquina de
estado de etapa secundaria;
un procesador de etapa de programador que maneja
la salida de los marcos desde el procesador de etapa de tráfico,
y
un procesador de corriente de bit de etapa de
salida que hace interfase con los marcos desde el procesador de
estado programado con una capa física de la interfase del procesador
de ingreso.
3. El motor de procesamiento de paquete de datos
de la reivindicación 2 en donde la máquina de estado de etapa
secundaria utiliza un arreglo de revisión clave en la medida en que
la máquina de estado de etapa secundaria analiza los marcos que
incorporan un clasificador de flujo de Palabra de Instrucción muy
Larga Programable (VLIW) que encadena la generación clave para la
disposición de revisión clave.
\newpage
4. El motor de procesamiento de paquete de datos
de la reivindicación 2 en donde el procesador de etapa de tráfico
se implementa como un procesador de flujo de datos que tiene
múltiples segmentos donde los múltiples segmentos en el procesador
de etapa de tráfico se implementan dinámicamente dependiendo de uno
de la pluralidad de protocolos determinado para el flujo de datos
dado.
5. El motor de procesamiento de paquete de datos
de la reivindicación 1 en donde al menos una porción de los
procesadores de etapa de corriente de bit hace interfase con la
memoria de paquete de flujo de datos multi-puerto
utilizando una de una aproximación multiplexada arbitrada o con
división de tiempo con el fin de eliminar la necesidad para cada
uno de los procesadores de etapa de corriente de bit para copiar
algunos o todos los datos en el flujo de datos dado con el fin de
procesar esos datos.
6. El motor de procesamiento de paquete de datos
de la reivindicación 1 en donde la memoria de control de cada uno
de los procesadores de etapa de corriente de bit es seleccionable de
uno de una memoria de instrucción o una memoria de estado y es
individualmente, selectivamente, dinámicamente reconfigurable y
programable utilizando un control de acceso de registro (RAC) y un
sistema de control de acceso de sub-módulo
(SAC).
7. El motor de procesamiento de paquete de datos
de la reivindicación 6 en donde el sistema RAC y SAC se controla
por una interfase de usuario gráfica (GUI) que maneja la generación
de código, el control de flujo, el reporte de desempeño, los
diagnósticos y el mantenimiento del motor de procesamiento de
paquete de datos.
8. El motor de procesamiento de paquete de datos
de la reivindicación 1 en donde la producción de red de alta
velocidad se selecciona del conjunto que consiste de: redes de
almacenamiento, redes de comunicación, redes de procesador y
cualquier combinación de éstos.
9. El motor de procesamiento de paquete de datos
de la reivindicación 1 que comprende además:
un conmutador de paquete de datos de alta
velocidad multi-puerto,
en donde una pluralidad de motores de
procesamiento de paquete de datos están operablemente conectados al
conmutador multi-puerto para formar una disposición
de puente multi- protocolo, y en donde cada una de la pluralidad de
motores de procesamiento de paquete de datos se conecta a diferentes
redes de alta velocidad que se comunican utilizando un protocolo
diferente.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US71056105P | 2005-08-23 | 2005-08-23 | |
| US710561P | 2005-08-23 | ||
| US466367 | 2006-08-22 | ||
| US11/466,367 US7782873B2 (en) | 2005-08-23 | 2006-08-22 | Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2340954T3 true ES2340954T3 (es) | 2010-06-11 |
Family
ID=37772279
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06802072T Active ES2340954T3 (es) | 2005-08-23 | 2006-08-23 | Motor multi-protocolo para procesamiento de corriente de bits reconfigurable en redes de alta velocidad. |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP1934758B1 (es) |
| JP (1) | JP2009506645A (es) |
| AT (1) | ATE447741T1 (es) |
| DE (1) | DE602006010225D1 (es) |
| ES (1) | ES2340954T3 (es) |
| WO (1) | WO2007024844A2 (es) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8189599B2 (en) | 2005-08-23 | 2012-05-29 | Rpx Corporation | Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks |
| EP2506592B1 (en) | 2008-02-25 | 2018-04-18 | TiVo Solutions Inc. | Stackable communications system |
| CN101394349B (zh) * | 2008-10-28 | 2010-09-29 | 福建星网锐捷网络有限公司 | 不同接口设备通信中的数据传输方法及系统 |
| US8477831B2 (en) * | 2010-02-17 | 2013-07-02 | Altera Corporation | Multi-protocol multiple-data-rate auto-speed negotiation architecture for a device |
| EP2741452A1 (en) * | 2012-12-10 | 2014-06-11 | Robert Bosch Gmbh | Method for data transmission among ECUs and/or measuring devices |
| JP5992847B2 (ja) * | 2013-02-26 | 2016-09-14 | 日本電信電話株式会社 | フレーム解析装置 |
| US10102028B2 (en) | 2013-03-12 | 2018-10-16 | Sas Institute Inc. | Delivery acknowledgment in event stream processing |
| WO2015026746A1 (en) * | 2013-08-19 | 2015-02-26 | Q Factor Communications Corp. | Method & implementation of zero overhead rate controlled (zorc) information transmission via digital communication link |
| CN104423984A (zh) * | 2013-08-29 | 2015-03-18 | 比亚迪股份有限公司 | 在线升级方法和在线升级系统 |
| CN113810109B (zh) * | 2021-10-29 | 2022-09-27 | 西安微电子技术研究所 | 一种多协议多业务光纤通道控制器及其工作方法 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4307447A (en) * | 1979-06-19 | 1981-12-22 | Gould Inc. | Programmable controller |
| US6721872B1 (en) * | 1999-10-25 | 2004-04-13 | Lucent Technologies Inc. | Reconfigurable network interface architecture |
| US6934817B2 (en) * | 2000-03-31 | 2005-08-23 | Intel Corporation | Controlling access to multiple memory zones in an isolated execution environment |
| US6934280B1 (en) * | 2000-05-04 | 2005-08-23 | Nokia, Inc. | Multiple services emulation over a single network service |
| US6665755B2 (en) * | 2000-12-22 | 2003-12-16 | Nortel Networks Limited | External memory engine selectable pipeline architecture |
| US6934943B2 (en) * | 2001-10-18 | 2005-08-23 | Hewlett-Packard Development Company | Optimization of control transfers to dynamically loaded modules |
| US6671869B2 (en) * | 2001-12-12 | 2003-12-30 | Scott A. Davidson | Method and apparatus for graphically programming a programmable circuit |
| US7343279B2 (en) * | 2002-08-01 | 2008-03-11 | Teradyne, Inc. | Universal approach for simulating, emulating, and testing a variety of serial bus types |
-
2006
- 2006-08-23 DE DE602006010225T patent/DE602006010225D1/de active Active
- 2006-08-23 EP EP06802072A patent/EP1934758B1/en not_active Not-in-force
- 2006-08-23 WO PCT/US2006/032747 patent/WO2007024844A2/en active Search and Examination
- 2006-08-23 AT AT06802072T patent/ATE447741T1/de not_active IP Right Cessation
- 2006-08-23 ES ES06802072T patent/ES2340954T3/es active Active
- 2006-08-23 JP JP2008528063A patent/JP2009506645A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP1934758A2 (en) | 2008-06-25 |
| ATE447741T1 (de) | 2009-11-15 |
| DE602006010225D1 (de) | 2009-12-17 |
| JP2009506645A (ja) | 2009-02-12 |
| WO2007024844A9 (en) | 2008-08-21 |
| EP1934758B1 (en) | 2009-11-04 |
| EP1934758A4 (en) | 2009-01-21 |
| WO2007024844A3 (en) | 2007-11-29 |
| WO2007024844A2 (en) | 2007-03-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2340954T3 (es) | Motor multi-protocolo para procesamiento de corriente de bits reconfigurable en redes de alta velocidad. | |
| US7782873B2 (en) | Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks | |
| US11520394B2 (en) | Network processor FPGA (npFPGA): multi-die-FPGA chip for scalable multi-gigabit network processing | |
| US8189599B2 (en) | Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks | |
| US10305802B2 (en) | Reliable transport of ethernet packet data with wire-speed and packet data rate match | |
| US9100349B2 (en) | User selectable multiple protocol network interface device | |
| US8170044B2 (en) | Pipeline method and system for switching packets | |
| US11695708B2 (en) | Deterministic real time multi protocol heterogeneous packet based transport | |
| US9471388B2 (en) | Mapping network applications to a hybrid programmable many-core device | |
| US6898752B2 (en) | Apparatus and methods for combinational error detection in an InfiniBand switch | |
| EP2291959B1 (en) | A method of data delivery across a network fabric in a router or ethernet bridge | |
| US7286544B2 (en) | Virtualized multiport switch | |
| US9148369B2 (en) | Packet routing with analysis assist for embedded applications sharing a single network interface over multiple virtual networks | |
| US11394664B2 (en) | Network interface device | |
| US9077659B2 (en) | Packet routing for embedded applications sharing a single network interface over multiple virtual networks | |
| CN101578590A (zh) | 高速网络中用于可重新配置的位流处理的全协议引擎 | |
| US9772968B2 (en) | Network interface sharing | |
| US20050018665A1 (en) | Software configurable cluster-based router using stock personal computers as cluster nodes | |
| US20060256793A1 (en) | Efficient multi-bank buffer management scheme for non-aligned data | |
| US20230388251A1 (en) | Tightly-Coupled, Loosely Connected Heterogeneous Packet Based Transport | |
| US20040205252A1 (en) | Methods and devices for converting between trunked and single-link data transmission in a fibre channel network |