View
172
Download
2
Category
Preview:
DESCRIPTION
Descripción del funcionamiento de este protocolo
Citation preview
PROTOCOLO SSDP Alvaro Humberto Cisneros, José Andres Rojas
Maestría Ciencias de la información y las comunicaciones
Universidad Distrital Francisco José de Caldas
Bogotá, Colombia
humcis@gmail.com
ing.jar@hotmail.com
Resumen - El protocolo SSDP es un
protocolo de descubrimiento de dispositivos y
servicios plug and play de la red, sus siglas
responden a Simple Service Discovery
Protocol, utiliza un protocolo HTTP para la
resolución de descubrimiento y para la prestar
el servicio que el cliente esta solicitando. El
SSDP esta regulado por la RFC SSDP. Este
protocolo se desarrolla bajo ambiente de
redes pequeñas LAN y se utiliza para mejorar
el proceso de descubrimiento y resolución de
servicios de un dispositivo nuevo en la red o
que este conectado a un elemento de la red,
por ejemplo impresoras, FAX, entre otros
elementos.
INTRODUCCIÓN
En el presente artículo se desarrolla un
estudio sobre el protocolo SSDP, este
protocolo es utilizado en los ambientes LAN
de pequeñas redes para hogar y
microempresas, permite el descubrimiento y
configuración de dispositivos plug and play.
FUNCIONAMIENTO
El Protocolo SSDP o Protocolo Simple de
Descubrimiento de Servicios (Simple Service
Discovery Protocol) es un protocolo que se
utiliza para la búsqueda de dispositivos UPnP
(Universal Plug and Play) en una red.
Su estructura según la versión V1.0 utiliza un
mensaje HTTP para el descubrimiento,
notificación y configuración, este mensaje en
HTTP maneja en su capa de transporte el
protocolo UDP en unicast o multicast
apuntando al puerto 1900 para anunciar los
servicios de un dispositivo. Solo la
información más relevante acerca del
dispositivo y el servicio que se ofrece se
encuentra contenido en los mensajes
intercambiados.
Este protocolo declara una terminología que
se tiene en cuenta para el procedimiento de
SSDP
El cliente SSDP: Quien solicita o hace uso
del servicio SSDP
El servicio SSDP: Un recurso HTTP que
provee el servicio usado por los clientes
SSDP
Tipo de servicio: Un identificador uniforme
de recursos URI que identifica el tipo o
función particular del servicio.
Nombre único de servicio USN, una URI que
garantiza que el proceso sea único es usado
para identificar un servicio en particular de
los múltiples servicios que puedan ser
generados en la red.
El protocolo maneja 2 tipos de paquetes
HTTP-Request uno maneja la instrucción
“NOTIFY” el otro paquete es “M-SEARCH”,
el primero anuncia que tipos de servicio
ofrece y segundo es de solicitud de servicios,
estos paquetes dejan vacio el cuerpo de HTTP
y la cabecera contiene los siguientes
elementos de notificación e identificación.
Cuando una un servidor se presta a prestar el
servicio aparece un mensaje con el código
200 Ok que indica que se prestará el servicio.
En general el protocolo SSDP maneja tres
mensajes M-SEARCH en multicast para
solicitar un servicio y utiliza 9 paquetes
unicast para cuando tanto el cliente como el
servidor reconocen quien es el cliente y quien
el servidor se inicia la transmisición de la
configuración de HTTP este maneja en
transporte el protocolo TCP y un mensaje
unicast desde el router con un puerto TCP 80
y el equipo con el puerto dirección IP
determinadas por el equipo.
Cabecera M-SEARCH
S: Identificador UNI
Host: Dirección Destino consulta,
239.255.255.250:1900
MAN: tipo de servicio de red. “Generalmente
de descubrimiento”
ST: Identificador simple que especifica que
tipo de servicio requiere
MX: paquetes a retransmitir, comúnmente en
3.
Cabecera NOTIFY
Host: Dirección publicación de servicios
239.255.255.250:1900
Cache Control: max-age, máximo tiempo de
vida de los paquetes.
Location: Dirección IP de la fuente
prestadora del servicio.
NT: Identificador UNI de servicio a prestar
NTS: Identificador de servicio UNI
específico similar a S, tiene por lo general los
valores "ssdp:alive" para registrarse o
"ssdp:byebye" para cancelar el registro o
solicitud.
USN: Nombre de la unidad de servicio a
prestar.
Cabecera HTTP OK
Es una cabecera normal de HTTP lo que
tenemos que tener en cuenta son algunos
parámetros como:
Status code = 200
Response phase: OK
Server: Servicio prestado o suministrado.
Las gráficas a continuación muestran el
desarrollo de una comunicación SSDP
Figura 1. Mensaje SSDP M-Search
En la anterior grafica se observa una petición
de configuración de puerta de enlace
Figura 2. Mensaje SSDP Notify
En esta gráfica se observa que el router envía
un mensaje multicast para notificar que presta
este servicio.
Figura 3. HTTP OK identificador 200
En esta gráfica vemos el archivo HTTP 200
Ok que indica la prestación del servicio.
Figura 4. Mensaje HTTP puertos TCP y
direcciones IP.
En esta grafica observamos que el servicio se
presta de forma unicast siendo el router un
servidor con puerto 80 en TCP y el equipo
tiene un puerto de 58008, también se observa
que es el router el que envía la información
de configuración al equipo.
Cabe notar que mientras se envían mensajes
m-search y notify de SSDP estos manejan en
capa de transporte el protocolo UDP solo se
activa TCP cuando se confirma que se envía
la configuración o servicio solicitado al
cliente que lo requiere. Esto permite que no
se genere tanta congestión.
APLICACIONES SOBRE REDES
En las redes caseras o de pequeñas empresas
se ha optado por implementar este protocolo
ya que para el usuario normal permite una
configuración rápida de elementos de red
como impresoras, cámaras, televisores, entre
otros sin necesidad de implementar o tener
que instalar protocolos de red para compartir
archivos o dispositivos periféricos.
Con la creciente industria de elementos para
hogar e industria que necesitan de conexión
y configuración LAN de forma ágil este
protocolo permite una gran flexibilidad
permitiendo a cualquier equipo que se
conecte a la red enviar la configuración
necesaria manejando tráfico TCP unicast
solamente cuando el cliente y el router que
presta este servicio se escuchan, mientras
pasa este proceso los mensajes de m-search y
de notify solamente se manejan en UDP pero
en multicast.
Aunque como vemos es un protocolo que
permite una gran flexibilidad es también un
protocolo que debido a su transmisión
multicast puede saturar la red. Se recomienda
en redes pequeñas hogar y pequeñas
empresas, estos mensajes en multicast pueden
ser deshabilitados del router ya que en el
tráfico LAN pueden generar congestión
debido a que el router esta constantemente
notificando que presta dichos servicios. Otro
punto a evaluar es que si existe un intruso
puede emular la prestación de estos servicios
y puede con ello enviar a los equipos
información maliciosa para la configuración
de estos.
CALCULO DE TIEMPO DE RESOLUCIÓN
Y FLUJO DE INFORMACIÓN
Un aspecto importante en el desempeño de
las redes es la cantidad o flujo de información
que se necesita para configurar un equipo en
la red, puesto que si un equipo es conectado
para su uso compartido en la red, ejemplo una
impresora, este generará una carga de
paquetes adicionales en el entorno LAN que
pueden generar colas de transmisión en el
router. Si un protocolo gasta un promedio de
bytes para configurar un dispositivo
determinado podemos como administradores
de una red LAN decidir cuales de estos
protocolos o servicios implementamos para
mejorar el desempeño de la red.
A continuación se muestra un ejemplo que
fue modificado del paper Simple Service
Discovery Protocol/1.0 Operating without an
Arbiter <draft-cai-ssdp-v1-03.txt>.
“Según el algoritmo utilizado por este
protocolo el ancho de banda que utiliza
mediante un periodo de tiempo determinado
en función de las solicitudes de
descubrimiento es “[1]:
((DR*3 + DR*9*RS)*AM)/TP [1]
Donde las siglas de esta ecuación describen lo
siguiente:
DR = Número total de clientes de SSDP que
hacen peticiones de descubrimiento sobre el
periodo de tiempo de la muestra.
RS = Número total de servicio que
correspondes a SSDP:discover
AM = tamaño medio de los paquetes de
peticiones respuestas
TP = Tiempo o periodo de resolución de un
servicio SSDP:discover.
El 3 es el número de veces que el SSDP:
discover será repetido. El 9 es el número de
veces que las respuestas de unidifusión a la
ssdp:discover. Asumiendo que se repite la
configuración 3 veces debido al mensaje de
descubrimiento enviado.
Con estos datos suministrados colocamos el
ejemplo de una red corporativa de 200
clientes con 40 impresoras, imaginemos que
se conectan a la red y necesitan de dichos
servicio de impresión, si el tiempo TP es de
40 segundos, el tamaño de los paquetes en
promedio es de 512 bytes se obtiene que:
DR = 200 , RS = 40; AM = 512 Bytes, TP =
40 segundos
((200*3+200*9*40)*512)/40 = 929280
Bytes/seg = 0.88623Mbytes/seg
Si la red sufriera un reinicio el total de
información que tiene que enviar para superar
este inconveniente sería de 0.88623
Mbytes/seg * 40 seg = 35,4492 MBytes. Si se
asume que la red de la empresa tiene una red
Ethernet de 10 Mbps y la carga total efectiva
de esta red es de 5 Mbps el tiempo con el cual
la red se estabilizaría sería de 35,4492/5 = 7,1
segundos. Es una respuesta bastante rápida
para un entorno pequeño o red pequeña
empresarial.
CONCLUSIONES
El protocolo SSDP es un protocolo para el
descubrimiento y la configuración de los
dispositivos plug and play de la red, ejemplo
impresoras, cámaras, televisores, etc.
Su configuración esta dada para que funcione
en entornos de redes pequeñas tipo hogar y
pequeñas empresas.
Maneja mensajes de descubrimiento y
notificación estos se manejan multicast con la
dirección 239.255.255.250 y con el puerto
UDP 1900, cuando se realiza el
descubrmiento se maneja la configuración por
HTTP y el protocolo TCP con mensajes
unicast desde el router hasta el equipo cliente
que solicita el servicio.
El flujo de datos por segundo esta dado por
variables como el número de clientes, el
número de servicios el tamaño promedio de
los paquetes de descubrimiento y el tiempo
promedio de la resolución de los mismos, la
formula del algoritmo nos permite calcular el
ancho de banda que consume el protocolo
para configurar la red.
REFERENCIAS
[1] Yaron Y. Goland, Ting Cai, Paul
Leach, Ye Gu, Simple Service Discovery
Protocol/1.0 Operating without an Arbiter,
2010.
Recommended