Tema 2.- Redes inalámbricas Ad Hoc.
Tema 2.- Redes inalámbricas Ad Hoc.
Aspectos relacionados Aspectos relacionados
Configuración cero
Z f Z C fi i N ki
Zeroconf: Zero Configuration Networking
Propuestas del Grupo
802.11 Bluetooth
009 MIT 2008/20
ZEROCONF: Grupo de trabajo del IETF
E t bl id ti b d 1999
M ¾
Establecido en septiembre de 1999
¾ http://www.ietf.org/html.charters/zeroconf-charter.html
Objetivo mínimo: dos ordenadores conectados entre sí
Objetivo mínimo: dos ordenadores conectados entre sí mediante un cable cruzado por Ethernet , han de
comunicarse entre sí bajo IP sin necesidad de intervención comunicarse entre sí bajo IP , sin necesidad de intervención humana, ni servidores DHCP o DNS
¾
AppleTalk actualmente ya hace esto muy bien conectando
¾
AppleTalk actualmente ya hace esto muy bien, conectando simplemente a un hub
Apple con Macs dotados de IEEE 802.11 Airport lo hace de modo inalámbrico
s Ad Hoc
pp e co acs dotados de 80 po t o ace de odo a á b co
¾
Microsoft NETBIOS provee para redes pequeñas un sistema alternativo
alámbricasa
Zero Configuration networking: http:/www.zeroconf.org
009
Zeroconf: áreas de trabajo
MIT 2008/20
Para lograr esta funcionalidad con IP en pequeñas redes se crean cuatro áreas de trabajo principales:
M
cuatro áreas de trabajo principales:
1. Asignar direcciones IP sin un servidor DHCP (con dirección de red, router...)
2. Traducir entre nombres y direcciones IP sin un servidor DNS
3. Descubrir servicios, como por ejemplo impresoras, sin un Servicio de Directorio
4. Asignar direcciones IP multicast sin un servidor MADCAP
¾ MADCAP: Multicast Address Dynamic Client Allocation Protocol-
¾ MADCAP: Multicast Address Dynamic Client Allocation Protocol-
Las soluciones en cualquiera de las cuatro áreas han de coexistir amigablemente con las redes actualmente configuradas g g
¾ Direccionamiento IP tanto de IPv4 como de IPv6
Los protocolos de Zeroconf no tienen que causar perjuicio alguno a
s Ad Hoc
la red, cuando una máquina configurada con Zeroconf sea conectada
a la red actual
¾ Características de seguridad suficientes para prevenir que no sean menos seguros
alámbricas ¾ Características de seguridad suficientes para prevenir que no sean menos seguros
draft ietf zeroconf reqts 12 txt: http:/www zeroconf org
a draft-ietf-zeroconf-reqts-12.txt: http:/www.zeroconf.org
This document was never published by the IETF. Historical interest
009 MIT 2008/20
¾ Unicast Address Autoconfiguration
A t ti fi ti f i IP dd ithi th i hi h
M Automatic configuration of a unique IP address within the scope in which the address will be used.
¾ Multicast Address Autoconfiguration
¾ Multicast Address Autoconfiguration
Allocation of a unique multicast address for the application which needs a new multicast address.
¾ Multicast Name Resolution
Translation between name and IP 6 dd
Unicast Address Autoconfiguration
ny
IPv6 address
¾ Service Discovery
i f h i
Autoconfiguration
Technology Resolutio
n
e Discovery
s Ad Hoc
Discovery of the necessary service on the network without prior
configuration.
Technology
in IPv4,6-based MANET
cast Name
Service
alámbricas Multic
Multicast Address Autoconfiguration
a
009
Zeroconf/asignación de direcciones IP:
escenarios y requerimientos
MIT 2008/20
o y q o
Configuración de la interfaz IP :
¾ Siempre incluye la configuración de una dirección IP y de la máscara de red
M ¾ Siempre incluye la configuración de una dirección IP y de la máscara de red
¾ Puede incluir alguna información de encaminamiento (p.ej., router por defecto)
¾ Es necesario disponer de ella antes que ninguna comunicación se lleve a cabo
Requerimientos:
¾ Ha de configurar una máscara de red apropiada
ó ú
¾ Ha de tener una dirección IP única dentro de una subred
¾ Ha de tener alguna información relativa al encaminamiento para la interred
¾ Ha de tener una subred IP única dentro de la interred si ésta existe
¾ Ha de tener una subred IP única dentro de la interred, si ésta existe
¾ Tiene que resolver conflictos puntualmente ante los cambios de topología
Consideraciones en IPv6
s Ad Hoc ¾ IPv6 permite a un host seleccionar apropiadamente una dirección, una máscara
de red e información de encaminamiento. Así, ya existe una configuración Zeroconf
alámbricas Zeroconf
a
009
estrategias
MIT 2008/20
g
Existen tres estrategias principales:
Conflict detection allocation
M
Conflict-detection allocation
¾ En este esquema los nodos conjeturan una IP (aleatoriamente o utilizando
alguna información de la red) y luego deben utilizar algún método para detectar direcciones duplicadas.
Conflict-free allocation
E t h fli t d di i i l t
¾ En este esquema no hay conflicto de direcciones, ya que se implementan mecanismos que controlan a priori que no pueda existir un solapamiento de las direcciones. Se basan en algoritmos de asignación de enteros para que los
j t di j t
conjuntos sean disjuntos.
Best-effort allocation
¾ Los nodos responsables de la asignación de direcciones intentan asignar
s Ad Hoc
¾ Los nodos responsables de la asignación de direcciones intentan asignar direcciones IP no utilizadas en la medida de la información de que disponen y luego utilizan técnicas de detección de conflictos para los casos en los que haya conflicto
alámbricas conflicto.
S Ahn N Kim W Kim Y Lee A comparison Study of Address Autoconfiguration Schemes for Mobile Ad
a S. Ahn, N. Kim, W. Kim, Y. Lee, A comparison Study of Address Autoconfiguration Schemes for Mobile Ad Hoc Network
009
zeroconf/asignación de direcciones IP:
conflict-detection allocation - Mejoras para el DAD
MIT 2008/20
o o o o jo p
DAD fuerte: (Duplicated Address Detection)
¾ Se refiere a cuando un algoritmo puede garantizar que detectará duplicados
M ¾ Se refiere a cuando un algoritmo puede garantizar que detectará duplicados siempre que se produzcan.
¾ La mayoría de los métodos conflict-detection utilizan time-outs en la
i ió t d l h d ti l DAD l
comunicación entre nodos a la hora de gestionar el DAD, con lo que su
funcionalidad se fundamenta en que en la red las latencias estén acotadas: no se puede garantizar en una MANET
DAD débil:
¾ Será cuando no se puede garantizar el DAD en determinadas circunstancias, pero esto es tolerable para el funcionamiento normal de la red se permite que pero esto es tolerable para el funcionamiento normal de la red. se permite que haya DA pero se debe garantizar que dados dos nodos (A y B) con la misma dirección IP, los paquetes dirigidos al nodo A le acaben llegando sólo a él y lo mismo con el nodo B
s Ad Hoc
mismo con el nodo B.
¾ “Weak Duplicate Address Detection in Mobile Ad Hoc Networks”, Nitin Vaidya, ACM International Symposium on Mobile Ad Hoc Networking and Computing
alámbricas
(MobiHoc), June 2002
K. Weniger: Passive Duplicate Address Detection in Mobile Ad hoc Networks, In Proceedings of IEEE WCNC 2003, New Orleans, USA, Mar. 2003
a Jeong et al. “Ad Hoc IP Address Autoconfiguration” draft-jeong-adhoc-ip-addr-autoconf- 00.txt
009
conflict-free allocation
MIT 2008/20
o o o
“Prophet address allocation for large scale manet” , Zhou, Ni Mutka SIGCOMM 2003
M
Ni, Mutka, SIGCOMM 2003
L f l bl d l fi ió d di i IP
¾ Los autores enfocan el problema de la autoconfiguración de direcciones IP
como el de la asignación de un conjunto de enteros dentro de un rango dado a los distintos nodos de la MANET
Convenientemente realizada la asignación, no tiene porqué haber conflictos.
El nodo inicial sabe a priori que conflictos se pueden producir, pudiendo evitarlos realizando la detección antes de la asignación de direcciones
s Ad Hoc alámbricasa
009
zeroconf/asignación de direcciones IP:
Best effort allocation
MIT 2008/20
o o o
S.Nesargi, R.Prakesh “MANETconf:Configuration of hosts in mobile ad hoc networks”, Proceedings of IEEE INFOCOM 2002
M
, g
Protocolo distribuido, no impide el conflicto de direcciones pero garantiza la no duplicación a costa de:
t h i f ió d t d d
¾ mantener mucha información de estado por nodo
¾ contemplar muchas más posibilidades que el resto de métodos (los otros lo dejan en manos del DAD y de la asignación disjunta).
Independiente del protocolo de routing, del protocolo de acceso al medio y del HW.
Proceso de asignación: interacción entre el nodo que quiere acceder ( requester ) y otro nodo (alcanzable sin dirección IP) ya configurado
s Ad Hoc
( q ) y ( ) y g
( initiator ) que le configurará.
alámbricasa
009 MIT 2008/20
Grado de distribución: los algoritmos tienen que ser lo más distribuidos posibles. No existe un servidor central que pueda realizar el trabajo.
M Complejidad: La complejidad temporal redundará en una mayor latencia a la hora de configurar un nodo. La complejidad espacial en la capacidad de almacenamiento del nodo.
Sobrecarga de la red: si la solución requiere mucha comunicación entre nodos (p.e., mantenimiento de información de estado),
¾ broadcast, etc. y como influirán eventos impredecibles como particiones/fusiones.
Distribución de direcciones equilibrada: interesará que la distribución sea lo más equíprobable posible (respecto al conjunto de direcciones), pues entonces la probabilidad de conflicto será baja, disminuyendo la sobrecarga de tráfico.
Latencia: Entendida como el tiempo que tarda en asignarse una dirección a un nodo.
Escalabilidad: en MANETs, el tamaño puede ser variable e impredecible con un
s Ad Hoc
rango dinámico potencialmente
¾ Además interesarán soluciones donde la mayor parte de la comunicación ocurra localmente pues si se usan broadcast y la red crece mucho la latencia puede disparase
C ió E did l i i i ió d l i d l bilid d (DAD)
alámbricas
Corrección: Entendida como la minimización del tiempo de vulnerabilidad (DAD) esto es los períodos de sombra en los que no se puede garantizar que haya
duplicados.
a
009
Zeroconf: Zero Configuration Networking
MIT 2008/20
Traducir entre nombres y direcciones.
¾ Close DNS coupling
M p g
¾ Multicast DNS
Descubrir servicios
¾ SLP (Service Location Protocol) by IETF srvloc Working Group
¾ SLP (Service Location Protocol) by IETF srvloc Working Group
¾ UPnP (Universal Plug and Play) by Microsoft
¾ Jini by Sun Microsystems
A i di i IP lti t
Asignar direcciones IP multicast
¾ Ejemplo:
¾ O. Catrina et al., “Zeroconf Multicast Address Configuration Protocol (ZMAAP),”
Internet draft, October 2002
Asigna direcciones únicas y se encarga de su gestión
s Ad Hoc
Previene la reasignación de direcciones asignadas
alámbricasa
009 MIT 2008/20
Multicast Service Scenario
M Multicast Service Scenario
1. Unicast Address Autoconfiguration
- Booting of each Mobile Node (MN) Unicast address configuration in NIC
B C D
E A
U i Add - Unicast address configuration in NIC
2. Multicast Address Autoconfiguration
- Run of Video-conferencing Tool
A B C D E
Unicast Address Autoconfiguration
& Creation of a new Session - Allocation of a multicast address
3. Advertisement of Session information
A B C D E
1 2
1 1 1 1
4. Join to the new Session in MN A 5. Join to the new Session in MN E 6 Transmission of Video/Audio data 2 3
4 6
s Ad Hoc
6. Transmission of Video/Audio data by MN A
7. Transmission of Video/Audio data
4 6 5
7
alámbricas
by MN E 7
a
Multicast Address
009
Zeroconf: Propuestas del grupo
MIT 2008/20
La disponibilidad de las tecnologías 802.11 y Bluetooth en la mayoría de los dispositivos actuales ofrece la posibilidad de combinar ambas
M
de los dispositivos actuales ofrece la posibilidad de combinar ambas para sacar el máximo partido a sus capacidades
¾ Proponemos una solución que hace que el proceso inicialización de redes móviles ad-hoc (MANETs) basadas en IEEE 802.11 sea automático usando la tecnología de Bluetooth
tecnología de Bluetooth
¾ ¿Escenarios de aplicación?
s Ad Hoc alámbricas
José Cano Reyes, Eduardo Burgoa, Carlos T. Calafate, Juan-Carlos Cano, Pietro Manzoni, "A MANET autoconfiguration system based on Bluetooth technology", Third IEEE International Symposium on Wireless Communication Systems a (ISWCS), 5-8 of September 2006, Valencia (Spain).
009 MIT 2008/20
¿Por qué Bluetooth?
M ¾
Características:
El concepto de servicios, descubrimiento del dispositivo/servicio
Conexión segura y autenticación
Conexión segura y autenticación
Bajo coste y bajo consumo
Radio de corto alcance
¾
Hemos diseñado un servicio Bluetooth que simplifica las tareas de los usuarios que desean formar una MANET basada en
802.11
Denotamos este servicio como MANET Autoconf
s Ad Hoc
Denotamos este servicio como MANET_Autoconf
alámbricasa
009
Arquitectura
MIT 2008/20
Requerimientos de los terminales
¾ Interfaz Bluetooth Æ para obtener los parámetros de configuración
M p p g
Dirección IP y máscara de subred
Protocolo de encaminamiento (OLSR,AODV,DSR ..)
Parámetros Wi-fi (SSID canal )
Parámetros Wi fi (SSID, canal, ..)
¾ Interfaz 802.11 Æ para permitir a la estación participar activamente en la MANET (compartir información, etc…)
T ti d l t
Tres tipos de elementos
¾ Servidor Bluetooth Æ esperando conexiones Bluetooth entrantes
¾ Clientes Bluetooth Æ esperando ser configurados con los parámetros
¾ Clientes Bluetooth Æ esperando ser configurados con los parámetros adecuados
¾ Miembros de la MANET
s Ad Hoc
Dos redes operando
¾ Bluetooh y 802.11
alámbricasa
009 MIT 2008/20M
802.11 Bluetooth
s Ad Hoc alámbricasa
009
Diagrama de flujo de clientes y servidor
MIT 2008/20Ms Ad Hoc alámbricasa
009 MIT 2008/20
Implementaciones:
M
¾ Windows (gráfica)
Pila de protocolos Bluetooth de Microsoft
Acceso a la pila a traves de librería externa [OpenNETCF]
Plataforma .NET
Lenguaje Visual Basic g j
Para portátil y PDA
¾ Linux (consola y gráfica)
BlueZ (pila de protocolos Bluetooth oficial para sistemas Linux)
BlueZ (pila de protocolos Bluetooth oficial para sistemas Linux)
Solución en modo consola en C
Aplicación gráfica en C++ usando las librerías QT
Sól tátil
s Ad Hoc
Sólo para portátil
alámbricas
[OpenNETCF] , P. Foot, “OpenNETCF Bluetooth Library,” Available at
a http://www.opennetcf.org/, 2005.
009
Aplicación prototipo
MIT 2008/20
Hemos diseñado una aplicación cliente y otra servidor. Ambas ofrecen información sobre el dispositivo local:
M
ofrecen información sobre el dispositivo local:
¾ Dirección MAC
¾ Nombre público
¾ Tipo de dispositivo (portátil, PDA, etc.)
Interfaz del servidor
El servidor permite
¾ Arrancar/parar el servidor
(registrar/deregistrar el servicio)
¾ Cambiar los parámetros de configuración
¾ Controlar el número de dispositivos configurados
s Ad Hoc alámbricasa
009 MIT 2008/20
El cliente permite
M Buscar servicio Conectar
El cliente permite
¾ Buscar dispositivos ofreciendo el servicio MANET_Autoconf
¾ Ajustar el tiempo de descubrimiento
¾ Conectar a un dispositivo para
¾ Conectar a un dispositivo para obtener los parámetros
¾ Ver la terminación de la lista
d t id
de tareas requeridas
s Ad Hoc alámbricas
Interfaz del cliente
a Interfaz del cliente
009
Resultados experimentales
MIT 2008/20
Objetivo principal Æ medir los tiempos relativos a:
M ¾
Descubrimiento de dispositivos (inquiry)
¾
Descubrimiento del servicio (MANET_Autoconf)
¾
Descarga del fichero de configuración
Tiempo de Inquiry
Tiempo de Inquiry
¾
Tarda alrededor de 6.42 segundos de media
s Ad Hoc ¾
El sistema operativo introduce un retardo de unos 20 ms
alámbricas
Ejecución de 100 pruebas independientes
a
009 MIT 2008/20M
1. Proceso de Inquiry + descubrimiento del servicio (“No service”) 2. Proceso de Inquiry + q y
descubrimiento del
servicio + descarga del fichero ((“With service”))
s Ad Hoc
La distancia tiene un gran impacto en el funcionamiento
alámbricas La distancia tiene un gran impacto en el funcionamiento
Los valores al encontrar el servicio son siempre mayores que cuando no lo encuentra
a
009
Resultados experimentales
MIT 2008/20M
Descubrimiento del servicio + descarga del fichero
¾ El número de
dispositivos Bluetooth del entorno aumenta
s Ad Hoc Tiempo de configuración estimado
¾ Si el único dispositivo Bluetooth próximo es el que ofrece el servicio, el proceso termina en
alámbricas
menos de 2 segundos
¾ Si se detectan también otros nodos Bluetooth, el tiempo de la configuración aumentará linealmente con el número de nodos
a
009 MIT 2008/20
Proponemos una solución eficaz para estimular el uso de MANETs confiando en la tecnología Bluetooth
M
confiando en la tecnología Bluetooth.
La arquitectura propuesta hace uso de los servicios Bluetooth, el descubrimiento de dispositivos/servicios etc para hacer el proceso descubrimiento de dispositivos/servicios, etc., para hacer el proceso de configuración del nodo completamente automático.
Evaluamos la arquitectura propuesta en términos del tiempo previsto
q p p p p
de la configuración y su dependencia con la distancia, demostrando que se espera que los usuarios terminen el proceso de integración en
MANET d
una MANET en pocos segundos.
Trabajo Futuro:
ó
s Ad Hoc
¾ Desarrollar una versión de nuestro programa cliente para otros dispositivos y sistemas operativos.
¾ Probar distintos protocolos de encaminamiento.
alámbricas p
¾ Ampliar la aplicación prototipo para crear entornos más elaborados.
a
009
Y ahora Que!
MIT 2008/20
VISUAL DNS
Ms Ad Hoc alámbricasa
