ES2263820T3 - Metodo y dispositivo para transferir mensajes snmp por udp con compresion de secuencias que se repiten periodicamente. - Google Patents
Metodo y dispositivo para transferir mensajes snmp por udp con compresion de secuencias que se repiten periodicamente.Info
- Publication number
- ES2263820T3 ES2263820T3 ES02775199T ES02775199T ES2263820T3 ES 2263820 T3 ES2263820 T3 ES 2263820T3 ES 02775199 T ES02775199 T ES 02775199T ES 02775199 T ES02775199 T ES 02775199T ES 2263820 T3 ES2263820 T3 ES 2263820T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- udp
- payload
- snmp
- compression
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 238000007906 compression Methods 0.000 title claims abstract description 34
- 230000006835 compression Effects 0.000 title claims abstract description 34
- 238000012546 transfer Methods 0.000 title claims description 23
- 230000006837 decompression Effects 0.000 claims abstract description 8
- 230000005540 biological transmission Effects 0.000 claims description 18
- 238000004891 communication Methods 0.000 claims description 8
- 238000005538 encapsulation Methods 0.000 claims description 7
- 238000012545 processing Methods 0.000 claims description 4
- 230000000295 complement effect Effects 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 8
- 238000007726 management method Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 4
- 230000032258 transport Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 108091081062 Repeated sequence (DNA) Proteins 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- 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/04—Protocols for data compression, e.g. ROHC
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Método según la reivindicación 8 y 9 o 10, caracterizado porque la etapa de recepción comprende las operaciones de: - recibir (216) el mensaje sometido a dicha etapa de compresión como una carga útil UDP, - someter la carga útil así recibida a una operación (214) de decodificación hexadecimal, - reconocer y ensamblar (212) los enlaces variables del mensaje sometido a la decodificación hexadecimal, y - someter el mensaje reconocido y ensamblado en la operación (212) de reconocimiento y ensamblaje a una operación (210) de decodificación de ASCII a binario, - someter el mensaje decodificado en forma binaria a dicha etapa (204) de descompresión.
Description
Método y dispositivo para transferir mensajes
SNMP por UDP con compresión de secuencias que se repiten
periódicamente.
Esta invención se refiere a la transferencia de
mensajes usando un transporte UDP (abreviatura para "User Datagram
Protocol", protocolo de datagramas de usuario), tal como por
ejemplo los mensajes SNMP ("Simple Network Management
Protocol", protocolo de gestión de red simple).
Estos mensajes se generan y se transmiten dentro
de redes de comunicación de datos, tales como Internet. La
arquitectura de los protocolos de Internet se basa en cuatro capas
lógicas, es decir, aplicación, transporte, red y
enlace.
enlace.
Los mensajes SNMP realizan un mecanismo de
comunicación simple entre un sistema de gestión de red (NMS) y los
nodos que se están gestionando. Esto es posible por las aplicaciones
específicas localizadas respectivamente en la NMS denominada
"Gestor de red" y en los nodos denominados "agentes". Los
mensajes SNMP tienen lugar por tanto en el nivel UDP, utilizándolo
como transporte para tal fin.
La aplicación denominada "agente" (en lo
sucesivo: agente) con su respectivo gestor de red sobre los mensajes
SNMP tiene asociada una base de datos actualmente denominada
"Base de información de gestión" o, por su abreviatura del
inglés MIB. En dicha base de datos se recoge la información relativa
a la gestión y la monitorización del nodo correspondiente o
elemento de red. En particular, dicha información incluye lo
siguiente:
- -
- variables MIB, que pueden leerse por el gestor de red para derivar información sobre el elemento de red;
- -
- variables MIB que pueden escribirse por el gestor de red para provocar acciones en el elemento de red; y
- -
- Eventos (trampas) que el propio agente puede provocar hacia el gestor de red (gestor) con respecto a situaciones específicas.
La comunicación en el nivel SNMP incluye por
tanto esencialmente:
- -
- mensajes necesarios para leer/escribir las variables anteriores (GetRequest, GetNextRequest, SetRequest, GetBulk), enviadas por el gestor de red, y
- -
- mensajes de respuesta (GetResponse) y mensajes trampa, transmitidos por el agente.
El conjunto de todas las variables/trampas
gestionadas por un agente está asociado al elemento de red y
específicamente representan la MIB relacionada, es decir, muestra
el modo de operación y las características intrínsecas del elemento
de red con respecto al gestor de red.
Cada variable o trampa se identifica
individualmente por una cadena en el lenguaje ASN.1 ("Abstract
Syntax Notation One", notación de sintaxis abstracta - uno),
denominada identificador de objeto u OID.
El esquema de la cadena es, por ejemplo, de tipo
"1.3.6.1.2.1.4.21" que indica el hecho de que el lenguaje ASN.1
permite la representación de objetos según una estructura en árbol
jerárquica.
Una parte de la MIB está definida como un
estándar y puede soportarse por cualquier agente, mientras que otras
variables y algunas trampas son específicas de cada fabricante y en
algunos casos características de una tipología de aparato
particular.
El protocolo SNMP, que nació en 1988, ha
sufrido cierta evolución a lo largo de los años. En particular se
han definido nuevas tipologías de mensajes que los agentes deben ser
capaces de entender. El estándar MIB, que cada agente debe poder
soportar, se ha ampliado. En la fecha de presentación de esta
solicitud, las versiones empleadas son las versiones 1 y 2,
mientras que la estandarización de la versión 3 está actualmente en
camino.
El tamaño de una MIB varía según el tipo de
aparato y puede incluso ser del orden de algunos cientos de kBytes,
lo que corresponde a algunos cientos de OID.
El diagrama de la figura 1 de los dibujos
adjuntos muestra los componentes típicos de un mensaje SNMP. El
contenido de cada componente está escrito en caracteres ASCII y su
tamaño máximo permitido es igual al tamaño máximo de un mensaje
UDP, la entidad de datos que lo transporta, igual a 65.507 bytes u
octetos (de los que aproximadamente 64 kbytes están destinados para
la información que debe transportarse).
En particular, en el mismo diagrama de la figura
1 puede observarse la presencia de una cabecera de mensaje y una
parte PDU (unidad de datos de protocolo), de las que la parte
indicada por 1 recoge mensajes tales como GetRequest,
GetNextRequest, SetRequest y GetResponse, y la parte indicada por 2
recoge mensajes GetBulk, mientras que la parte indicada por 3
generalmente se refiere a mensajes tipo trampa.
Más específicamente, en la cabecera de los
mensajes SNMP está presente la siguiente información:
- -
- Número de versión: número de la versión SNMP empleada para la composición del mensaje (V1, V2, V3,...), y
- -
- Nombre de la comunidad: especie de contraseña que permite el acceso a través de la lectura y escritura a los objetos contenidos en el módulo MIB.
La siguiente información está disponible dentro
de la PDU
- -
- Tipo de PDU: tipología de mensaje que en la versión 1 contiene instrucciones tales como GetRequest, GetNextRequest, SetRequest y Request, mientras que en la versión 2 también puede contener instrucciones tales como GetBulkRequest e InformRequest;
- -
- Id. de solicitud: identificador individual del mensaje asignado por el gestor y usado por el agente al responder, para que el gestor pueda asociar la respuesta solicitada con la referencia apropiada;
- -
- Estado de error: ajustado a 0 en todas las tipologías de mensaje, salvo para los mensajes de respuesta en los que, si se ajusta a 1, significa que hay presente un error;
- -
- Índice de error: indica cuál de entre las variables solicitadas (OID) ha provocado el error, y
- -
- Enlaces variables: son pares de OID/valor; siendo los valores "cero" en el caso de solicitudes y compilado en el caso de mensajes de respuesta.
En particular, la parte justo a la izquierda de
la figura 1 muestra una estructura típica de la parte que recoge
los anteriores enlaces variables.
En la presente invención y en las leyendas que
aparecen en algunas figuras de los dibujos adjuntos, se ha optado
por mencionar -para los diferentes elementos en cuestión- los
acrónimos/nombres/iniciales correspondientes en lengua inglesa.
Esto se ha realizado con vistas a una
descripción clara y directa. Los acrónimos, nombres e iniciales
anteriores se usan actualmente a nivel internacional por los
expertos en la técnica ya que no se han desarrollado traducciones a
los diferentes idiomas nacionales a lo largo de los años.
La transmisión del mensaje SNMP, que es posible
a través de UDP, permite el intercambio de paquetes de datos entre
dos ordenadores enlazados a la red. El formato de mensaje UDP
consiste concretamente en una cabecera cuyos datos principales son
la dirección IP del ordenador que transmite el mensaje, la dirección
IP del ordenador de destino y el tamaño de la PDU que se
transporta. A su vez, el formato PDU está formado por una parte de
cabecera y por una parte de datos actualmente denominada "carga
útil" (Payload) u "octeto de datos". La cabecera contiene
por tanto los siguientes datos: puerto de origen, puerto de destino,
tamaño de la unidad transportada, verificación de la integridad
(CHECKSUM) de la unidad de datos.
La metodología actualmente adoptada para
transferir mensajes SNMP a través de UDP (desde el gestor al agente
y viceversa) se basa esencialmente en el hecho de que el mensaje
SNMP completo está codificado mediante la metodología BER ("Basic
Encoding Rules", reglas de codificación básicas). Este modo de
operación permite convertir los bytes que forman el mensaje SNMP en
una estructura hexadecimal adecuada para usarse como carga útil del
mensaje UDP.
El servicio de transferencia UDP de los datos
así obtenidos esencialmente prevé:
- -
- en la fase de transmisión: lectura del mensaje SNMP y codificación hexadecimal posterior (codificación BER) del mensaje, para su transmisión a través de UDP, y
- -
- en la fase de recepción: tras la recepción a través del UDP, decodificación hexadecimal (decodificación BER) del PDU y posterior reconstrucción del mensaje.
La práctica de aplicación actual ha demostrado
que en las redes de comunicación de datos tales como Internet, surge
la necesidad de transferir una masa de información en términos de
solicitudes/respuestas transportadas en forma de mensajes SNMP.
\newpage
Debido al tamaño total de la información, al
tiempo requerido para la transferencia relacionada y al tráfico de
red así generado, las soluciones convencionalmente adoptadas para la
transferencia de mensajes SNMP en un formato estándar generalmente
exhiben una eficacia bastante pobre.
Por esta razón ya se han propuesto tres
especificaciones IEFT, como borrador, para abordar este asunto.
La primera propuesta (conocida como Compresión
del Identificador de Objeto SNMP, rev. Abril 2001 -
draft-ietf-eos-oidcompression-00.txt)
se basa en el concepto de que la mayoría de la información
contenida en la MIB se designa por un OID, formado por una parte
constante y bastante grande y por una parte variable y muy pequeña.
Partiendo de este principio, la propuesta pretende codificar, según
un algoritmo, la parte constante del OID a través de una numeración
más corta. Esta solución optimiza sólo en parte la cantidad de
información que está transfiriéndose, sin reducir considerablemente
su tamaño.
La segunda propuesta (conocida como
"Transferencia Eficiente de Datos SNMP en masa, rev. Abril 2001 -
draft-ietf-eos-snmpbulk-00.txt")
aborda el asunto de la gestión de la instrucción GetBulk que
permite la recogida simultánea de un conjunto dado de información.
La instrucción introducida en la versión 2 SNMP no permite la
optimización de la recogida, puesto que el gestor tiene que
declarar el número de elementos que deben recogerse, sin conocer
cuántos elementos forman el conjunto de información solicitado. Se
han sugerido modificaciones de los protocolos UDP con una
modificación del algoritmo de codificación del mensaje (de BER a
PER, que significa "Packet Encoding Rules", reglas de
codificación de paquetes) o con el recurso a un modo de
transferencia de tipo FTP (acrónimo de "File Transfer
Protocol", protocolo de transferencia de ficheros). La solución
descrita en el documento anteriormente mencionado, es la
introducción de una nueva instrucción en el lado del agente,
denominada GetColsRequest, y el mensaje relacionado en el lado del
gestor, capaz de reconocer el número de elementos que han de
transferirse, identificar el final del conjunto solicitado y
optimizar por tanto el tráfico de solicitudes y respuestas. Sin
embargo, esta solución tampoco permite optimizar la gestión del
tamaño y el número de mensajes que se
envían.
envían.
La tercera solución tenida en cuenta (conocida
como Compresión de la carga útil SNMP - rev. Abril 2001 -
draft-irtf-nmrg-snmp-compression-01.txt'')
es en principio similar a la primera propuesta, puesto que propone
un algoritmo de codificación diferencial denominado "Compresión
Delta OID" o ODC. Partiendo de una base OID, dicha solución prevé
memorizar el OID subsiguiente asignando al OID un código asociado a
la base OID, seguido de la parte variable del OID. Fundamentalmente,
las variaciones se almacenan en términos de incrementos
diferenciales, en comparación con el elemento de base. Esta solución
tiene el inconveniente de ser incompatible con las versiones
anteriores del protocolo. Además, permite un ahorro estimado de
aproximadamente el 30% para valores de OID particularmente
recursivos, es decir, matrices de datos, y es sustancialmente
ineficiente en el caso de un bajo número de elementos
recursivos.
Un documento adicional, M. Degermark, B.
Nordgren, S. Pink, "IP header compression", febrero 1999, IETF
XP002221120, tomado de Internet: URL: www.ietf.org'', D1
describe cómo comprimir múltiples cabeceras IP y cabeceras TCP y
UDP por salto a través de enlaces punto a punto. El solicitante
indica que sólo se comprime la cabecera de un mensaje, mientras que
la dimensión de la carga útil, que es importante en la dimensión
total del mensaje, no cambia.
El objetivo de la presente invención es
proporcionar una solución alternativa en comparación con la solución
expuesta anteriormente, con el fin de permitir una transferencia
optimizada a través de UDP de mensajes tales como mensajes SNMP, sin
afectar el protocolo y el rendimiento en el lado del agente y del
gestor.
Según la presente invención, dicho objetivo se
alcanza mediante un método que tiene las características que se
reúnen en las reivindicaciones adjuntas. La invención se refiere
también de forma separada, al sistema relacionado y al producto del
procesamiento de datos, que puede cargarse directamente en la
memoria interna de un ordenador y que incorpora partes de un código
de software para implementar el método según la invención, cuando el
producto del procesamiento de datos anterior se ejecuta en un
ordenador.
Básicamente, la solución según la invención se
basa en la compresión de todo el mensaje (cabecera y PDU).
En particular, se prevén dos modos diferentes de
transferencia.
El primero encapsula el mensaje SNMP en un nuevo
mensaje SNMP de tipo privado y lo envía de un modo estándar usando
UDP.
El segundo conduce directamente el UDP a través
de un programa "driver" y proporciona el resultado de la
compresión del mensaje SNMP como un octeto de datos.
La técnica de compresión se basa esencialmente
en el reconocimiento de secuencias que aparecen periódicamente
dentro del mensaje.
En una realización particularmente preferida de
la invención, la técnica de compresión que se utiliza es una
variación de la técnica conocida como LZ77 (véase el trabajo de Ziv.
J., Lempel A., "A Universal Algorithm for Sequential Data
Compression", IEEE Transactions on Information Theory, vol. 23,
nº 3, págs. 337-343), muy conocida en el entorno
UNIX y denominada gzip (formato gzip - RFC 1952), también empleada
por el PKZIP, más conocido. Las especificaciones de dicha técnica se
conocen comúnmente y existe bibliotecas fuente disponibles que
implementan y usan dicha solución para entornos de desarrollo y
sistemas operativos diferentes, tales como HP-UX,
Digital, BeOS, Linux, OS/2, Java, Win32, WinCE.
En particular es posible utilizar una traslación
del algoritmo de Win32 empleando una biblioteca "zLib". Para
consulta, puede hacerse referencia a la página web
http://www.infozip.org/pub/infozip/zlib/. La característica
principal de esta biblioteca es permitir la ejecución y la
compresión en memoria de las estructuras y las cadenas de datos
binarios, siendo éste un factor importante relacionado con el
rendimiento del sistema.
La invención se describirá ahora a modo de
ejemplo no limitativo, con referencia a los dibujos adjuntos en los
que:
- la figura 1,
relacionada con la técnica anterior, ya se ha descrito
anteriormente;
- la figura 2 muestra
en la forma general de un diagrama de bloques una arquitectura de
aplicación típica de la solución según la invención;
- las figuras 3 a 5,
cada una subdividida en dos partes relacionadas con la transmisión
(parte a) y la recepción (parte b) respectivamente, ilustran
diferentes tipos de realizaciones de la solución según la invención
en la forma de un diagrama de flujo;
- la figura 6 es otro
diagrama de flujo que ilustra las características generales de la
solución según la invención; y
- las figuras 7 y 8
ilustran, según modalidades sustancialmente similares a las
adoptadas en la figura 1, los criterios de realización de la
solución según la invención, ilustrados en dos posibles
variaciones.
En el diagrama general de la figura 2, la
referencia N indica una red de comunicación de datos (como ejemplo
directo puede considerarse Internet) que define el entorno de
aplicación típico de la solución según la invención.
La referencia A muestra el módulo actualmente
denominado "agente" que lleva a cabo la función de control y
monitorización de un elemento correspondiente de la red N, actuando
en un modo de diálogo bidireccional con un gestor M
correspondiente.
Este último define, junto con un agente A'
adicional de un nivel jerárquico superior, un puerto o compuerta G,
que a su vez es interfaz con un gestor M' adicional de un nivel
jerárquico superior.
Este último define junto con una aplicación
correspondiente un módulo de observación u observador O.
Las referencias C1 y C2 indican dos canales de
comunicación bidireccional que llevan a cabo la comunicación, a un
nivel jerárquico inferior, entre el agente A y la compuerta G, y, a
un nivel jerárquico superior, entre la compuerta G y el observador
O.
Los canales C1 y C2 anteriormente mencionados
son por los que tendrá lugar la transmisión de mensajes
SNMP.
SNMP.
Los diagramas de flujo de la figura 3 ilustran
las modalidades adoptadas para la compresión (figura 3a) y
descompresión (figura 3b) del mensaje SNMP.
Los diagramas de flujo de la figura 4 ilustran
(también en referencia a la transmisión, figura 4a, y a la
recepción, figura 4b) una primera solución que prevé la
transferencia del mensaje SNMP comprimido por encapsulación sobre
SNMP.
Los diagramas de flujo de la figura 5 se
refieren, por el contrario, a una solución de transferencia por
encapsulación sobre UDP. También en referencia específica a la
transmisión (figura 5a) y a la recepción (figura 5b).
Los diagramas de las figuras 7 y 8 ilustran en
relación con la representación del OID el mismo aspecto formal que
de la figura 1 y hacen referencia al conjunto de las operaciones de
compresión y transmisión, ejemplificadas por la parte a) de las
figuras 3 y 4 (figura 7) y la parte a) de las figuras 3 y 5 (figura
8), respectivamente.
Examinando en primer lugar el diagrama de flujo
de la figura 3, la referencia 100 identifica la etapa durante la
que se lee el mensaje SNMP completo (cabecera + PDU) para entonces
convertirlo o codificarlo en un formato hexadecimal durante una
etapa posterior indicada por 102. Esto se lleva a acabo aplicando
una codificación de tipo codificación BER.
El mensaje así codificado se comprime entonces
usando una técnica de compresión basada en el reconocimiento de
secuencias recursivas, tales como por ejemplo la técnica a la que se
hace referencia en la biblioteca zLib, que ya se ha mencionado
anteriormente.
Esto tiene lugar durante una etapa indicada por
104 para obtener durante la etapa indicada por 106 una unidad de
datos comprimida lista para la transmisión.
De un modo totalmente simétrico, el diagrama de
flujo de la parte b de la figura 3 incorpora cuatro etapas, a saber
206, 204, 202 y 200 (designadas para realizarse según la secuencia
indicada), en las que la unidad de datos comprimida recibida (etapa
206) se somete a una descompresión (etapa 204) con vistas a una
posterior decodificación hexadecimal (etapa 202) con una
subsiguiente reconstrucción del mensaje SNMP completo (etapa
200).
El hecho de haber asignado a la parte b del
diagrama de flujo de la figura 3 referencias numéricas clasificadas
en un orden inverso con respecto a su secuencia de realización,
tiene únicamente el propósito de subrayar el carácter simétrico con
las etapas 100 a 106 del método de compresión. Se han realizado
elecciones similares con referencia a los diagramas de flujo de las
figuras 4 y 5.
Tal como ya se ha mostrado, las figuras 4 y 7
hacen referencia a una solución de transferencia que prevé la
encapsulación de la unidad de datos comprimida en un mensaje SNMP
estándar, caracterizado por un "enlace variable" peculiar y
privado, mediante una modalidad de transmisión estándar por UPD.
La modalidad de encapsulación de la unidad de
datos comprimida obtenida durante la etapa 106 incorpora una etapa
inicial, indicada por 108, durante la cual la unidad de datos
comprimida se lee en bytes y se convierte entonces en el conjunto
correspondiente de caracteres ASCII, durante una etapa posterior de
codificación indicada por 110.
En la siguiente etapa, indicada por 112 (que
puede ir precedida posiblemente por funciones auxiliares tales como
ACK TAB+CERO; véase el bloque 110a de la figura 7) se genera el
"enlace variable" del mensaje formado por un primer OID con
una numeración peculiar o privada (por ejemplo 1.3.6.1.4.666.) que
contiene en su valor la cadena _ZIP_xxxx, indicando xxxx el tamaño
del archivo original. En el ejemplo anteriormente mencionado se ha
indicado el código 666.1 peculiar que, de momento, no ha sido
registrado en IANA (Internet Assigned Numbers Authoriy), aunque
podría usarse cualquier otro código no registrado.
Los elementos posteriores del enlace variable
que contiene la unidad de datos comprimida, debidamente convertida
en caracteres ASCII, están formados por parejas OID/valor. El valor
contiene partes de la unidad de datos comprimida, convertida en
ASCII, con un tamaño máximo de 255 caracteres.
Entonces se reconstruye la información de la
cabecera del mensaje SNMP. Todo esto tiene lugar durante la etapa
112 que va seguida de una etapa indicada por 214 en la que se lleva
a cabo una codificación adicional según la metodología BER para
generar una carga útil de PDU del mensaje UDP (carga útil de
PDU-UDP) para usarla en la transmisión de datos
(etapa 116).
También en este caso, las etapas indicadas por
216, 214, 212, 210 y 208, reproducidas en la parte b) de la figura
4 y designadas para realizarse según el orden en el que se han
citado anteriormente, representan las funciones duales; que deben
llevarse a cabo en el lado de recepción, de las etapas 108 a 116
relativas a la operación de transmisión.
Al adoptar la solución a la que hacen referencia
las figuras 4 y 7, el mensaje SNMP comprimido tiene por tanto un
formato SNMP lógico estándar, pero un contenido peculiar o privado.
Así, se requiere una extensión funcional, aunque mínima, del gestor
del agente, por ejemplo para permitir su reconocimiento y la
codificación/decodificación.
Los experimentos llevados a cabo por el
solicitante prueban que una solución de este tipo es completamente
viable sin afectar a la arquitectura de la red.
La solución alternativa a las que hacen
referencia las figuras 5 y 8, prevé la preparación de la unidad de
datos comprimida partiendo del mensaje SNMP, según las modalidades
mostradas en la figura 3, seguido de la encapsulación directa de
dicha unidad de datos en la carga útil de
PDU-UDP.
Obviamente, para un correcto funcionamiento,
esta solución requiere el uso de un transmisor y un receptor
específico, por ejemplo en condiciones que aseguren la
disponibilidad de un puerto UDP diferente del estándar. El
transmisor debe por tanto conocer el puerto UDP que utiliza el
receptor y viceversa. La información sobre los puertos empleados
puede intercambiarse en un nivel superior mediante un mensaje de
sincronización en un formato SNMP estándar, según los criterios que
van a explicarse mejor a continuación.
Cuando se adopta la solución alternativa
ilustrada en las figuras 5 y 8, la unidad de datos comprimida,
facilitada por la etapa 108 y designada para sustituir el BER del
mensaje, se convierte en la carga útil del mensaje
PDU-UDP.
La operación relacionada está esquematizada por
las etapas indicadas por 118 y 120 en las figuras 5 y 8, precediendo
dichas etapas a la etapa 112 de transmisión, designada para el
puerto específico respectivo (generalmente denominado puerto X) del
receptor.
También en este caso, la operación
complementaria incorpora tres etapas, indicadas por 222 (recepción
en el puerto Y del módulo que actúa en ese momento como receptor),
220 (extracción de la carga útil del PDU-UDP), y 218
(obtener la unidad de datos comprimida recibida, designada para
transferirse hacia la etapa 206 de la parte b) del diagrama de flujo
de la figura 3), respectivamente.
También en este caso las etapas 222, 220 y 218
se llevan a cabo según el orden en el que han sido mencionadas.
El mensaje de sincronización que se ha
mencionado anteriormente se envía por el gestor al agente SNMP según
un principio general "aplicación a aplicación" utilizando el
formato SNMP estándar que contiene un "enlace variable"
peculiar o privado.
La información que va a transferirse puede ser
del tipo:
\vskip1.000000\baselineskip
| \hskip1.7cm OID \hskip2.2cm Valor | |
| 1.3.6.1.4.666.2 | <UDP_TX_Port> |
| 1.3.6.1.4.666.3 | <UDP_RX_Port> |
El gestor envía al gestor SNMP un mensaje
privado que compila el valor <UDP_TX_Port> con el número del
puerto designado para usarse para la transmisión UDP (por ejemplo
1024) así como un valor <UDP_RX_Port> con el número del puerto
que utiliza para la recepción UDP (por ejemplo 1224).
El agente replica al gestor enviando un mensaje
similar que contiene su propia información. Este método reduce el
tiempo de procesamiento al mejorar la eficiencia de la solución.
El diagrama de bloques de la figura 6 muestra
adicionalmente cómo la solución descrita puede generalizarse para
aplicarse a cualquier tipología de mensajes que utilicen UDP como
transporte (por ejemplo SNMP, PING, etc.). Esta generalización hace
posible implementar un programa "driver" de UDP capaz de
sustituir los actualmente utilizados.
Esta solución puede evaluar el tamaño de la
carga útil que ha de transferirse, y proceder a continuación,
siempre que el tamaño sea adecuado (por ejemplo: más de 20 Bytes),
utilizando el método descrito en la presente memoria. Para declarar
la naturaleza compacta del mensaje UDP al receptor, pueden usarse
los 8 bits incluidos desde el bit 62 al bit 69 de la cabecera del
mensaje UDP (actualmente estos bits no se usan y se ajustan por
defecto en 0) ajustándose uno o más de los mismos en 1 por
ejemplo.
En particular, en el diagrama de la figura 6, la
referencia 300 indica cualquier etapa en la que surja la necesidad
de enviar un mensaje capaz de ser transportado por UDP, seguida de
una etapa 302 de compresión de la carga útil, realizada según las
modalidades descritas en la figura 3.
Una etapa 304 subsiguiente prevé la generación
de la cabecera del mensaje UDP según los términos anteriormente
expuestos, mientras que una etapa subsiguiente indicada por 306
corresponde a la creación de todo el mensaje UDP con vistas a su
transmisión IP, que se realizará durante la etapa indicada por
308.
La metodología descrita permite la
implementación de una solución con un objetivo general, capaz de
soportar cualquier tipo de aplicación que haga uso de la pila de
protocolos UDP-IP.
Dicha solución es particularmente adecuada para
la implementación de hardware o soluciones "en chip".
Una extensión funcional de la solución descrita
puede aplicarse independientemente de la metodología que se use
para la transferencia de datos y la codificación del mensaje o su
equivalente BER u octeto de datos UDP. A este respecto, un método
seguro y efectivo parece ser el actualmente denominado como
"cifrador de bloque Rijndael", también llamado "AES".
La solución descrita en la presente memoria
tiene la ventaja de permitir la compresión de mensajes SNMP,
superando los inconvenientes descritos en la introducción de esta
descripción, haciendo referencia a una técnica de compresión
flexible, de un modo consolidado, pero también a otras técnicas de
compresión (tales como MPEG). Dicha técnica y su algoritmo pueden
usarse en varios sistemas operativos, lo que hace esta solución una
solución reutilizable y re-implementable. Además,
dicha solución tiene un mínimo impacto tanto en el gestor como en
el agente, puesto que requiere el establecimiento de una sencilla
estructura para la compresión y la descompresión de mensajes.
La solución también se ha mostrado eficaz,
puesto que permite la optimización del tráfico de la red, en la
transferencia, al ser los intervalos de tiempo iguales, de una mayor
cantidad de información o la misma cantidad de información en un
menor número de mensajes. También es una solución segura ya que, aun
estando comprimida y codificada, la información se desplaza por la
red en un texto claro.
Obviamente, aunque el principio de la invención
permanece inalterado, los detalles de la implementación de la
invención y sus realizaciones podrían variar considerablemente con
respecto a lo que se ha descrito e ilustrado en la presente memoria,
sin alejarse del espíritu y el alcance de la invención según se
define en las reivindicaciones adjuntas.
Claims (17)
1. Método para la transferencia por UDP de
mensajes que incorporan una carga útil, caracterizado porque
comprende las etapas de codificar (102) al menos dicha carga útil en
un formato hexadecimal y someter al menos dicha carga útil
codificada a una etapa (302, 104, 204) de compresión basada en el
reconocimiento de secuencias que aparecen periódicamente en los
mensajes.
2. Método según la reivindicación 1,
caracterizado porque dicha etapa de compresión se realiza
según una técnica de tipo gzip, tal como zLib.
3. Método según la reivindicación 1 ó 2,
caracterizado porque comprende la etapa de indicar la
compresión ejecutada en el mensaje transferido por UDP.
4. Método según la reivindicación 3,
caracterizado porque usa un campo de bits de la cabecera UDP
para indicar la etapa (302) de compresión ejecutada.
5. Método según la reivindicación 4,
caracterizado porque se usan los bits desde el bit 62 al bit
69 de la cabecera UDP para indicar la etapa (302) de compresión
ejecutada.
6. Método según la reivindicación 5,
caracterizado porque comprende la etapa de ajustar a 1 al
menos uno de los bits 62 a 69 de la cabecera del mensaje UDP.
7. Método según una de las reivindicaciones 1 a
6, aplicado a la transferencia de mensajes SNMP,
caracterizado porque comprende:
- leer (100) un mensaje SNMP completo,
- codificar (102) el mensaje leído en formato
hexadecimal, y
- someter el mensaje codificado en forma
hexadecimal a una compresión (104).
8. Método según una de las reivindicaciones 1 a
7, aplicado a la transferencia de mensajes SNMP,
caracterizado por una etapa de recepción que comprende las
operaciones de:
- someter el mensaje recibido a una etapa (204)
de descompresión complementaria a dicha etapa de compresión, de modo
que el mensaje sometido a la etapa de descompresión pueda obtenerse
en formato hexadecimal,
- decodificar (202) el mensaje sometido a la
etapa (204) de descompresión partiendo del formato hexadecimal,
y
- reconstruir (200) el mensaje SNMP completo a
partir del mensaje decodificado.
9. Método según la reivindicación 7 u 8,
caracterizado porque comprende una operación de encapsulación
en un mensaje SNMP estándar del mensaje sometido a dicha etapa (104)
de compresión.
10. Método según la reivindicación 9,
caracterizado porque comprende las operaciones de:
- leer (108) en bytes el mensaje sometido a
dicha etapa (104) de compresión y convertirlo (110) en un mensaje
correspondiente en caracteres ASCII,
- generar (112) un conjunto de enlaces
variables, que incluyen un primer OID que indica el tamaño del
archivo original y, a continuación, parejas OID/valor que llevan
partes de dicho mensaje sometido a dicha etapa (104) de compresión,
convertido en caracteres ASCII,
- reconstruir una información de cabecera del
mensaje SNMP,
- codificar (114) el mensaje SNMP así obtenido
en un formato hexadecimal para generar la carga útil UDP, y
- transferir (116) por UDP la carga útil
generada.
11. Método según la reivindicación 8 y 9 ó 10,
caracterizado porque la etapa de recepción comprende las
operaciones de:
- recibir (216) el mensaje sometido a dicha
etapa de compresión como una carga útil UDP,
- someter la carga útil así recibida a una
operación (214) de decodificación hexadecimal,
- reconocer y ensamblar (212) los enlaces
variables del mensaje sometido a la decodificación hexadecimal,
y
- someter el mensaje reconocido y ensamblado en
la operación (212) de reconocimiento y ensamblaje a una operación
(210) de decodificación de ASCII a binario,
- someter el mensaje decodificado en forma
binaria a dicha etapa (204) de descompresión.
12. Método según la reivindicación 7 ó 8,
caracterizado porque comprende la etapa de integrar el
mensaje sometido a dicha etapa (104) de compresión mediante
encapsulación por UDP.
13. Método según la reivindicación 12,
caracterizado porque comprende las etapas de:
- configurar dicho mensaje sometido a dicha
etapa (104) de compresión como carga útil de una unidad de datos de
protocolo (PDU), y
- transferir la carga útil creada de este modo
desde un puerto de transmisión dado de un transmisor a un puerto de
recepción dado de un receptor.
14. Método según la reivindicación 13,
caracterizado porque incluye las etapas de:
- recibir dicho mensaje como una carga útil de
una PDU-UDP recibida en el puerto de recepción
y,
- extraer dicha carga útil de dicha PDU.
15. Método según la reivindicación 13 ó 14,
caracterizado porque comprende la etapa de transmitir entre
un terminal (M, M'; A, A') de transmisión y un terminal (A, A'; M,
M') de recepción un mensaje de sincronización de tipo SNMP
identificando dicho puerto de transmisión y/o dicho puerto de
recepción.
16. Sistema de gestión de redes de comunicación
de datos que incluye al menos una unidad (M, M') de gestión y al
menos una unidad (A, A') agente, que se comunican entre sí a través
de la menos un canal (C1, C2) mediante la transmisión de mensajes,
caracterizado porque dichos mensajes se transfieren por UDP
según el método basado en cualquiera de las reivindicaciones 1 a
15.
17. Producto de procesamiento de datos, que
puede cargarse directamente en la memoria interna de un procesador
digital y que incluye partes de código software para realizar el
método según cualquiera de las reivindicaciones 1 a 15 cuando el
producto se ejecuta en un procesador digital.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ITTO01A0813 | 2001-08-13 | ||
| IT2001TO000813A ITTO20010813A1 (it) | 2001-08-13 | 2001-08-13 | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2263820T3 true ES2263820T3 (es) | 2006-12-16 |
Family
ID=11459150
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02775199T Expired - Lifetime ES2263820T3 (es) | 2001-08-13 | 2002-08-09 | Metodo y dispositivo para transferir mensajes snmp por udp con compresion de secuencias que se repiten periodicamente. |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US7734825B2 (es) |
| EP (1) | EP1417821B1 (es) |
| JP (1) | JP2005500606A (es) |
| KR (1) | KR100942243B1 (es) |
| CN (2) | CN101854252B (es) |
| AT (1) | ATE324737T1 (es) |
| CA (1) | CA2456912C (es) |
| DE (1) | DE60210986T2 (es) |
| ES (1) | ES2263820T3 (es) |
| IT (1) | ITTO20010813A1 (es) |
| WO (1) | WO2003017618A1 (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ITTO20010813A1 (it) * | 2001-08-13 | 2003-02-13 | Telecom Italia Lab Spa | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
| WO2004109930A1 (en) * | 2003-06-06 | 2004-12-16 | Nokia Corporation | Arrangement for application message decompression |
| US7716355B2 (en) * | 2005-04-18 | 2010-05-11 | Cisco Technology, Inc. | Method and apparatus for processing simple network management protocol (SNMP) requests for bulk information |
| EP1768308B1 (en) * | 2005-09-26 | 2008-04-02 | Alcatel Lucent | Data distribution to nodes of a telecommunication network |
| CN1949765B (zh) * | 2005-10-10 | 2010-10-13 | 华为技术有限公司 | 获得被管设备的ssh主机公开密钥的方法和系统 |
| GB2441371A (en) * | 2006-08-29 | 2008-03-05 | Motorola Inc | Transmitting packets across a network by compressing and encapsulating them |
| US7865610B2 (en) | 2007-03-12 | 2011-01-04 | Nautel Limited | Point to multipoint reliable protocol for synchronous streaming data in a lossy IP network |
| CN103023702A (zh) * | 2012-12-14 | 2013-04-03 | 武汉烽火网络有限责任公司 | 批量mib的处理方法 |
| US20180270100A1 (en) * | 2014-12-19 | 2018-09-20 | Thomson Licensing | Method and apparatus for data transfer between network devices |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5790599A (en) * | 1989-01-19 | 1998-08-04 | Redband Technologies, Inc. | Data compression system using source representation |
| US6144859A (en) * | 1993-08-27 | 2000-11-07 | Aeris Communications, Inc. | Wireless cellular communicator system and apparatus |
| US6026232A (en) * | 1995-07-13 | 2000-02-15 | Kabushiki Kaisha Toshiba | Method and system to replace sections of an encoded video bitstream |
| US5649189A (en) * | 1995-11-29 | 1997-07-15 | 3Com Corporation | Method and apparatus for single pass data encoding of binary words using a stack for writing in reverse order |
| US6073180A (en) * | 1996-03-07 | 2000-06-06 | Nippon Telegraph And Telephone Corporation | High-speed batch file transfer method and apparatus, and storage medium in which a program for executing the transfer is stored |
| JPH09331332A (ja) * | 1996-06-10 | 1997-12-22 | Fujitsu Ltd | コネクション識別子のネゴシエーション方法 |
| US6108782A (en) * | 1996-12-13 | 2000-08-22 | 3Com Corporation | Distributed remote monitoring (dRMON) for networks |
| US6441920B1 (en) * | 1997-06-04 | 2002-08-27 | Agfa Corporation | System and method for output management |
| US6044468A (en) * | 1997-08-25 | 2000-03-28 | Emc Corporation | Secure transmission using an ordinarily insecure network communication protocol such as SNMP |
| US6189045B1 (en) * | 1998-03-26 | 2001-02-13 | International Business Machines Corp. | Data type conversion for enhancement of network communication systems |
| US6519635B1 (en) * | 1998-04-30 | 2003-02-11 | Cisco Technology, Inc. | SNMP master agent that translates messages to a sub-agent proprietary format using a translation table by the sub-agent |
| IT1302431B1 (it) * | 1998-08-12 | 2000-09-05 | Alasi Di Arcieri Franco & C S | Dispositivo di controllo di accessi in rete tramite il riconoscimentoveloce di trame applicative che soddisfano un insieme di regole |
| WO2000057284A1 (en) * | 1999-03-25 | 2000-09-28 | Motorola Inc. | Point to point protocol multiplexing/demultiplexing method and apparatus |
| CA2280662A1 (en) * | 1999-05-21 | 2000-11-21 | Joe Toth | Media server with multi-dimensional scalable data compression |
| US6542504B1 (en) * | 1999-05-28 | 2003-04-01 | 3Com Corporation | Profile based method for packet header compression in a point to point link |
| US6427149B1 (en) * | 1999-09-09 | 2002-07-30 | Herman Rodriguez | Remote access of archived compressed data files |
| US7600039B2 (en) * | 2000-02-16 | 2009-10-06 | Motorola, Inc. | Label-based multiplexing |
| AU2001259075A1 (en) * | 2000-04-17 | 2001-10-30 | Circadence Corporation | System and method for web serving |
| US7197046B1 (en) * | 2000-08-07 | 2007-03-27 | Shrikumar Hariharasubrahmanian | Systems and methods for combined protocol processing protocols |
| US6618397B1 (en) * | 2000-10-05 | 2003-09-09 | Provisionpoint Communications, Llc. | Group packet encapsulation and compression system and method |
| US6883035B2 (en) * | 2000-11-16 | 2005-04-19 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for communicating with temporary compression tables |
| JP3565266B2 (ja) * | 2000-12-28 | 2004-09-15 | 日本電気株式会社 | ネットワークの管理方法およびそのシステム |
| US6459392B1 (en) * | 2001-01-19 | 2002-10-01 | International Business Machines Corporation | Technique for encoding a sequence of periodic byte values with vertical correlation |
| ITTO20010813A1 (it) * | 2001-08-13 | 2003-02-13 | Telecom Italia Lab Spa | Procedimento per il trasferimento di messaggi tramite udp, relativo sistema e prodotto informatico. |
| KR100431003B1 (ko) * | 2001-10-31 | 2004-05-12 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| US7221684B1 (en) * | 2002-01-08 | 2007-05-22 | Cisco Technology, Inc. | Increasing network efficiency using packet compression and decompression |
| US6711740B1 (en) * | 2002-01-17 | 2004-03-23 | Cisco Technology, Inc. | Generic code book compression for XML based application programming interfaces |
| US7519729B2 (en) * | 2002-02-27 | 2009-04-14 | Ricoh Co. Ltd. | Method and apparatus for monitoring remote devices through a local monitoring station and communicating with a central station supporting multiple manufacturers |
| ITTO20020325A1 (it) * | 2002-04-12 | 2003-10-13 | Telecom Italia Lab Spa | ,,procedimento per organizzare la comunicazione fra oggetti gestori ed oggetti gestiti in una rete telematica.relativa architettura e prodot |
| US7362780B2 (en) * | 2002-12-11 | 2008-04-22 | Nokia Corporation | Avoiding compression of encrypted payload |
-
2001
- 2001-08-13 IT IT2001TO000813A patent/ITTO20010813A1/it unknown
-
2002
- 2002-08-09 CA CA2456912A patent/CA2456912C/en not_active Expired - Fee Related
- 2002-08-09 CN CN2010101343871A patent/CN101854252B/zh not_active Expired - Fee Related
- 2002-08-09 AT AT02775199T patent/ATE324737T1/de not_active IP Right Cessation
- 2002-08-09 KR KR1020047002221A patent/KR100942243B1/ko active IP Right Grant
- 2002-08-09 ES ES02775199T patent/ES2263820T3/es not_active Expired - Lifetime
- 2002-08-09 DE DE60210986T patent/DE60210986T2/de not_active Expired - Lifetime
- 2002-08-09 WO PCT/IT2002/000533 patent/WO2003017618A1/en active IP Right Grant
- 2002-08-09 CN CN028158814A patent/CN1541475B/zh not_active Expired - Fee Related
- 2002-08-09 US US10/486,738 patent/US7734825B2/en not_active Expired - Fee Related
- 2002-08-09 EP EP02775199A patent/EP1417821B1/en not_active Expired - Lifetime
- 2002-08-09 JP JP2003521584A patent/JP2005500606A/ja active Pending
-
2010
- 2010-06-01 US US12/791,350 patent/US20100306414A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20050038912A1 (en) | 2005-02-17 |
| JP2005500606A (ja) | 2005-01-06 |
| CN1541475A (zh) | 2004-10-27 |
| ITTO20010813A0 (it) | 2001-08-13 |
| ITTO20010813A1 (it) | 2003-02-13 |
| DE60210986T2 (de) | 2007-01-11 |
| EP1417821B1 (en) | 2006-04-26 |
| CN101854252A (zh) | 2010-10-06 |
| CA2456912C (en) | 2013-12-24 |
| EP1417821A1 (en) | 2004-05-12 |
| CN101854252B (zh) | 2012-07-11 |
| DE60210986D1 (de) | 2006-06-01 |
| CN1541475B (zh) | 2011-10-26 |
| US7734825B2 (en) | 2010-06-08 |
| KR100942243B1 (ko) | 2010-02-16 |
| WO2003017618A1 (en) | 2003-02-27 |
| ATE324737T1 (de) | 2006-05-15 |
| CA2456912A1 (en) | 2003-02-27 |
| US20100306414A1 (en) | 2010-12-02 |
| KR20040030967A (ko) | 2004-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20100306414A1 (en) | Transferring of SNMP Messages Over UDP with Compression of Periodically Repeating Sequences | |
| JP3906204B2 (ja) | コンピューティング装置、コンピューティング装置とリモート・コンピュータ・システムとの間でデータを通信する方法 | |
| US7599283B1 (en) | Network traffic synchronization and data compression in redundant network topologies | |
| JP3760767B2 (ja) | ネットワーク管理装置及びネットワーク管理方法 | |
| JP4874550B2 (ja) | 有線又は無線ネットワークにおけるパケットのルーティングのためのシステム及び方法 | |
| US7154416B1 (en) | Adaptive control of codebook regeneration in data compression mechanisms | |
| US7602728B2 (en) | Method and apparatus for determination of network topology | |
| WO2018099046A1 (zh) | 报文转发方法和装置 | |
| EP4181463A1 (en) | Method and device for processing message | |
| ES2495141T3 (es) | Procedimiento y dispositivo para compresión y descompresión de paquetes con protocolo Datagram de usuario | |
| US20110173209A1 (en) | Method for lossless data reduction of redundant patterns | |
| Choi et al. | 6lowpan-snmp: Simple network management protocol for 6lowpan | |
| KR100767394B1 (ko) | 인터넷 프로토콜 버전6 기반의 저전력 무선 개인 영역네트워크에서 외부 인터넷 프로토콜 버전6 기반 네트워크와연동하기 위한 게이트웨이 및 이를 이용한 상호 연동 방법 | |
| Gündoğan et al. | Designing a LoWPAN convergence layer for the Information Centric Internet of Things | |
| CN106470212B (zh) | 一种基于lzw压缩算法对eigrp协议报文进行压缩和加密的方法 | |
| Aloufi | 6lowpan stack model configuration for iot streaming data transmission over coap | |
| JP3565266B2 (ja) | ネットワークの管理方法およびそのシステム | |
| JP2018006964A (ja) | データ圧縮方法、ゲートウェイ、及びデータ送信システム | |
| US20050180387A1 (en) | Method for organising communication between manager objects and managed objects in a communication network, architecture and software thereof | |
| US6785731B1 (en) | Methods for efficient transmission of signaling messages in a packet-based network | |
| CN106572080B (zh) | 一种基于lzw压缩算法对snmp报文进行压缩和加密的方法 | |
| Guitton et al. | Fault-tolerant compression algorithms for delay-sensitive sensor networks with unreliable links | |
| CN112769705A (zh) | 一种适用于小型局域网的VoIP报头压缩方法 | |
| Hübner | Communication and Networked Systems | |
| Cho et al. | Modeling and analysis of robust header compression performance |