¿Qué significa la frase Internet de las cosas?

Depende mucho de su ubicación en la cadena

de suministro. Muchas personas han tratado de
definirla y las definiciones, a menudo, están
matizadas por las necesidades de sus propios
sectores y sus propias agendas. Pero como
ingeniero de hardware o software, usted ya
comprende el elemento esencial: crear
productos que estén interconectados. Los
sistemas integrados tendrán (y tienen) un papel
fundamental en el desarrollo de la IoT. En este
artículo, examinaremos Internet y sus protocolos
existentes y nuevos que apoyan las iniciativas
de IoT. Antes de analizar estos protocolos,
definamos qué son, porque las tareas del
dispositivo final dictarán la mayoría de los
requisitos para los protocolos que se deben
usar.
IoT industrial y para consumidores

Los requisitos de software para los dispositivos de IoT industrial y para

consumidores pueden ser bastante distintos. Aunque podrían compartir un
kernel común y servicios de bajo nivel, el middleware requerido por sus
aplicaciones puede ser fundamentalmente diferente.

La IoT industrial, a saber, un nodo WSN representa una pila de software

para un dispositivo de IoT industrial, como un nodo de sensor inalámbrico
(WSN). Este dispositivo de baja potencia y de bajo costo puede funcionar
completamente con una batería. Este tipo de dispositivo podría usar
normalmente un
procesador de 32 bits. También podría usar un procesador de 8 o 16 bits,
pero si la pila de comunicaciones se ejecuta en módulos complementarios.
Usaría un protocolo de red muy eficiente, como 6LoWPAN, para reducir el
tiempo de transmisión y ahorrar energía. También podría comunicarse de
 forma inalámbrica en distancias cortas mediante Bluetooth. Al ser un nodo
periférico, debemos transferir los datos desde una red inalámbrica a una red
basada en IP (Internet local o pública) y usaría Wi-Fi o Ethernet de baja
potencia.
Está claro, que los requisitos de software de este dispositivo son mucho
mayores. Podría necesitar una Java VM. También podría utilizar un
protocolo de mercado vertical. Lamentablemente, la IoT para consumidores
está muy fragmentada en términos de protocolo de mercado vertical
(protocolo de aplicación). Muchas compañías están proponiendo soluciones
patentadas. Por ejemplo, en el mercado del consumidor de bienes para el
hogar:
  Apple tiene MFI (Made For Idevices)
  Google (Nest) anunció Thread
  Samsung, Intel, Dell, Atmel y Broadcom se unieron para lanzar Open
Interconnect Consortium (OIC)
  The AllSeen Alliance (anteriormente AllJoyn) ha estado proponiendo un
estándar durante muchos años. Los principales miembros son Haier, LG,
Microsoft, Panasonic, Qualcomm, Sharp, Silicon Image, Technicolor y TP-
Link.
Hay otros ejemplos, como la comunicación por línea de alimentación:
HomePlug y HomeGrid.

En el mercado vertical médico, organizaciones como Continua Alliance,

IHE (Integrating the HealthCare Enterprise) o IEEE también están
desarrollando y proponiendo estándares.

Micrium no ofrece estos protocolos. Un fabricante de equipos que necesite

que sus productos sean compatibles con uno de estos protocolos de IoT
para consumidores debe registrarse con estas organizaciones y, luego,
integrar estos protocolos como parte de la aplicación de su producto.

En la IoT industrial, esta iniciativa impulsada por el mercado no está tan

presente. Existe una actividad principal denominada Industrial Internet
Consortium (IIC), cuyos miembros fundadores son AT&T, Cisco, GE, Intel
e IBM. Sin embargo, aparte del IIC, el desarrollo de dispositivos y sistemas
de IoT es más bien privado. Esta es la razón por la cual el conocimiento de
Internet y de los Protocolos de Internet (IP) es tan importante actualmente
para los desarrolladores de sistemas integrados.

Protocolo de Internet (IP)

El uso de la tecnología de IP es fundamental para la IoT. El IP permite la
interoperabilidad de los sistemas. Es posible que esta característica no
parezca importante hoy, pero a medida que la IoT evolucione, la
interoperabilidad de los sistemas se convertirá en una competencia
importante para generar ingresos. Ethernet/Wi-Fi y 6LoWPAN dependen
en gran medida de IPv4 e IPv6.

Protocolos IP utilizados en la IoT

Definitivamente, es posible crear un sistema de IoT con las tecnologías
Web existentes, aunque no sean tan eficaces como los protocolos más
nuevos. HTTP(S) y Websockets son estándares comunes, junto con XML o
JavaScript Object Notation (JSON) para la carga útil. Cuando se utiliza un
explorador Web estándar (cliente HTTP), JSON proporciona una capa de
abstracción para que los desarrolladores Web creen una aplicación para
Web con estado con una conexión de dúplex constante a un servidor Web
(servidor HTTP) mediante la mantención de dos conexiones HTTP
abiertas.

HTTP
HTTP es la base del modelo cliente-servidor usado para la Web. El método
más seguro de implementar el HTTP en su dispositivo de IoT es incluir
solo un cliente, no un servidor. En otras palabras, es más seguro si el
dispositivo de IoT puede iniciar conexiones a un servidor Web, pero no es
capaz de recibir solicitudes de conexión. Después de todo, no queremos
permitir que máquinas externas tengan acceso a la red local donde se
encuentran instalados los dispositivos de IoT.

WebSocket
WebSocket es un protocolo que proporciona comunicación dúplex
completa a través de una conexión TCP única por la cual se pueden enviar
mensajes entre el cliente y el servidor. Forma parte de la especificación
HTML 5. El estándar WebSocket simplifica gran parte de la complejidad
que circunda la comunicación Web bidireccional y la administración de la
conexión. Usar Websockets junto con HTTP es una solución apropiada
para los dispositivos de IoT si los dispositivos pueden soportar las cargas
de HTTP.

XMPP
XMPP (Protocolo extensible de mensajería y presencia) es un excelente
ejemplo de una tecnología Web existente que encuentra un uso nuevo en el
espacio de IoT.

El XMPP tiene sus raíces en la mensajería instantánea y la información de

presencia, y se ha ampliado a llamadas de voz y video, colaboración,
middleware ligero, redifusión de contenido y enrutamiento generalizado de
datos XML. Es un aspirante a administración a escala masiva de
electrodomésticos de consumo, como lavadoras, secadoras, refrigeradores,
etc.

Las ventajas del XMPP son su direccionamiento, seguridad y escalabilidad.

Esto lo hace ideal para aplicaciones de IoT orientada a los consumidores.

HTTP, Websocket y XMPP son solo ejemplos de tecnologías que se han

tenido que poner a trabajar para la IoT. Otros grupos también están
trabajando intensamente a fin de desarrollar soluciones para los nuevos
desafíos que la IoT nos presenta.

Protocolos dedicados de IoT

Muchos expertos de IoT se refieren a los dispositivos de IoT como sistemas
limitados, porque creen que estos dispositivos deberían ser lo más baratos
posibles y usar los MCU más pequeños disponibles, a la vez, que ejecutan
una pila de comunicación.
Actualmente, adaptar Internet para la IoT es una de las prioridades
principales de muchas organizaciones de estandarización global.
Si su sistema no requiere las características de TCP y puede funcionar con
las capacidades de UDP más limitadas, quitar por completo el módulo de
TCP ayuda enormemente a reducir el tamaño de la huella de código total de
su producto. Esto es lo que 6LoWPAN (para WSN) y CoAP (protocolo de
Internet ligero) aportan al universo de la IoT.

CoAP
Aunque la infraestructura Web se encuentra disponible para dispositivos de
IoT y estos la pueden usar, es demasiado pesada para la mayoría de las
aplicaciones de IoT. En julio de 2013, IETF lanzó el Protocolo de
aplicación restringida (CoAP) para usarlo con nodos y redes de baja
potencia y con pérdida (restringidos) (LLN). El CoAP, como HTTP, es un
protocolo RESTful.

El CoAP está semánticamente alineado con HTTP e, incluso, tiene

asignaciones uno a uno hacia y desde HTTP. Los dispositivos de red están
restringidos por microcontroladores más pequeños, con pequeñas
 cantidades de memoria flash y RAM, mientras que las restricciones en las
redes locales, como 6LoWPAN, se deben a altas tasas de error de paquete y
a un bajo rendimiento (decenas de kilobits por segundo). El CoAP puede
ser un protocolo apropiado para dispositivos que operan con batería o
mediante extracción de energía.

Características del CoAP: el CoAP usa UDP

 Debido a que el CoAP usa UDP, algunas de las funciones de TCP se

reproducen directamente en el CoAP. Por ejemplo, el CoAP distingue entre
mensajes que se pueden confirmar (que requieren una confirmación) y que
no se pueden confirmar.
  Las solicitudes y las respuestas se intercambian de forma asincrónica en
los mensajes de CoAP (a diferencia del HTTP, donde se utiliza una
conexión TCP existente).
  Todos los encabezados, métodos y códigos de estado se codifican de
forma binaria, lo que reduce la sobrecarga del protocolo. Sin embargo, esto
requiere el uso de un analizador de protocolo para solucionar problemas de
red.
  A diferencia del HTTP, la capacidad de copiar en caché las respuestas de
CoAP no depende del método de solicitud, sino del Código de respuesta.

El CoAP aborda completamente las necesidades de un protocolo

extremadamente ligero y con la naturaleza de una conexión permanente.
Tiene conocimiento semántico de HTTP y es RESTful (recursos,
identificadores de recursos y manipula esos recursos a través de una
Interfaz de programación de aplicaciones [API] uniforme). Si tiene un
entorno Web, usar CoAP será relativamente fácil.

MQTT
El Transporte de telemetría de cola de mensajes (MQTT) es un protocolo
de código abierto que se desarrolló y optimizó para dispositivos
restringidos y redes de bajo ancho de banda, alta latencia o poco confiables.
Es un transporte de mensajería de publicación/suscripción que es
extremadamente ligero e ideal para conectar dispositivos pequeños a redes
con ancho de banda mínimo. El MQTT es eficiente en términos de ancho
de banda, independiente de los datos y tiene reconocimiento de sesión
continua, porque usa TCP. Tiene la finalidad de minimizar los
requerimientos de recursos del dispositivo y, a la vez, tratar de asegurar la
confiabilidad y cierto grado de seguridad de entrega con calidad del
servicio.
 El MQTT se orienta a grandes redes de dispositivos pequeños que
necesitan la supervisión o el control de un servidor de back-end en Internet.
No está diseñado para la transferencia de dispositivo a dispositivo.
Tampoco está diseñado para realizar "multidifusión" de datos a muchos
receptores. El MQTT es simple y ofrece pocas opciones de control. Las
aplicaciones que usan MQTT, por lo general, son lentas en el sentido de
que la definición de "tiempo real" en este caso se mide habitualmente en
segundos.

Comparación de los protocolos de IoT potenciales

Cisco ocupa un lugar central en la Internet; su equipo de IP está en todas
partes. En la actualidad, Cisco participa activamente en la evolución de la
IoT. Ve el potencial de conectar los objetos físicos y obtener datos de
nuestro entorno y procesarlos para mejorar nuestros niveles de vida.


 Estos protocolos de IoT específicos de Internet se desarrollaron para satisfacer los
requisitos de los dispositivos con pequeñas cantidades de memoria y las redes con bajo
ancho de banda y alta latencia.

 El HTTP puede ser un protocolo pesado para un dispositivo de IoT. Tiene
mensajes extensos porque se envían en formato legible para el ser humano.
En el caso de los dispositivos de IoT, el tamaño de la carga es, a menudo,
una limitación. Para una gran familia de dispositivos, informar y aceptar
comandos puede realizarse de forma más eficaz con un protocolo mucho
más liviano. Se ha propuesto al MQTT como la respuesta a estos
problemas. El MQTT no es un estándar IETF y es generado por IBM y la
fundación Eclipse.

Conclusión
En el término "Internet de las cosas", aparece la palabra Internet. Algunas
compañías pueden ofrecer dispositivos clasificados como dispositivos de
IoT que no utilizan el Protocolo de Internet. Deberíamos esperar esto. Hoy,
la IoT es un término tan sólido (algunos podrían decir que exagerado) que
todos los fabricantes quieren aprovechar la enorme cobertura mediática de
la IoT.

El Protocolo de Internet (IP) es un portador; puede encapsular tantos

protocolos para la IoT como lo hace hoy para la Web. Muchos especialistas
de la industria exigen una estandarización de protocolos. Sin embargo, si
existe una cantidad tan grande de protocolos para la Web, ¿por qué no
habría la misma cantidad para la IoT? Usted elige los protocolos que
satisfacen sus requisitos. La única diferencia es que los protocolos de IoT
aún son muy nuevos y deben demostrar su confiabilidad. Recuerde que,
cuando Internet se transformó en realidad, la versión 4 del IP fue lo que lo
hizo posible. Ahora, estamos implementando masivamente la versión 6 del
IP, y la IoT es la aplicación de excelente rendimiento que los portadores de
telecomunicaciones han estado esperando para justificar la inversión
requerida.

El posicionamiento de cada uno de los protocolos de IoT requiere un

cuestionamiento similar. Salvo el protocolo HTTP, todos estos protocolos
están posicionados como protocolos de IoT de publicación-suscripción en
tiempo real, compatibles con millones de dispositivos. Según cómo defina
"tiempo real" (segundos, milisegundos o microsegundos) y "cosas" (nodo
WSN, dispositivo multimedia, dispositivo usable personal, escáner médico,
control de motor, etc.), la selección del protocolo para su producto es
fundamental. En esencia, estos protocolos son todos muy diferentes.

Sin embargo, el diseño de los sistemas de datos de IoT se encuentra más

allá del diseño de hardware y de software. Necesitamos separar los datos de
la aplicación, de manera que podamos hacer cosas nuevas con ellos, cosas
que aún no imaginamos. Para el desarrollador de sistemas integrados
normal, pensar específicamente en los datos que genera el sistema requiere
una nueva mentalidad. Estos datos son valiosos. En el diseño de sistemas
integrados, comprendemos muy bien cómo diseñar las "Cosas", la red local
e, incluso, la puerta de enlace. El procesador, el sensor, la conectividad
inalámbrica, la puerta de enlace, la red IP y la seguridad son todos
elementos que el desarrollador integrado conoce bien.

El nuevo desafío para la comunidad integrada es utilizar algún tipo de

sistema de computación en nube para aprovechar el valor inherente de
nuestros datos. Para monetizar los datos del sistema integrado, se requiere
realmente algún tipo de sistema de computación en nube, ya sea privado,
subcontratado o público. Este es un nuevo paradigma para la comunidad
integrada.

La tecnología de hardware, la tecnología de software, la infraestructura y la

computación en nube de los sistemas integrados se están probando e
implementando activamente, promoviendo la emergente Internet de las
cosas. Para tener un éxito real y alcanzar los 50 mil millones de
dispositivos que se implementarán para el año 2020, necesitamos los
mismos estándares abiertos, desarrollo y cooperación que apoyaron la
creación de la Internet de las personas (también conocida como la Web).
IPSO Alliance está promocionando los estándares de IP y los utiliza para
crear las arquitecturas de referencia que buscan los desarrolladores de
productos.

La IoT para los sistemas integrados es la nueva revolución industrial. El

potencial de crecimiento de la industria integrada es enorme. Para alcanzar
este potencial, la industria integrada necesita adoptar el nuevo paradigma
de IoT. Ahora comprendemos lo que se debe hacer. Es posible que aún no
tengamos estándares bien definidos y establecidos para cada elemento
estructural de los sistemas de IoT futuros, como la facilidad de
configuración o la actualización remota y segura de firmware. No obstante,
esto no debería impedirnos crear un sistema que ofrecerá valor a los
clientes.

Para mi primera entrada, voy a hablaros sobre MQTT (Message Queue Telemetry
Transport), un protocolo usado para la comunicación machine-to-machine (M2M) en
el "Internet of Things". Este protocolo está orientado a la comunicación de sensores,
debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de
los dispositivos empotrados con pocos recursos (CPU, RAM, …). Un ejemplo de uso de
este protocolo es la aplicación de Facebook Messenger tanto para android y Iphone. La
arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de
servidor o "broker" con una capacidad de hasta 10000 clientes. El broker es el
encargado de gestionar la red y de transmitir los mensajes, para mantener activo el
canal, los clientes mandan periódicamente un paquete (PINGREQ) y esperan la
respuesta del broker (PINGRESP). La comunicación puede ser cifrada entre otras

muchas opciones. La
comunicación se basa en unos "topics" (temas), que el cliente que publica el mensaje
crea y los nodos que deseen recibirlo deben subscribirse a él. La comunicación puede
ser de uno a uno, o de uno a muchos. Un "topic" se representa mediante una cadena y
tiene una estructura jerárquica. Cada jerarquía se separa con '/'. Por
ejemplo, "edificio1/planta5/sala1/raspberry2/temperatura" o "/edificio3/planta0/sa
la3/arduino4/ruido". De esta forma se pueden crear jerarquías de clientes que publican
y reciben datos, como podemos ver en la imagen:

De esta forma un nodo

puede subscribirse a un "topic" concreto
("edificio1/planta2/sala0/arduino0/temperatura") o a varios ("edificio1/planta2/#") .
Próximamente intentaré subir un tutorial como ejemplo de su uso. Web MQTT -
mqtt.org

inter net of thi ngs mqtt

Simple Network Management Protocol

Simple Network Management Protocol (SNMP)

Familia Familia de protocolos de Internet

Función facilita el intercambio de información de

administración entre dispositivos de red

Última SNMPv3
versión

Puertos 161/UDP, 162/UDP (Trap)

Ubicación en la pila de protocolos

Aplicación SNMP

Transporte UDP y TCP

 Red IP (IPv4 y IPv6)

Estándares

RFC 1157 (SNMP, 1990)

RFC 3410 (SNMPv3, 2002)

[editar datos en Wikidata]

El Protocolo Simple de Administración de Red o SNMP (del inglés Simple Network

Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio
de información de administración entre dispositivos de red. Los dispositivos que
normalmente soportan SNMP incluyen routers, switches, servidores, estaciones de trabajo,
impresoras, bastidores de módem y muchos más. Permite a los administradores
supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su
crecimiento.
SNMP es un componente de la suite de protocolo de Internet como se define por el IETF.
Se compone de un conjunto de normas para la gestión de la red, incluyendo una capa de
aplicación del protocolo, una base de datos de esquema, y un conjunto de objetos de
datos. Las versiones de SNMP más utilizadas son SNMP versión 1 (SNMPv1) y SNMP
versión 2 (SNMPv2).
SNMP en su última versión (SNMPv3) posee cambios significativos con relación a sus
predecesores, sobre todo en aspectos de seguridad;[cita requerida] sin embargo no ha sido
mayoritariamente aceptado en la industria.

Índice
[ocultar]

 1Conceptos Básicos
 2Componentes básicos
 3Comandos básicos
 4Base de información de administración SNMP (MIB)
 5Detalles del Protocolo
 6Mensajes SNMP
o 6.1GetRequest
o 6.2GetNextRequest
o 6.3SetRequest
o 6.4GetResponse
o 6.5Trap
o 6.6GetBulkRequest
o 6.7InformRequest
 7Desarrollo y Uso
o 7.1Versión 1
o 7.2Versión 2
 7.2.1SNMPv1 y SNMPv2c interoperabilidad
 7.2.2Agentes de proxy
 7.2.3Sistema de gestión de la red bilingüe
o 7.3Versión 3
 8Dificultades de implementación
 9Indexación de Recursos
 10Implicaciones de Seguridad
 11Descubrimiento Automático
 12Véase también
o 12.1Otros protocolos
 13Referencias
 14Enlaces externos
o 14.1RFCs

Conceptos Básicos[editar]
En usos típicos SNMP, uno o más equipos administrativos, llamados gerentes, tienen la
tarea de supervisión o la gestión de un grupo de hosts o dispositivos de una red
informática. En cada sistema gestionado se ejecuta, en todo momento, un componente de
software llamado agente que reporta la información a través de SNMP con el gerente. Los
agentes SNMP exponen los datos de gestión en los sistemas administrados como
variables. El protocolo también permite realizar tareas de gestión de activos, tales como la
modificación y la aplicación de una nueva configuración a través de la modificación remota
de estas variables. Las variables accesibles a través de SNMP están organizadas en
jerarquías. Estas jerarquías y otros metadatos (tales como el tipo y la descripción de la
variable), se describen por Bases de Información de Gestión (MIB).[cita requerida]

Componentes básicos[editar]
Una red administrada a través de SNMP consta de tres componentes clave:

 Sistemas administradores de red (Network Management Systems, NMS);

 Dispositivos administrados;
 Agentes.
Estos componentes tienen las siguientes funciones:[cita requerida]
Un sistema administrador de red (NMS) ejecuta aplicaciones que supervisan y controlan
a los dispositivos administrados. Los NMS’s proporcionan el volumen de recursos de
procesamiento y memoria requeridos para la administración de la red. Uno o más NMS’s
deben existir en cualquier red administrada.
Un dispositivo administrado es un dispositivo que contiene un agente SNMP y reside en
una red administrada. Estos recogen y almacenan información de administración, la cual
es puesta a disposición de los NMS’s usando SNMP. Los dispositivos administrados, a
veces llamados elementos de red, pueden ser routers, servidores de acceso, switches,
bridges, hubs, computadores o impresoras.
Un agente es un módulo de software de administración de red que reside en un dispositivo
administrado. Un agente posee un conocimiento local de información de administración
(memoria libre, número de paquetes IP recibidos, rutas, etcétera), la cual es traducida a un
formato compatible con SNMP y organizada en jerarquías.

Comandos básicos[editar]
Los dispositivos administrados son supervisados y controlados usando cuatro comandos
SNMP básicos: lectura, escritura, notificación y operaciones transversales.[cita requerida]
El comando de lectura es usado por un NMS para supervisar elementos de red. El NMS
examina diferentes variables que son mantenidas por los dispositivos administrados.
El comando de escritura es usado por un NMS para controlar elementos de red. El NMS
cambia los valores de las variables almacenadas dentro de los dispositivos administrados.
El comando de notificación es usado por los dispositivos administrados para reportar
eventos en forma asíncrona a un NMS. Cuando cierto tipo de evento ocurre, un dispositivo
administrado envía una notificación al NMS.
Las operaciones transversales son usadas por el NMS para determinar qué variables
soporta un dispositivo administrado y para recoger secuencialmente información en tablas
de variables, como por ejemplo, una tabla de rutas.

Base de información de administración SNMP (MIB)[editar]

Una Base de Información de Administración (Management Information Base, MIB) es una
colección de información que está organizada jerárquicamente. Las MIB’s son accedidas
usando un protocolo de administración de red, como por ejemplo, SNMP.
Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de
cualquier número de características específicas de un dispositivo administrado. Los
objetos administrados están compuestos de una o más instancias de objeto, que son
esencialmente variables.
Existen dos tipos de objetos administrados: Escalares y tabulares. Los objetos escalares
definen una simple instancia de objeto. Los objetos tabulares definen múltiples instancias
de objeto relacionadas que están agrupadas conjuntamente en tablas MIB.
Un ejemplo de un objeto administrado es atInput, que es un objeto escalar que contiene
una simple instancia de objeto, el valor entero que indica el número total de
paquetes AppleTalk de entrada sobre una interfaz de un router.
Un identificador de objeto (object ID) identifica únicamente a un objeto administrado en la
jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz
anónima y los niveles, que son asignados por diferentes organizaciones.

El árbol MIB ilustra las variadas jerarquías asignadas por las diferentes organizaciones
Los identificadores de los objetos ubicados en la parte superior del árbol pertenecen a
diferentes organizaciones estándares, mientras los identificadores de los objetos ubicados
en la parte inferior del árbol son colocados por las organizaciones asociadas.
Los fabricantes pueden definir ramas privadas que incluyen los objetos administrados para
sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están
localizadas en la rama experimental.
El objeto administrado atInput podría ser identificado por el nombre de objeto iso.identified-
organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput o por el
descriptor de objeto equivalente 1.3.6.1.4.1.9.3.3.1.
El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos, los cuales
en su conjunto son llamados mib-2. Los grupos son los siguientes:

 System (1);
 Interfaces (2);
 AT (3);
 IP (4);
 ICMP (5);
 TCP (6);
 UDP (7);
 EGP (8);
 Transmission (10);
 SNMP (11).
Es importante destacar que la estructura de una MIB se describe mediante el
estándar Notación Sintáctica Abstracta 1 (Abstract Syntax Notation One).

Detalles del Protocolo[editar]

SNMP opera en la capa de aplicación del conjunto de protocolos de Internet (capa 7
del modelo OSI). El agente SNMP recibe solicitudes en el puerto UDP 161. El
administrador puede enviar solicitudes de cualquier puerto de origen disponible para el
puerto 161 en el agente. La respuesta del agente será enviado de vuelta al puerto de
origen en el gestor. El administrador recibe notificaciones (Trampas e InformRequests) en
el puerto 162. El agente puede generar notificaciones desde cualquier puerto disponible.
Cuando se utiliza con Transport Layer Security las solicitudes se reciben en el puerto
10161 y trampas se envían al puerto 10162. SNMPv1 especifica cinco unidades de datos
de protocolo (PDU) centrales. Otros dos PDU, GetBulkRequest e InformRequest se
añadieron en SNMPv2 y prorrogados a SNMPv3.[cita requerida]
Todas las PDU SNMP se construyen de la siguiente manera:

 Cabecera IP
 Encabezado UDP versión comunidad
 Tipo de PDU
 Petición-ID
 Error de estado
 Índice de errores
 Enlaces de variables

Mensajes SNMP[editar]
Para realizar las operaciones básicas de administración anteriormente nombradas, el
protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un
pequeño grupo de mensajes (PDUs) entre los administradores y agentes. La utilización de
un mecanismo de este tipo asegura que las tareas de administración de red no afectarán
al rendimiento global de la misma, ya que se evita la utilización de mecanismos de control
y recuperación como los de un servicio orientado a la conexión, por ejemplo TCP.
Los puertos comúnmente utilizados para SNMP son los siguientes:
 Número Descripción

161 SNMP

162 SNMP-trap

Los paquetes utilizados para enviar consultas y respuestas SNMP poseen el siguiente
formato:

Versión Comunidad SNMP PDU

 Versión: Número de versión de protocolo que se está utilizando (por ejemplo 0 para
SNMPv1, 1 para SNMPv2c, 2 para SNMPv2p y SNMPv2u, 3 para SNMPv3, ...);
 Comunidad: Nombre o palabra clave que se usa para la autenticación. Generalmente
existe una comunidad de lectura llamada "public" y una comunidad de escritura
llamada "private";
 SNMP PDU: Contenido de la Unidad de Datos de Protocolo, el que depende de la
operación que se ejecute.
Los mensajes GetRequest, GetNextRequest, SetRequest y GetResponse utilizan la
siguiente estructura en el campo SNMP PDU:

Tipo Identificador Estado de error Índice de error Enlazado de variables

 Identificador: Es un número utilizado por el NMS y el agente para enviar solicitudes y

respuesta diferentes en forma simultánea;
 Estado e índice de error: Sólo se usan en los mensajes GetResponse´(en las
consultas siempre se utiliza cero). El campo "índice de error" sólo se usa cuando
"estado de error" es distinto de 0 y posee el objetivo de proporcionar información
adicional sobre la causa del problema. El campo "estado de error" puede tener los
siguientes valores:
 0: No hay error;
 1: Demasiado grande;
 2: No existe esa variable;
 3: Valor incorrecto;
 4: El valor es de solo lectura;
 5: Error genérico.
 Enlazado de variables: Es una serie de nombres de variables con sus valores
correspondientes (codificados en ASN.1).
GetRequest[editar]
A través de este mensaje el NMS solicita al agente retornar el valor de un objeto de interés
mediante su nombre. En respuesta el agente envía una respuesta indicando el éxito o
fracaso de la petición. Si la petición fue correcta, el mensaje resultante también contendrá
el valor del objeto solicitado. Este mensaje puede ser usado para recoger un valor de un
objeto, o varios valores de varios objetos, a través del uso de listas.
GetNextRequest[editar]
Este mensaje es usado para recorrer una tabla de objetos. Una vez que se ha usado un
mensaje GetRequest para recoger el valor de un objeto, puede ser utilizado el mensaje
GetNextRequest para repetir la operación con el siguiente objeto de la tabla. Siempre el
resultado de la operación anterior será utilizado para la nueva consulta. De esta forma un
NMS puede recorrer una tabla de longitud variable hasta que haya extraído toda la
información para cada fila existente.
SetRequest[editar]
Este tipo de mensaje es utilizado por el NMS para solicitar a un agente modificar valores
de objetos. Para realizar esta operación el NMS envía al agente una lista de nombres de
objetos con sus correspondientes valores.
GetResponse[editar]
Este mensaje es usado por el agente para responder un mensaje GetRequest,
GetNextRequest, o SetRequest. En el campo "Identificador de Request" lleva el mismo
identificador que el "request" al que está respondiendo.
Trap[editar]
Una trap es generado por el agente para reportar ciertas condiciones y cambios de estado
a un proceso de administración. El formato de la PDU es diferente:

Dirección del Tipo genérico Tipo específico Enlazado de

Tipo Enterprise Timestamp
agente de trap de trap variables

 Enterprise: Identificación del subsistema de gestión que ha emitido el trap;

 Dirección del agente: Dirección IP del agente que ha emitido el trap;
 Tipo genérico de trap:
 Cold start (0): Indica que el agente ha sido inicializado o reinicializado;
 Warm start (1): Indica que la configuración del agente ha cambiado;
 Link down (2): Indica que una interfaz de comunicación se encuentra fuera de
servicio (inactiva);
 Link up (3): Indica que una interfaz de comunicación se encuentra en servicio
(activa);
 Authentication failure (4): Indica que el agente ha recibido un requerimiento de un
NMS no autorizado (normalmente controlado por una comunidad);
 EGP neighbor loss (5): Indica que en sistemas en que los routers están utilizando
el protocolo EGP, un equipo colindante se encuentra fuera de servicio;
 Enterprise (6): En esta categoría se encuentran todos los nuevos traps incluidos
por los vendedores.
 Tipo específico de trap: Es usado para traps privados (de fabricantes), así como para
precisar la información de un determinado trap genérico;
 Timestamp: Indica el tiempo que ha transcurrido entre la reinicialización del agente y la
generación del trap;
 Enlazado de variables: Se utiliza para proporcionar información adicional sobre la
causa del mensaje.
GetBulkRequest[editar]
Este mensaje es usado por un NMS que utiliza la versión 2 o 3 del protocolo SNMP
típicamente cuando es requerida una larga transmisión de datos, tal como la recuperación
de largas tablas. En este sentido es similar al mensaje GetNextRequest usado en la
versión 1 del protocolo, sin embargo, GetBulkRequest es un mensaje que implica un
método mucho más rápido y eficiente, ya que a través de un solo mensaje es posible
solicitar la totalidad de la tabla.
InformRequest[editar]
Un NMS que utiliza la versión 2 o 3 del protocolo SNMP transmite un mensaje de este tipo
a otro NMS con las mismas características, para notificar información sobre objetos
administrados, utilizando el protocolo de nivel 4(osi) TCP, y enviara el InformRequest hasta
que tenga un acuse de recibo.

Desarrollo y Uso[editar]
Versión 1[editar]
SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. SNMPv1
opera a través de protocolos como el User Datagram Protocol (UDP), Protocolo de Internet
(IP), servicio de red sin conexión OSI (CLNS), AppleTalk Protocolo de datagramas de
entrega (DDP), y Novell Internet Packet Exchange (IPX). SNMPv1 es ampliamente
utilizado y es el de facto protocolo de gestión de red en la comunidad de Internet.
Los primeros RFCs para SNMP, ahora conocido como SNMPv1, aparecieron en 1988:
• RFC 1065 - Estructura e identificación de información de gestión para internet basadas
en TCP / IP.
• RFC 1066 - Base de información de gestión para la gestión de la red de internet basadas
en TCP / IP.
• RFC 1067 - Un protocolo simple de administración de red.
Estos protocolos estaban obsoletos por:
• RFC 1155 - Estructura e identificación de información de gestión para internet basadas
en TCP / IP.
• RFC 1156 - Base de información de gestión para la gestión de la red de internet basadas
en TCP / IP.
• RFC 1157 - Un protocolo simple de administración de red.
Después de un corto tiempo, RFC 1156 (MIB-1) fue reemplazada por la más habitual:
• RFC 1213 - Versión 2 de la base de información de gestión (MIB-2) para la gestión de la
red de internet basadas en TCP / IP.
Versión 1 ha sido criticado por su falta de seguridad. La autenticación de los clientes se
realiza sólo por una "cadena de comunidad", en efecto, un tipo de contraseña, la cual
transmite en texto plano. El diseño de los años 80 de SNMPv1 fue realizado por un grupo
de colaboradores que vieron que el producto patrocinado oficialmente (HEMS/CMIS/CMIP)
por OSI / IETF / NSF (National Science Foundation) eran tanto inaplicable en las
plataformas informáticas de la época, así como potencialmente inviable. SNMP se aprobó
basándose en la creencia de que se trataba de un Protocolo provisional necesario para la
toma de medidas del despliegue a gran escala de Internet y su comercialización. En esos
tiempos, estándares de internet de autenticación y seguridad eran un sueño, a la vez
desalentado por los grupos de diseño enfocados en protocolos.
Versión 2[editar]
SNMPv2 ( RFC 1441 - RFC 1452 ), revisa la versión 1 e incluye mejoras en las áreas de
comunicaciones de rendimiento, la seguridad, confidencialidad e-manager-a gerente.
Introdujo GetBulkRequest, una alternativa a GetNextRequests iterativos para recuperar
grandes cantidades de datos de gestión en una sola solicitud. Sin embargo, el nuevo
sistema de seguridad basado en partidos en SNMPv2, visto por muchos como demasiado
complejo, no fue ampliamente aceptada. Esta versión de SNMP alcanzado el nivel de
madurez de Norma, pero se consideró obsoleto por las versiones posteriores.
Simple basada en la comunidad la versión Network Management Protocol 2, o SNMPv2c,
se define en el RFC 1901 - RFC 1908 . SNMPv2c comprende SNMPv2 sin el nuevo
modelo de seguridad de SNMP v2 controversial, utilizando en su lugar el sistema de
seguridad basado en la simple comunidad de SNMPv1. Esta versión es una de las
relativamente pocas normas para cumplir con el proyecto de nivel de madurez estándar del
IETF, y fue considerado el de facto estándar SNMPv2. Es también estaba obsoleto
después, por SNMPv3.
Simple de usuario basada en la versión Network Management Protocol 2, o SNMPv2u, se
define en el RFC 1909 - RFC 1910 . Este es un compromiso que pretende ofrecer una
mayor seguridad que SNMPv1, pero sin incurrir en la alta complejidad de SNMPv2. Una
variante de este se comercializó como SNMP v2 *, y el mecanismo fue finalmente
adoptado como uno de los dos marcos de seguridad de SNMP v3.
SNMPv1 y SNMPv2c interoperabilidad[editar]
Tal como está actualmente especificada, SNMPv2c es incompatible con SNMPv1 en dos
áreas clave: los formatos de mensajes y operaciones de protocolo. Mensajes SNMPv2c
utilizan diferentes cabecera y la unidad de datos de protocolo (PDU) formatos de mensajes
SNMPv1. SNMPv2c también utiliza dos operaciones de protocolo que no están
especificados en SNMPv1. Además, RFC 2576 define dos posibles estrategias de
coexistencia SNMPv1/v2c: agentes de proxy y sistemas de gestión de red bilingües.
Agentes de proxy[editar]
Un agente SNMPv2 puede actuar como un agente proxy en nombre de dispositivos
SNMPv1 administrados, de la siguiente manera: • Un SNMPv2 NMS emite un comando
destinado a un agente SNMPv1. • El NMS envía el mensaje SNMP para el agente proxy
SNMPv2. • El agente proxy reenvía Cómo, GetNext y Set mensajes al agente SNMPv1 sin
cambios. • Mensajes GetBulk son convertidas por el agente proxy de GetNext mensajes y
luego se envían al agente SNMPv1. El agente proxy mapas de mensajes de captura
SNMPv1 a SNMPv2 mensajes de captura y luego las envía al NMS.
Sistema de gestión de la red bilingüe[editar]
Sistemas de gestión de red SNMPv2 Bilingües soportan tanto SNMPv1 y SNMPv2. Para
apoyar este entorno de gestión dual, una aplicación para la gestión del NMS bilingües
debe ponerse en contacto con un agente. El NMS examina la información almacenada en
una base de datos local para determinar si el agente es compatible con SNMPv1 o
SNMPv2. Sobre la base de la información en la base de datos, el NMS se comunica con el
agente utilizando la versión adecuada de SNMP.
Versión 3[editar]
Aunque SNMPv3 no realiza cambios en el protocolo, aparte de la adición de seguridad
criptográfica, da la impresión de ser muy diferente debido a las nuevas convenciones
textuales, los conceptos y la terminología.
SNMPv3 añadió principalmente la seguridad y mejoras de configuración remota SNMP.
Debido a la falta de seguridad de las versiones previas de SNMP, los administradores de
red usaban otros medios, tales como SSH para la configuración, contabilidad y gestión de
fallos.
SNMPv3 se ocupa de cuestiones relacionadas con el despliegue a gran escala de SNMP,
contabilidad y gestión de fallos. Actualmente, SNMP se utiliza principalmente para el
control y la gestión del rendimiento.
SNMPv3 define una versión segura de SNMP y también facilita la configuración remota de
las entidades SNMP. SNMPv3 ofrece un entorno seguro para la gestión de sistemas que
abarcan los siguientes:

 Identificación de las entidades SNMP para facilitar la comunicación sólo entre

entidades SNMP conocidas - Cada entidad SNMP tiene un identificador llamado
 snmpEngineID y comunicación SNMP es posible sólo si la entidad SNMP conoce la
identidad de su interlocutor. Trampas y notificaciones son excepciones a esta regla.
 Soporte para los modelos de seguridad - Un modelo de seguridad puede definir la
política de seguridad dentro de un dominio administrativo o una intranet. SNMPv3
contiene las especificaciones para USM.
Definición de los objetivos de seguridad, donde los objetivos del servicio de autenticación
de mensajes incluyen la protección contra lo siguiente:

 Modificación de la información - Protección contra algunos no autorizados entidad que

altera SNMP en tránsito mensajes generados por un principal autorizado.
 Masquerade - Protección contra intentar operaciones de gestión no autorizadas por
algún director al asumir la identidad de otra principal que cuenta con las autorizaciones
correspondientes.
 Mensaje Corriente Modificación - Protección contra mensajes que consiguen
maliciosamente reordenado, retrasado, o reproducido para efectuar las operaciones de
gestión autorizadas.
 Divulgación - Protección contra escuchas en los intercambios entre los motores de
SNMP.
Especificación para USM - USM (Modelo de seguridad basada en el usuario) consiste en
la definición general de los siguientes mecanismos de comunicación disponibles:

 Comunicación sin autenticación y privacidad (noAuthNoPriv).

 La comunicación con la autenticación y sin privacidad (authNoPriv).
 La comunicación con la autenticación y la privacidad (authpriv).
 Definición de diferentes protocolos de autenticación y privacidad - Actualmente, los
protocolos de autenticación MD5 y SHA y los protocolos de privacidad y CBC_DES
CFB_AES_128 se admiten en la USM.
 Definición de un procedimiento de descubrimiento - Para encontrar el snmpEngineID
de una entidad SNMP para una dirección de transporte común y dirección de punto
final de transporte.
 Definición del procedimiento de sincronización de hora - Para facilitar la comunicación
autenticado entre las entidades SNMP.
 Definición del marco MIB SNMP - Para facilitar la configuración remota y
administración de la entidad SNMP.
 Definición de las MIB USM - Para facilitar la configuración remota y administración del
módulo de seguridad.
 Definición de las MIB VACM - Para facilitar la configuración remota y administración
del módulo de control de acceso.
El SNMPv3 se centra en dos aspectos principales, a saber, la seguridad y la
administración. El aspecto de seguridad se dirige, ofreciendo tanto una sólida
autenticación y cifrado de datos para la privacidad. El aspecto de la administración se
centra en dos partes, a saber los originadores de notificación y agentes proxy. SNMPv3
define una serie de capacidades relacionadas con la seguridad. Las especificaciones
iniciales definen la USM y VACM, que más tarde fueron seguidos por un modelo de
seguridad de transporte que proporciona apoyo a través de SSH y SNMPv3 SNMPv3 en
TLS y DTLS.

 USM (Modelo de Seguridad basado en Usuarios) proporciona funciones de

autenticación y privacidad (encriptación) y opera en el nivel de mensaje.
 VACM (Modelo de Control de Acceso basado en Vista) determina si se permite a un
director dado, acceso a un objeto MIB particular, para realizar funciones específicas y
opera en el nivel de PDU.
 TSM (Modo de Seguridad del Transporte) proporciona un método para la autenticación
y el cifrado de mensajes a través de los canales externos de seguridad. Dos
 transportes, SSH y TLS/DTLS, han definido que hacen uso de la especificación de
TSM.
La seguridad ha sido la mayor debilidad de SNMP desde el principio. La autenticación en
las versiones de SNMP 1 y 2 consiste sólo en una contraseña (cadena de comunidad)
enviada en texto claro entre un gerente y agente. Cada mensaje SNMPv3 contiene los
parámetros de seguridad que están codificados como una cadena de octetos. El
significado de estos parámetros de seguridad depende del modelo de seguridad que se
utiliza. SNMPv3 proporciona características de seguridad importantes:

 Confidencialidad - El cifrado de paquetes para impedir la escucha por una fuente no

autorizada.
 Integridad - Integridad de los mensajes para asegurar que un paquete no ha sido
alterado durante el tránsito que incluye un mecanismo opcional por repetición de
paquetes.
 Autenticación - para comprobar que el mensaje es de una fuente válida.
A partir de 2004 el IETF reconoce el Protocolo de Gestión de Red Simple versión 3 como
se define en el RFC 3411 - RFC 3418 (también conocido como STD0062) como la versión
estándar actual de SNMP. El IETF ha designado SNMPv3 un completo estándar de
Internet, el más alto nivel de madurez de un RFC. Considera versiones anteriores sean
obsoletos (designándolos diversamente "Histórico" u "Obsoleto"). En la práctica, las
implementaciones de SNMP a menudo soportan múltiples versiones: Típicamente
SNMPv1, SNMPv2c y SNMPv3.

Dificultades de implementación[editar]
Las implementaciones del protocolo SNMP pueden variar entre diferentes fabricantes. En
algunos casos, el SNMP es incorporado como una característica adicional en el sistema y
no como un elemento fundamental del mismo. Algunos fabricantes tienden a ampliar en
exceso su interfaz de línea de comandos (CLI) propietaria para configurar y controlar sus
sistemas.
La estructura tipo árbol aparentemente simple y el indexado lineal del SNMP pueden no
ser interpretados suficientemente bien por las estructuras de datos que son elementos del
diseño básico de una plataforma. En consecuencia, el procesamiento de consultas SNMP
en ciertos conjuntos de dato pueden exigir más uso del CPU del necesario. Por ejemplo,
se crearían tablas de enrutamiento más grandes de lo normal, como BGP y IGP.
Algunos valores de SNMP (como los valores tabulares) requieren conocer específicamente
los esquemas de los índices, los cuales no son necesariamente consistentes en todas las
plataformas. Esto puede causar problemas de correlación entre los valores de diferentes
equipos que no usan el mismo esquema en sus índices (por ejemplo, al recopilar métricas
sobre la utilización del disco cuando un "identificador de disco" específico sea diferente
entre plataformas.

Indexación de Recursos[editar]
Los dispositivos modulares pueden aumentar o disminuir sus índices de SNMP (también
conocidos como instancias) cada vez que se agrega o quita hardware en una ranura de
forma dinámica. Aunque esto es más común con el hardware, las interfaces virtuales
tienen el mismo efecto. Los valores de índice se suelen asignar en el momento del
arranque y permanecen fijos hasta el siguiente reinicio. Los índices del hardware o de las
entidades virtuales añadidas mientras el dispositivo está "en marcha" pueden ser
asignados al final de la gama existente y posiblemente ser reasignados en el siguiente
reinicio. Las herramientas de inventario y monitorización de redes necesitan tener
capacidad de actualización del dispositivo reaccionando adecuadamente al trap de
arranque en frío en el reinicio del dispositivo para evitar la corrupción y la falta de
coincidencia de los datos sondeados.
Las asignaciones de índice para una instancia de dispositivo SNMP pueden cambiar de
sondeo a sondeo sobre todo como resultado de los cambios iniciados por el administrador
del sistema. Si se necesita información para una interfaz en particular, es imprescindible
determinar el índice de SNMP antes de recuperar los datos necesarios. Generalmente,
una tabla de descripción como ifDescr asignará un nombre de usuario como serie 0/1
(Blade 0, puerto 1) a un índice SNMP.

Implicaciones de Seguridad[editar]
 SNMP versiones 1 y 2c están sujetos a la detección de paquetes de la cadena de
comunidad borre el texto del tráfico de red, ya que no implementan el cifradoss.
 Todas las versiones de SNMP están sujetos a la fuerza bruta y ataques de diccionario
para adivinar las cadenas de comunidad, cadenas de autenticación, las claves de
autenticación, cadenas de cifrado o claves de cifrado, ya que no implementan un
protocolo de enlace de desafío-respuesta .
 Aunque SNMP funciona sobre TCP y otros protocolos, se utiliza con mayor frecuencia
sobre UDP que está sin conexión y vulnerables a la suplantación de IP ataques. Por lo
tanto, todas las versiones están sujetos a pasar por las listas de acceso de dispositivos
que podrían haber sido implementadas para restringir el acceso SNMP, aunque otros
mecanismos de seguridad de SNMPv3 debe impedir un ataque exitoso.
 Potente configuración de SNMP (escritura) capacidades no están siendo plenamente
utilizados por muchos vendedores, en parte debido a la falta de seguridad en las
versiones de SNMP SNMPv3 antes y en parte debido a que muchos dispositivos,
simplemente no son capaces de ser configurado a través de cambios en los objetos
MIB individuales.
 SNMP encabeza la lista del Instituto SANS Común Defecto Problemas de
configuración con el tema de las cadenas de comunidad SNMP por defecto
establecidos en 'público' y 'privado' y era el número diez en la escala SANS Top 10
amenazas de seguridad de Internet más críticos para el año 2000.

Descubrimiento Automático[editar]
SNMP por sí mismo no es más que un protocolo para la recolección y organización de
información. La mayoría de los conjuntos de herramientas de aplicación SNMP ofrecen
algún tipo de mecanismo de descubrimiento, una recopilación normalizada de datos
comunes a la mayoría de las plataformas y dispositivos, para obtener un nuevo usuario o
implementador comenzaron. Una de estas características es a menudo una forma de
descubrimiento automático, donde los nuevos dispositivos detectados en la red se
sondean automáticamente. Para SNMPv1 y SNMPv2c, esto representa un riesgo de
seguridad, ya que su lectura SNMP comunidades serán transmitidos en texto plano para el
dispositivo de destino. Mientras que los requisitos de seguridad y perfiles de riesgo varían
de una organización a otra, se debe tener cuidado al usar una función como esta, con
especial atención a los entornos comunes, como los centros de datos mixtos e inquilinos,
servidor de alojamiento y las instalaciones de colocación, y ambientes similares.

SNMP. Un protocolo
simple de gestión
La proliferación de redes de datos a lo largo de la
década de los 90, tanto LANs como WANs, y el
interfuncionamiento entre ellas hace que los
aspectos relativos a su control y gestión cada vez
sean más tenidos en cuenta, convirtiéndose en algo
a lo que todos los responsables de redes han de
prestar una gran atención.

ado que la tendencia natural de una red

cualquiera es a crecer, conforme se añaden
nuevas aplicaciones y más y más usuarios
hacen uso de la misma, los sistemas de
gestión empleados han de ser lo
suficientemente flexibles para poder soportar los
nuevos elementos que se van añadiendo, sin necesidad
de realizar cambios drásticos en la misma.

Este punto, el de gestión de red, es uno de los más

controvertidos en teleinformática, ya que,
prácticamente, no existe una solución única, aceptada
por todos y que sea fácilmente implantable. Las
soluciones existentes suelen ser propietarias -Netview
de IBM, OpenView de HP, etc.- lo que hace que en
una red compleja, formada por equipos
multifabricante, no exista un único sistema capaz de
realizar la gestión completa de la misma,
necesitándose varias plataformas -una por cada
fabricante-, lo que
dificulta y complica
enormemente la labor del
gestor de red.

Con la idea de presentar

una solución única, válida
para cualquier tipo de red,
varios grupos de
normalización están trabajando en ello y, aunque hay
dos tendencias claras (SNMP para redes de empresa y
CMIS/CMIP para redes públicas), sólo SNMP es la
que está consiguiendo una aceptación e implantación
amplia, a lo que ha contribuido su sencillez y rapidez
de desarrollo.

Una forma sencilla de supervisión

SNMP (Simple Network Management Protocol), en

sus distintas versiones, es un conjunto de aplicaciones
de gestión de red que emplea los servicios ofrecidos
por TCP/IP, protocolo del mundo UNIX, y que ha
llegado a convertirse en un estándar. Surge a raíz del
interés mostrado por la IAB (Internet Activities
Board) en encontrar un protocolo de gestión que fuese
válido para la red Internet, dada la necesidad del
mismo debido a las grandes dimensiones que estaba
tomando. Los tres grupos de trabajo que inicialmente
se formaron llegaron a conclusiones distintas, siendo
finalmente el SNMP (RFC 1098) el adoptado,
incluyendo éste algunos de los aspectos más
relevantes presentados por los otros dos:
HEMS (High-Level Management System) y
SGMP (Simple Gateway Monitoring Protocol).

Para el protocolo SNMP la red constituye un conjunto

de elementos básicos -
Administradores o Management Stations) ubicados
en el/los equipo/s de gestión de red y Gestores
(Network Agentes (elementos pasivos ubicados en los
nodos -host, routers, modems, multiplexores, etc.- a
ser gestionados), siendo los segundos los que envían
información a los primeros, relativa a los elementos
gestionados, por iniciativa propia o al ser interrogados
(polling) de manera secuencial, apoyándose en los
parámetros contenidos en sus MIB (Management
Information Base). Su principal inconveniente es el
exceso de tráfico que se genera, lo que lo puede hacer
incompatible para entornos amplios de red; por contra
CMIS/CMIP (Common Management Information
Service/Protocol) de OSI ofrece un mejor rendimiento
y seguridad, estando orientado a la administración de
sistemas extendidos.

La versión 2 de SNMP aporta una serie de mejoras

frente a la original, que, fundamentalmente, se
manifiestan en tres áreas particulares: seguridad
(autentificación, privacidad y control de accesos),
transferencia de datos y comunicaciones
Administrador a Administrador.
Los cinco tipos de mensajes SNMP intercambiados
entre los Agentes y los Administradores, son:

- Get Request

Una petición del Administrador al Agente para que

envíe los valores contenidos en el MIB (base de
datos).

- Get Next Request

Una petición del Administrador al Agente para que

envíe los valores contenidos en el MIB referente al
objeto siguiente al especificado anteriormente.

- Get Response

La respuesta del Agente a la petición de información

lanzada por el Administrador.

- Set Request

Una petición del Administrador al Agente para que

cambie el valor contenido en el MIB referente a un
determinado objeto.

- Trap

Un mensaje espontáneo enviado por el Agente al

Administrador, al detectar una condición
predeterminada, como es la conexión/desconexión de
una estación o una alarma.

El protocolo de gestión SNMP facilita, pues, de una

manera simple y flexible el intercambio de
información en forma estructurada y efectiva,
proporcionando significantes beneficios para la
gestión de redes multivendedor, aunque necesita de
otras aplicaciones en el NMS que complementen sus
funciones y que los dispositivos tengan un software
Agente funcionando en todo momento y dediquen
recursos a su ejecución y recogida de datos.

Una amplia base de información

A través del MIB se tiene acceso a la información

para la gestión, contenida en la memoria interna del
dispositivo en cuestión. MIB es una base de datos
completa y bien definida, con una estructura en árbol,
adecuada para manejar diversos grupos de objetos
(información sobre variables/valores que se pueden
adoptar), con identificadores exclusivos para cada
objeto.

La arquitectura SNMP opera con un reducido grupo

de objetos que se encuentran definido con detalle en la
RFC 1066 "Base de información de gestión para la
gestión de redes sobre TCP/IP".

Los 8 grupos de objetos habitualmente manejados por

MIB (MIB-I), que definen un total de 114 objetos
(recientemente, con la introducción de MIB-II se
definen hasta un total de 185 objetos), son:

- Sistema: Incluye la identidad del vendedor y el

tiempo desde la última reinicialización del sistema de
gestión.

- Interfaces: Un único o múltiples interfaces, local o

remoto, etc.

- ATT (Address Translation Table): Contiene la

dirección de la red y las equivalencias con las
direcciones físicas.

- IP (Internet Protocol): Proporciona las tablas de

rutas, y mantiene estadísticas sobre los datagramas IP
recibidos.

- ICMP (Internet Communication Management

Protocol): Cuenta el número de mensajes ICMP
recibidos y los errores.

- TCP (Transmission Control Protocol): Facilita

información acerca de las conexiones TCP,
retransmisiones, etc.

- UDP (User Datagram Protocol): Cuenta el número

de datagramas UDP, enviados, recibidos y entregados.

- EGP (Exterior Gateway Protocol): Recoge

información sobre el número de mensajes EGP
recibidos, generados, etc.
* J. Manuel Gestión a
Huidobro
Es ingeniero distancia
Superior de
Telecomunicacio
nes y Además de éstos,
Responsable del
Centro de
ciertos fabricantes
Información están cooperando
al Cliente en
para el desarrollo
Ericsson de extensiones
Comunicaciones particulares para
de Empresa.
ciertas clases de
productos y la
gestión remota de
dispositivos,

conocidas
como RMON
(Remote MONitor),
normas RFC 1757
(antes 1271) para
Ethernet y RFC
1513 para Token
Ring
del IETF (Internet
Engineering Task
Force), que
incluyen sobre unos
200 objetos
clasificados en 9
grupos: Alarmas,
Estadísticas,
Historias, Filtros,
Ordenadores, N
Principales, Matriz
de Tráfico, Captura
de Paquetes y
Sucesos. Con
RMONv2 se
decodifican
paquetes a nivel 3
de OSI, lo que
implica que el
trafico puede
monitorizarse a
nivel de direcciones
de red (puertos de
los dispositivos) y
aplicaciones
específicas.

RMON define las

funciones de
supervisión de la
red y los interfaces
de comunicaciones
entre la plataforma
de gestión SNMP,
los monitores
remotos y los
Agentes de
supervisión que
incorporan los
dispositivos
inteligentes.

- Alarmas: Informa
de cambios en las
características de la
red, basado en
valores umbrales
para cualquier
variable MIB de
interés. Permite que
los usuarios
configuren una
alarma para
cualquier Objeto
gestionado.

- Estadísticas:
Mantiene
utilización de bajo
nivel y estadísticas
de error.

- Historias:
Analiza la
tendencia, según
instrucciones de los
usuarios, basándose
en la información
que mantiene el
grupo de
estadísticas.

- Filtros: Incluye
una memoria para
paquetes entrantes
y un número
cualquiera de filtros
definidos por el
usuario, para la
captura selectiva de
información;
incluye las
operaciones lógicas
AND, OR y NOT.

- Ordenadores:
Una tabla
estadística basada
en las direcciones
MAC, que incluye
información sobre
los datos
transmitidos y
recibidos en cada
ordenador.

- Los N
principales:
Contiene solamente
estadísticas
ordenadas de los
"N" ordenadores
definidos por el
usuario, con lo que
se evita recibir
información que no
es de utilidad.

- Matriz de
tráfico:
Proporciona
información de
errores y utilización
de la red, en forma
de una matriz
basada en pares de
direcciones, para
correlacionar las
conversaciones en
los nodos más
activos.

- Captura de
paquetes: Permite
definir buffers para
la captura de
paquetes que
cumplen las
 condiciones de
filtrado.

- Sucesos: Registra
tres tipos de
sucesos basados en
los umbrales
definidos por el
usuario:
ascendente,
descendente y
acoplamiento de
paquetes, pudiendo
generar
interrupciones para
cada uno de ellos

Agregar al perfil en la parte de comparaciones de protocolos de

administración/monitoreo entre dispositivos de red.

Diferencia 1: MQTT es un protocolo dedicado para IoT

Este protocolo se optimizó para dispositivos restringidos y redes de bajo ancho de

banda, alta latencia o poco confiables.

Protocolo utilizado para la comunicación M2M

Tiene la finalidad de minimizar los requerimientos de recursos del dispositivo y, a la

vez, tratar de asegurar la confiabilidad y cierto grado de seguridad de entrega con
calidad del servicio.

HTTP es un protocolo pesado

Ambos utilizan TCP

Internet of Things
requirements and protocols
FEBRUARY 1, 2014KIM ROWE (ROWEBOTS)
Higher-level protocols for the Internet of Things (IoT) offer
various features that make them suitable for a broad range of
applications. For example, SNMP has been used for many
years to manage network devices and configure networks and
DDNS has been used to provide browser access to web
devices. Either protocol can also be used for managing and
configuring a variety of home devices. In comparison, CoAP is
more suited to very small sensor deployments with tiny
hardware and completely different security. A deeper
understanding of these protocols and the applications
requirements is necessary to properly select which protocol is
most suitable for the application at hand.

Once the correct protocol or set of a few protocols is known to

have the right characteristics for the application deployment,
management and application support, the best implementation
of each protocol should be understood. From this
understanding, the designer can select the optimal
implementation of each protocol for the system and then from
these, select the best protocol implementation for the system.

The protocol selection problem is closely tied to the

implementation of the protocol and the components that
support the protocol are often essential in the final design. This
makes the decision a very complex one. All aspects of
deployment, operation, management, and security must be
considered as part of the protocol selection including the
implementation environment.

In addition, there are not any converged standards for

particular applications, and these standards are generally
selected by the market. This is a problem and an opportunity
because the protocol selected for an application today may
become obsolete in the future and may need to be replaced,
or could become the standard if done correctly. As a
developer, using specific features of the environment, to
satisfy system requirements, that, in turn, rely on the details of
the protocol, can make change in the future very difficult.

This article examines the range of protocols available, the

specific requirements that drive the features of these protocols
and considers the implementation requirements to build a
complete system.

Protocols and vendors

Higher-level protocols for Internet of Things have various

features and offer different capabilities. Most of these protocols
were developed by specific vendors, and these vendors
typically promote their own protocol choices, don’t clearly
define their assumptions, and ignore the other alternatives. For
this reason, relying on vendor information to select IoT
protocols is problematic and most comparisons that have been
produced are insufficient to understand tradeoffs.

IoT protocols are often bound to a business model. Sometimes

these protocols are incomplete and/or used to support existing
business models and approaches. Other times, they offer a
more complete solution but the resource requirements are
unacceptable for smaller sensors. In addition, the key
assumptions behind the use of the protocol are not clearly
stated which makes comparison difficult.

The fundamental assumptions associated with IoT applications

are:

 Various wireless connections will be used

 Devices will range from tiny MCUs to high-performance

systems with the emphasis on small MCUs

 Security is a core requirement

 Data will be stored in the cloud and may be processed in
the cloud

 Connections back to the cloud storage are required

 Routing of information through wireless and wireline

connections to the cloud storage is required

Other assumptions made by the protocol developers require

deeper investigation and will strongly influence their choices.
By looking at the key features of these protocols and looking at
the key implementation requirements, designers can develop a
clearer understanding of exactly what is required in both the
protocol area and in the supporting features area to improve
their designs. Before we look at this, let’s review the protocols
in question.

IoT or M2M protocols

There is a broad set of protocols that are promoted as the

silver bullet of IoT communication for the higher-level M2M
protocol in the protocol stack. Note that these IoT or M2M
protocols focus on the application data transfer and
processing. The following list summarizes the protocols
generally considered.

 CoAP

 Continua – Home Health Devices

 DDS

 DPWS: WS-Discovery, SOAP, WSAddressing, WDSL, and

XML Schema

 HTTP/REST

 MQTT
 UPnP

 XMPP

 ZeroMQ

These protocols have their features summarized in Figure 1.

Several key factors related to infrastructure and deployment
are considered separately below.

Figure 1: All M2M or IoT protocols can be supported much more easily if a POSIX/Linux API is
available. The Unison OS is being fitted with key combinations of IoT protocols as off the shelf
options using it’s POSIX API for fast and simple device support.

Key protocol features

Communications in the Internet of Things (IoT) is based on the

Internet TCP/UDP protocols and the associated Internet
protocols for setup. For basic communication, this means
either UDP datagrams of TCP stream sockets. Developers of
smaller devices claim that UDP offers large advantages in
performance and size, which will in turn minimize cost.
Although true, it is not significant in many instances.

Stream sockets suffer a performance hit but they do guarantee

in-order delivery of all data. The performance hit on sending
sensor data on an STM32F4 at 167 MHz is less than 16.7
percent (measured with 2 KB packets – smaller packets
reduce the performance hit). By taking the approach of stream
sockets, standard security protocols can also be used which
simplifies the environment (although DTLS could be used with
UDP if available).

Similarly, the difference in memory cost for an additional 20

KB of flash and 8 KB of RAM to upgrade to TCP is generally
small. For trivial applications and sensors with huge volume,
this may be meaningful but generally does not affect designs
for ARM Cortex-M3 and greater or other architectures like RX,
PIC32 and ARM Cortex-Ax.

Messaging the common IoT approach is very important and

many protocols have migrated to a publish/subscribe model.
With many nodes connecting and disconnecting, and these
nodes needing to connect to various applications in the cloud,
the publish/subscribe request/response model has an
advantage. It responds dynamically to random on/off operation
and can support many nodes.

Two protocols, CoAP and HTTP/REST, are both based on

request response without a publish/subscribe approach. In the
case of CoAP, the use of 6LoWPAN and the automatic
addressing of IPv6 is used to uniquely identify nodes. In the
case of HTTP/REST the approach is different in that the
request can be anything including a request to publish or a
request to subscribe so in fact it becomes the general case if
designed in this way. Today, these protocols are being merged
to provide a complete publish/subscribe request/response
model.
System architectures are varied, including client server, tree or
star, bus, and P2P. The majority use client-server but others
use bus and P2P approaches. A star is a truncated tree
approach. Performance issues exist for these various
architectures with the best performance generally found in
P2P and bus architectures. Simulation approaches or
prototype approaches are preferred early in design to
safeguard against surprises.

Scalability depends on adding many nodes in the field, and

having the cloud resources easily increased to service these
new nodes. The various architectures have different
properties. For client server architectures, increasing the pool
of available servers is sufficient and easy. For bus and P2P
architectures, scale is inherent in the architecture but there are
no cloud services. In the case of tree or star connected
architectures, there can be issues associated with adding
extra leaves on the tree, which burdens the communication
nodes.

Another aspect of scalability is dealing with a large number of

changing nodes and linking these nodes to cloud applications.
As discussed, publish/subscribe request/response systems
are intended for scalability because they deal with nodes that
go off line for a variety of reasons, which allows applications to
receive specific data when they decide to subscribe and
request data resulting in fine data flow control. Less robust
approaches don’t scale nearly as well.

Low-Power and Lossy Networks have nodes that go on and

off. This dynamic behaviour may affect entire sections of the
network so protocols are designed for multiple paths dynamic
reconfiguration. Specific dynamic routing protocols found in
ZigBee, ZigBee IP (using 6LoWPAN), and native 6LoWPAN
ensure that the network adapts. Without these features,
dealing with these nodes becomes one of discontinuous
operation and makes the resource requirements of the nodes
much higher

Resource requirements are key as application volume

increases. Microcontrollers offer intelligence at very low cost,
and have the capacity to deal with the issues listed above.
Some protocols are simply too resource-intensive to be
practical on small nodes. There will be limitations around
discontinuous operation and big data storage unless
significant amounts of serial flash or other storage media are
included. As resources are increased, to reduce overall
system costs, aggregation nodes are more likely to be added
to provide additional shared storage resources.

Interoperability is essential for most devices in the future. Thus

far the industry has seen sets of point solutions, but ultimately
users want sensors and devices to work together. By using a
set of standardized protocols as well as standardized
messaging, devices can be separated from the cloud services
that support them. This approach could provide complete
device interoperability. Also, using intelligent publish/subscribe
options, different devices could even use the same cloud
services, and provide different features. Using an open
approach, application standards will emerge, but today the
M2M standards are just emerging and the applications
standards are years in the future. All the main protocols are
being standardized today.

Security using standard information technology security

solutions are the core security mechanisms for most of these
protocols that offer security. These security approaches are
based on:

 TLS

 IPSec / VPN

 SSH
 SFTP

 Secure bootloader and automatic fallback

 Filtering

 HTTPS

 SNMP v3

 Encryption and decryption

 DTLS (for UDP-only security)

As systems will be fielded for many years, design with security

as part of the package is essential.

Implementation requirements

Privacy is an essential implementation requirement. Supported

by privacy laws, almost all systems require secure
communication to the cloud to ensure personal data cannot be
accessed or modified and liabilities are eliminated.
Furthermore, the management of devices and the data that
appears in the cloud need to be managed separately. Without
this feature, users’ critical personal information is not protected
properly and available to anyone with management access.
 Figure 2: Using two separate back-end or cloud solutions to separate management and user
data is a preferred solution to guarantee privacy for users. Billing for the management system
and billing for the application can also be separately managed using this approach.

In the system architecture diagram we show the two separate

components inside the cloud required for system management
and application processing to satisfy privacy laws. Both
components may have separate billing options and can run in
separate environments. The management station may also
include:

 System initialization

 Remote field service options (such as field upgrades, reset

to default parameters, and remote test)

 Control for billing purposes (such as account disable,

account enable, and billing features)

 Control for theft purposes (the equivalent of bricking the

device)
Given this type of architecture, there are additional protocols
and programs that should be considered:

 Custom developed management applications on cloud

systems

 SNMP management for collections of sensor nodes

 Billing integration programs in the cloud

 Support for discontinuous operation using SQLite running

on Unison OS to store and selectively update data to the cloud

Billing is a critical aspect of commercial systems. Telecoms

operators have demonstrated that the monthly pay model is
the best revenue choice. In addition, automatic service
selection and integration for seamless billing is important. Also
credit card dependence creates issues including over the limit
issues, expired cards and deleted accounts.

Self-supporting users are a key to implementation success,

too. This includes things like remote field service so devices
never return to the factory, intelligent or automatic
configuration, online help, community help, and very intuitive
products are all key.

Application integration is also important. Today point systems

predominate, but in the future the key will be making sensors
available to a broad set of applications that the user chooses.
Accuracy and reliability can substantially influence results
application results and competition is expected in this area as
soon as standard interfaces emerge. Indirect access via a
server ensures security, evolution without application changes
and billing control.

Discontinuous Operation and Big Data go hand in hand. With

devices connecting and disconnecting randomly, a need to
preserve data for the sensors and update the cloud later is
required. Storage limitations exist for both power and cost
reasons. If some data is critical, it may be saved while other
data is discarded. All data might be saved and a selective
update to the cloud performed later. Algorithms to process the
data can run in either the cloud or the sensors or any
intermediate nodes. All of these options present particular
challenges to the sensor, cloud, communications, and external
applications.

Multiple connection sensor access is also a requirement to

make sensors truly available to a broad set of applications.
This connection will most likely happen through a server to
simplify the sensors and eliminate power requirements for
duplicate messages.

IoT protocols for the Unison OS

The Unison RTOS is targeted at small microprocessors and

microcontrollers for IoT applications. As such it offers many of
the things that designers would expect are required. Unison’s
features include:

 POSIX APIs

 Extensive Internet protocol support

 All types of wireless support

 Remote field service

 USB

 File systems

 SQLite

 Security modules
This is in addition to off-the-shelf support and factory support
for the wide set of protocols discussed here.

By providing a complete set of features and modules for IoT

development along with a modular architecture, developers
can insert their protocols of choice for IoT development.
Building protocol gateways is also possible. This approach
minimizes risk by eliminating lock-in and shortening time to
market.

Unison is also scalable, which allows it to fit into tiny

microcontrollers and also provide comprehensive support on
powerful microprocessors. The memory footprint is tiny which
leads directly to a very fast implementation.

Protocols for the Internet of Things

Many protocols are being touted as ideal Internet of Things

(IoT) solutions. Often the correct protocol choices are
obscured by vendors with vested interests in their offerings.
Users must understand their specific requirements and
limitations and have a precise system specification to make
sure that the correct set of protocols is chosen for the various
management, application and communications features and
make sure that all implementation specifications are met.

RoweBots Unison RTOS is suited to address IoT requirements

with off-the-shelf modules for a variety of protocols and a
complete set of supporting modules for fast and easy
development.

Kim Rowe is Founder of RoweBots Limited.