Redes Manet

Tema 4.
Redes inalmbricas Ad Hoc

A. B.
Conceptos generales Encaminamiento i. DSR
C. D.
ii. AODV iii. OLSR Calidad de servicio Control de potencia
agradecimientos/acknowledgments
Nitin H. Vaidya, Tutorial on Mobile Ad Hoc Networks: Routing, MAC and Transport Issues disponible en http://www.crhc.uiuc.edu/wireless/tutorials.html
Redes Inalmbricas y Computacin Ubicua/2006-2007
Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007
Mobile Ad-hoc Networks (MANETs)

Redes formadas por nodos mviles con conexin inalmbrica. No utilizan ninguna infraestructura preexistente
o Existen soluciones hbridas conocidas como redes mesh
En una MANET la movilidad ha un importancia crucial.

o Las rutas varan en el tiempo o Problemas de particionamiento
Porqu las redes ad hoc?

Disponer de infraestructura cableada fija o puntos de acceso no siempre es posible o viable
o No resulta prctico en entornos civiles de carcter temporal o No se dispone o Puede haber sido destruida, por ejemplo en entornos de desastres naturales
Las redes ad hoc

o Se pueden desplegar de forma flexible en entornos que no disponen de infraestructura fija
Un caso ejemplar: Traffic networks

Coches inteligentes y carreteras inteligentes. Los sistemas de abordo hablan con la carreteras. Por ejemplo: FleetNet Internet on the Road. Ad Hoc Radio Network for InterVehicle Communications
o http://www.fleetnet.de
Ofrece:
o Cooperative driver assistance:

Emergency notification Overtaking assistance Obstacle warning
o Decentralized floating car data:

Traffic jam monitor Dynamic navigation Route weather forecast
o User communications and information services:

Hot-spot Internet access Inter-vehicle chat Distributed games
4
Varios tipos
Entorno completamente simtrico
o todos los nodos tiene capacidades y responsabilidades idnticas
Entornos asimtricos; pueden variar:

o Los radios de transmisin o La duracin de las bateras o La capacidad de proceso o Capacidad de encaminamiento o Las tecnologas utilizadas
A menos que est indicado de otra A menos que est indicado de otra manera, se asume implcitamente el manera, se asume implcitamente el entorno completamente simtrico en el entorno completamente simtrico en el que todos los nodos tienen idnticas que todos los nodos tienen idnticas capacidades y responsabilidades capacidades y responsabilidades
Retos de las redes ad hoc

Cmo encaminar paquetes entre estaciones Cmo hacerlo de forma eficiente Otros retos:
o o o o o o Calidad de servicio Configuracin Descubrimiento de servicios Seguridad y privacidad Prestaciones TCP ...
Limitaciones de las redes ad hoc

o relativas al medio inalmbrico
Radio de transmisin limitado (Encaminamiento complejo) Ancho de banda reducido Errores de transmisin/perdidas de paquetes Seguridad restringida
o relativas al carcter mvil de las estaciones

Topologa dinmicas (rutas dinmicas) Energa reducida
6
[Corson99] , S. Corson and J. Macker, Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations, RFC 2501, January 1999.
Visin general
aplicaciones
Middleware
seguridad
MobileIP
IP
MANETs
zeroconf
TCP/UDP TCP
sensores
IEEE 802.11
Bluetooth
Mobile ad hoc networking: imperatives and challenges, Imrich Chlamtac, Marco Conti, Jennifer J.-N. Liu, Ad Hoc Networks, Elsevier, 1 (2003).
Tema 4.Redes inalmbricas Ad Hoc

A. B.
C.
ii. AODV iii. OLSR Calidad de servicio
Routing Overview
Network with nodes, edges Goal: transfer message from one
node to another
o Which is the best path? o Who decides - source or intermediate nodes?
msg
Routing Overview
Which path?
o Generally try to optimize one of the following:
Shortest path (fewest hops) Shortest time (lowest latency) Shortest weighted path (utilize available bandwidth, battery)
Who determines route?

o Source (path) routing [Like airline travel]
Source specifies entire route Intermediate nodes just forward to specified next hop
o Destination (hop-by-hop) routing [Like postal service]

Source specifies only destination in message header Intermediate nodes look at destination in header, consult internal tables to determine appropriate next hop
1 0
MANET Routing Properties

No external network setup: self-configuring Efficient when network topology is dynamic (frequent network changes links break, nodes come and go) Self Starting Adapt to network conditions Qualitative Properties
o Distributed operation o Loop Freedom o Demand Based Operation o Security o Sleep period operation o Unidirectional link support
Quantitative Properties
o End-to-End data throughput o Delays o Route Acquisition time o Out of order delivery (percentage) o Efficiency
1 1
Why is Routing in MANET different ?

Host mobility
o link failure/repair due to mobility may have different characteristics than those due to other causes
Rate of link failure/repair may be high when nodes move fast New performance criteria are used
o route stability despite mobility o energy consumption o host position
Dynamic Solution much more difficult to be deployed
1 2
Tipos de protocolos de encaminamiento

Protocolos proactivos
o Determinan las rutas independientemente del modelo de trfico o Los tradicionales protocolos link-state y distance-vector son proactivos
Protocolos reactivos
o Mantiene las rutas solamente si es necesario
La tercera va: los protocolos hbridos Aspectos a tener en consideracin

o Tiempo de espera para el descubrimiento de la ruta
Los protocolos proactivos normalmente tienen una latencia menor gracias al uso de caches Los protocolos reactivos pueden tener mayor latencia
Una ruta entre A y B es establecida solo si A intenta transmitir a B
o Overhead del descubrimiento y del mantenimiento de la ruta

Los protocolos reactivos pueden tener un overhead menor por que buscan las rutas nicamente cuando es necesario Los protocolos proactivos pueden tener un overhead mayor por que siempre estn actualizando las rutas
1 3
Que solucin adoptar depende del tipo di trafico y del tipo de movilidad!! Que solucin adoptar depende del tipo di trafico y del tipo de movilidad!!
manet Working Group

IETF WG: Mobile Ad-hoc Networks (manet)
o http://www.ietf.org/html.charters/manet-charter.html
Purpose of MANET working group

o standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors.
Approaches are intended to be:

o relatively lightweight in nature o suitable for multiple hardware and wireless environments, and address scenarios o MANETs are deployed at the edges of an IP infrastructure o hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features.
1 4
Description of Working Group

Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications:
o Reactive MANET Protocol (RMP) o Proactive MANET Protocol (PMP)
Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed.
1 5
Goals and Milestones

Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Mar 05 Mar 05 Mar 05 Jun 05 Nov 05 Feb 06 Feb 06 Feb 06 Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues. Agenda bashing, discussion of charter and of mobile ad hoc networking draft. Discuss proposed protocols and issues. Redefine charter. Publish Informational RFC on manet design considerations Review the WG Charter and update Submit AODV specification to IESG for publication as Experimental RFC Develop I-D for potential common manet encapsulation protocol approach Submit initial I-D(s) of candidate proposed routing protocols and design frameworks Promote implementation, revision, and testing of initial proposed I-D(s) Explore basic performance and implementation issues of initial approaches Explore proposed proactive protocol design commonalities Submit DSR specification to IESG for publication as Experimental RFC Submit OLSR specification to IESG for publication as Experimental RFC Submit TBRPF specification to IESG for publication as Experimental RFC Develop a further focused problem statement and address an approach for a common engineering work effort Reevaluate the WG's potential based on the problem statement consensus Submit initial ID of RMP for WG review Submit initial ID of PMP for WG review Submit inital ID of generalized MANET flooding approach Revise WG documents and review Document initial implementation progress and experience Revise documents based upon implementation experience Submit RMP specification and supporting documentation to IESG for publications as Proposed Standard Submit PMP specification and supporting documentation to IESG for publications as Proposed Standard Submit MANET flooding specification to IESG for publication as Experimental Standard Review and update milestones
1 6
Mar 06
Protocolos propuestos
D. Johnson, D. Maltz, and Y-C. Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR), draft-ietf-manet-dsr-10.txt. Internet Draft (work in progress), April 2003. http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. Request for Comments (Experimental) 3561, July 2003. http://www.ietf.org/rfc/rfc3561.txt T. Clausen and P. Jacquet. Optimized Link State Routing Protocol OLSR. Request for Comments (Experimental) 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004. http://www.ietf.org/rfc/rfc3684.txt I. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET On-demand (DYMO) Routing, draft-ietf-manet-dymo-02.txt. Internet Draft (work in progress), June 2005. http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-02.txt T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausenmanet-olsrv2-01. Internet Draft (work in progress), August 2005. http://www.ietf.org/internet-drafts/draft-clausen-manet-olsrv2-01.txt J. Macker. Simplified Multicast Forwarding for MANET, draft-ietf-manet-smf-00.txt. Internet Draft (work in progress), June 2005. http://www.ietf.org/internet-drafts/draftietf-manet-smf-00.txt Y muchos ms:
o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list
1 7
Protocolos propuestos
D. Johnson, D. Maltz, and Y-C. Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR), draft-ietf-manet-dsr-10.txt. Internet Draft (work in progress), April 2003. http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. Request for Comments (Experimental) 3561, July 2003. http://www.ietf.org/rfc/rfc3561.txt T. Clausen and P. Jacquet. Optimized Link State Routing Protocol OLSR. Request for Comments (Experimental) 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004. http://www.ietf.org/rfc/rfc3684.txt I. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET On-demand (DYMO) Routing, draft-ietf-manet-dymo-02.txt. Internet Draft (work in progress), June 2005. http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-02.txt T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausenmanet-olsrv2-01. Internet Draft (work in progress), August 2005. http://www.ietf.org/internet-drafts/draft-clausen-manet-olsrv2-01.txt J. Macker. Simplified Multicast Forwarding for MANET, draft-ietf-manet-smf-00.txt. Internet Draft (work in progress), June 2005. http://www.ietf.org/internet-drafts/draftietf-manet-smf-00.txt Y muchos ms:
o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list
1 8
Uso del flooding para la entrega de datos

Una primera solucin se basa en utilizar flooding controlado
S E B F C J D A H G K N I destino M
nodo que acaba de enviar una trama nodo que acaba de recibir una trama envio broadcast de una trama
1 9

nodo que acaba de enviar una trama nodo que acaba de recibir una trama
Z
envio broadcast de una trama
S E B C A H K N I posible colisin!! G F J D M
2 0

Z
S E B C A H G K N I recibe la trama pero no la reenva por que ya lo ha hecho D F J M
2 1

Z
S E B C A H G K N I recibe la trama de J y de K (entre ellos son hidden) posible colisin D F J M
2 2

Z
S E B C A H G K N I D no reenva por que es el destino final D F J M
2 3

Z
S E B C A H G K N I El flooding ha teminado! El flooding ha teminado! D F J M
2 4

Muchos protocolos utilizan el flooding (limitado) de los paquetes del control, en vez de los paquetes de los datos. Los paquetes de control se utilizan para descubrir las rutas. Las rutas establecidas se utilizan posteriormente para enviar los paquetes de datos. La sobrecarga que se debe al flooding de los paquetes de control se amortiza gracias a los paquetes de los datos transmitidos entre los floodings consecutivos de paquetes del control.
Ventajas Sencillo Es ms eficiente si la tasa de envo es baja el overhead de los procesos de bsqueda y mantenimiento de rutas explicitas resulte ser ms alto
Desventajas Overhead potencialmente muy alto
o en el peor de los casos todos los nodos alcanzable por el nodo fuente recibirn los datos
o Ej.: en el caso que los nodos transmitan pocos mensajes de tamao pequeo y que la topologa vare muy a menudo
Potencialmente la entrega de los datos es ms fiable, por que se pueden utilizar mltiples rutas.
Potencialmente la entrega de los datos es menos fiable a causa del uso de difusiones. ?
o Ej.: las difusiones con el MAC de IEEE 802.11 son pocos fiables
2 5

A. B.
C. D.
Dynamic Source Routing (DSR)

David B. Johnson, David A. Maltz, Yih-Chun Hu, The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks, <draft-ietf-manet-dsr-10.txt> Redes de tamao medio (200 nodos), admite altas velocidades Cuando el nodo S desea enviar un paquete al nodo D, pero no tiene una ruta hacia D, inicia un descubrimiento de la ruta (route discovery). El nodo fuente S hace un flooding de Route Request (RREQ) Cada nodo aade su propio identificador cuando reenva un RREQ. Uso del send buffer Uso de RREQ identifier
2 7
Uso del Route Request en DSR

nodo que acaba de enviar una RREQ nodo que acaba de recibir una RREQ
[X,Y] lista de IDs aadidos al RREQ L
S [S] E B F C J D A H G K N I destino M
2 8

Z
S B C [S,C] A H
E [S,E] L F J G K N I posible colisin!! D M
2 9

Z
S E B C A H G [S,C,G] K N I recibe el RREQ pero no lo reenva por que ya lo ha hecho D F [S,E,F] J M
3 0

Z
S E B C A H G D K[S,C,G,K] N I recibe la trama de J y de K (entre ellos son hidden) posible colisin F J [S,E,F,J] M
3 1

Z
L S E B C A H G K N I D no reenva por que es el destino final D F J M [S,E,F,J,M]
3 2
Uso del Route Reply

En destino D al recibir el primer RREQ enva un Route Reply (RREP) RREP se enva usando la ruta obtenida invirtiendo la que est en el RREQ que se ha recibido
Y
S E B C A H
RREP [S,E,F,J,D]
F J
G K
N I
3 3
Route Reply en DSR

El Route Reply puede ser enviado invirtiendo la ruta en el Route Request (RREQ) solo si tenemos la garanta que los enlaces sean bi-direccionales
o Para garantizarlo el RREQ es reenviado solo si se recibe desde un enlace que sabemos ser bi-direccional
Si se permiten enlaces unidireccionales (asimtricos) entonces el RREP tiene que utilizar un route discovery desde D hacia S
o A menos que D ya tenga una ruta hacia S o Si un route discovery es iniciado por D hacia S, entonces el Route Reply es piggybacked hacia S desde D.
El uso del estndar IEEE 802.11 para enviar datos implica que los canales son bi-direccionales (por que se utilizan los ACKs)
3 4
Dynamic Source Routing (DSR)

Cuando el nodo S recibe el RREP, memoriza en cache la ruta Cuando el nodo S enva un paquete de datos a D, la ruta est incluida en la cabecera
o por eso el nombre de source routing
Los nodos intermedio utilizan solo y nicamente la ruta incluida en la cabecera para saber a quien tienen que reenviar el paquete.
3 5
Data Delivery in DSR

La cabecera de los paquetes va creciendo al aumentar de la longitud de la ruta
Z Y
DATA [S,E,F,J,D]
S E B C A H G K N I D F J M L
3 6
Optimizaciones de DSR: Route Caching (1/2)

Cada nodo guarda en cache todas las rutas que pueda descubrir
1. Cuando el nodo S descubre la ruta [S,E,F,J,D] hacia el nodo D, el nodo S descubre tambin la ruta [S,E,F] hacia el nodo F 2. Cuando el nodo K recibe Route Request [S,C,G] destinado al nodo D, el nodo K descubre la ruta [K,G,C,S] hacia el nodo S 3. Cuando el nodo F retransmite Route Reply RREP [S,E,F,J,D], el nodo F descubre la ruta [F,J,D] hacia el nodo D 4. Cuando el nodo E retransmite Data [S,E,F,J,D] descubre la ruta Y [E,F,J,D] hacia el nodo D
Z S B C A H I G K D N E F J M L
3 7
Optimizaciones de DSR: Route Caching (2/2)

Los nodos, adems pueden descubrir rutas por medio del overhearing Uso de las caches:
o Cuando un nodo X recibe un Route Request para un nodo D y tiene en su cache una ruta hacia ese nodo puede contestar directamente o Cuando el nodo S descubre que una ruta al nodo D est interrumpida, utiliza otra ruta, si existe, de su cache local. Si no, el nodo S comienza un route discovery
Posible problema del uso de las caches:

o en entornos altamente mviles el uso de las caches puede afectar las Y prestaciones
Z S B C A H I G E F M J K D N L
3 8
Route Error (RERR)

J enva un route error a S utilizando la ruta J-F-E-S cuando su intento de entregar el paquete de datos a D falla Los nodos que escuchan el RERR actualizan sus caches Cada nodo es responsable de confirmar que ese enlace se puede utilizar para transmitir datos.
o Ack del MAC (p.ej., 802.11) o Passive acks o DSR-specific ACK

B
Z S L
RERR [J-D] M F J
C A H I G K N D
3 9
Caractersticas adicionales
Tcnica del Expading ring en la bsqueda de rutas utilizando el campo TTL de los paquetes
o non propagating Route Request
Tcnica de Route salvaging en el mantenimiento de las rutas

o Sustitucin dinmica de las rutas por nodos intermedios o El numero de salvamientos es limitado
Tcnica de Automatic route shortening para optimizar las rutas

o Uso de gratuitous Route Reply
Uso de flujos de datos: los flows
4 0
DSR: ventajas y desventajas

Se gestionan solo las rutas entre nodos que quieren comunicarse
El tamao de la cabecera crece al crecer de la ruta debido al uso del source routing El flooding de las peticiones de ruta puede potencialmente alcanzar todos los nodos en la red. Hay que evitar las colisiones producidas por la retransmisin de los RREQ
o se reduce la carga para mantener varias rutas

El uso de la cache puede reducir la carga de futuros procesos de route discovery Un solo proceso de RR puede producir variar rutas hacia el destino gracias a las respuestas de las caches de los nodos intermedios
o se insertan retardos aleatorio antes de enviar el RREQ.

Aumento de la contienda para el acceso al canal si se producen demasiadas RR por nodos que usan sus caches
o Problema de la tormenta de Route Reply. o se puede evitar forzando un nodo a no enviar un RREP si escucha otro RREP con una ruta ms corta
Un nodo intermedio puede corromper las caches de otros nodos enviando RREP utilizando una cache obsoleta
4 1

A. B.
C. D.
Ad Hoc On-Demand Distance Vector Routing (AODV)

Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir Das, Ad hoc On-Demand Distance Vector (AODV) Routing, IETF RFC 3561 El DSR incluye el encaminamiento fuente en la cabecera de los paquetes. Si el tamao de los paquetes resultantes es muy grande puede afectar a las prestaciones, sobre todo si los paquetes de datos son pequeos AODV intenta mejorar DSR utilizando tablas de encaminamiento en los nodos de forma que los paquetes no tengan que llevar informacin sobre de la ruta AODV mantiene la caracterstica del DSR que las rutas son mantenidas solo para los nodos que quieren comunicar
4 3
Distance Vector
Basic Routing Protocol
o known also as Distributed Bellman-Ford or RIP
Every node maintains a routing table

o all available destinations o the next node to reach to destination o the number of hops to reach the destination
Periodically send table to all neighbors to maintain topology Bi-directional links are required!
4 4
Thanks to Raoul Reuter
Distance Vector (Tables)
A
Dest. A B C Next A B B Metric 0 1 3
1
Dest. A B C
B
Next A B C Metric 1 0 2
2
Dest. A B C
C
Next B B C Metric 3 2 0
4 5
Distance Vector (Update)
B broadcasts the new routing information to his neighbors
Routing table is updated
(A, 1) (B, 0) (C, 1)
(A, 1) (B, 0) (C, 1)
A
Dest. A B C Next A B B Metric 0 1 3 2
1
Dest. A B C
B
Next A B C Metric 1 0 1
1
Dest. A B C
C
Next B B C Metric 3 2 1 0
4 6
Distance Vector (New Node)
broadcasts to update tables of C, B, A with new entry for D
(A, 1) (B, 0) (C, 1) (D, 2)
(A, 2) (B, 1) (C, 0) (D, 1)
(D, 0)
A
Dest. A B C D Next A B B B Metric 0 1 2 3 Dest. A B C D A B C C
B
Next Metric 1 0 1 2 Dest. A B C D Next B B C D
C
Metric 2 1 0 1
4 7
Distance Vector
Broken Link and consequent Loops
1 1 1
A
Dest. D Next B Metric 3 Dest.c D C
B
Next Metric 2 Dest. D Next D B
C
Metric 1
(D, 2)
(D, 2)
A
Dest. D Next B Metric 3 Dest. D C
B
Next Metric 2 Dest. D Next B
C
Metric 3
4 8
Distance Vector
create the Count to Infinity problem
(D,5) (D,4) (D,4) (D,3) (D,2) (D,2)
A
Dest. D Next B Metric 3, 5, Dest.c D C
B
Next Metric 2, 4, 6 Dest. D
C
Next B Metric 3, 5,
4 9
Distance Vector
Issues in ad-hoc networks:
o Loops
Bandwidth reduction in network Unnecessary work for loop nodes
o Count to Infinity
Very slow adaptation to topology changes.
5 0
AODV
Los mensajes de Route Requests (RREQ) son reenviados de manera similar a DSR Cuando un nodo retransmite un Route Request, activa tambin una ruta inversa que apunta a la fuente
o AODV supone canales bidireccionales
Cuando el destino recibe el Route Request, responde enviando un Route Reply El Route Reply recorre la ruta activada a travs del envo del Route Request
5 1
Envio del Route Request

Y nodo que acaba de enviar una trama nodo que acaba de recibir una trama envi broadcast de una trama RREQ S E B F C J D A H G K N I destino M L Z
5 2

nodo que acaba de enviar una trama nodo que acaba de recibir una trama Z envi broadcast de una trama RREQ Links de la ruta inversa S E B C A H K N I posible colisin!! G F J D M L Y
5 3

nodo que acaba de enviar una trama nodo que acaba de recibir una trama Z envi broadcast de una trama RREQ Links de la ruta inversa S E B C A H G K N I recibe la trama pero no la reenva por que ya lo ha hecho D F J M L Y
5 4

nodo que acaba de enviar una trama nodo que acaba de recibir una trama Z envi broadcast de una trama RREQ Links de la ruta inversa S E B C A H G K N I recibe la trama de J y de K (entre ellos son hidden) posible colisin D F J M L Y
5 5

nodo que acaba de enviar una trama nodo que acaba de recibir una trama Z envi broadcast de una trama RREQ Links de la ruta inversa S E B C A H G K N I D no reenva por que es el destino final D F J M L Y
5 6
Envio del Route Reply

nodo que acaba de enviar una trama nodo que acaba de recibir una trama Z envi broadcast de una trama RREQ Links de la ruta inversa S E B C A H G K N I D F J M L Y
5 7
Setup del la ruta de envo

Y Los enlaces de la ruta de envo son establecido cuando el mensaje de RREP recorre la ruta inversa
S E B C A H G K N I D F J M
5 8
Route Reply in AODV

Detalles sobre el uso del route reply
o Un nodo intermedio (no el destino final) puede tambin enviar un Route Reply (RREP) si conoce una ruta ms reciente que la que se sabe el sender S o Para determinar se la ruta conocida por un nodo intermedio es ms reciente se utilizan los destination sequence numbers
Si Node:dsn >= RREQ:dsn no reenvio
o La probabilidad que un nodo intermedio enve un Route Reply es inferior en AODV que en DSR
Un Route Request nuevo desde S para un destino se le asigna un destination sequence number ms alto. Un nodo intermedio que conoce la ruta, pero con un numero de secuencia ms pequeo, no puede enviar un Route Reply
Timeouts
o Una entry de una tabla de encaminamiento que esta memorizando un reverse path es cancelada despus de un intervalo de timeout
este intervalo tiene que ser suficientemente largo para que el RREP pueda volver hacia atrs
o Una entry de una tabla de encaminamiento que esta memorizando un forward path es cancelada si no utilizada despus de un intervalo
active_route_timeout 5 9
Notificacin sobre interrupcin de enlaces

Un nodo vecino de X se considera activo para una entry de la tabla de encaminamiento si este vecino ha enviado un paquete dentro de el intervalo active_route_timeout , paquete que ha sido reenviado utilizando esa entry Cuando una una enlace 1-hop in una tabla de encaminamiento se interrumpe, se avisan a todos los vecinos activo Las interrupciones de enlaces se propagan utilizando los mensajes de Route Error, que tambin sirven para actualizar los destination sequence numbers
o cuando un nodo X no puede reenviar un paquete desde S a D sobre el link (X,Y), genera un mensaje RERR o el nodo X incrementa el destination sequence number para D en su cache o este numero, una vez incrementado (=N) es incluido en el RERR o cuando el nodo S recibe el RERR, activa un un nuevo proceso de bsqueda de D utilizando un destination sequence number como mnimo de valor igual a N o cuando el nodo D recibe el route request con destination sequence number N, actualizar su sequence number a N, a menos que no sea ya mayor de N
6 0
Link Failure Detection

Hello messages: Neighboring nodes periodically exchange hello message Absence of hello message is used as an indication of link failure Alternatively, failure to receive several MAC-level acknowledgement may be used as an indication of link failure
6 1
Por que los Sequence Numbers in AODV

Para evitar la presencia de rutas viejas o no validas
o permite determinar cual de las rutas es ms nueva
Para prevenir la formacin de bucles

o Suponiendo que A no sabe nada de la interrupcin del enlace C-D por que el RERR enviado por C se ha perdido
B E
o C efecta un route discovery buscando a D. EL nodo A recibe el RREQ, por ejemplo va la ruta C-E-A o El nodo A contestara por que A conoce una ruta hacia D pasando por B o Obtenemos un bucle, por ejemplo, C-E-A-B-C
A
6 2
B E

A. B.
C. D.
Optimized Link State Routing (OLSR)

Thomas Clausen, Philippe Jacquet, Project Hipercom INRIA, Optimized Link State Routing Protocol, RFC 3626 Protocolo proactivo basado en una optimizacin de los clsicos protocolos link-state, como el OSPF. Adapto para redes donde el trafico es random y espordico entre un gran numero de nodos, y cuando los nodos que intercomunican varan en el tiempo Esta preparado para suportar extensiones, como funcionamiento en sleep mode, routing multicast, etc. No requiere modificar la estructura de los paquetes IP
6 4
LSR vs. OLSR

La sobrecarga de hacer broadcasting de la informacin sobre el estado de los enlaces se reduce limitando el numero de nodos que reenvan esta informacin
Son necesarias 24 retransmisio nes para difundir el mensaje hasta tres salto de distancia
o Una difusin desde el nodo X es reenviada solo por sus multipoint relays o Los multipoint relays del nodo X son sus vecinos escogidos de manera que cada vecino two-hop de X sea un vecino one-hop de por lo menos un multipoint relay de X o Cada nodo transmite su lista de vecinos en mensajes peridicos, de forma que todos los nodos puedan saber cuales son sus vecinos two-hops, para poder escoger sus multipoint relays
nodo que retransmite
Son necesarias 11 retransmisione s para difundir el mensaje hasta tres salto de distancia
6 5
nodo que retransmite
Terminologa
Los nodos pueden tener diferentes interfaces OLSR, cada una con su propia direccin IP
o A cada nodo se le asigna una nica direccin IP de referencia (main address)

neighbor: x es vecino de y si y puede escuchar la seal de x
S
o 2-hop neighbor: un nodo cuya P seal es recibida por un vecino. o strict 2-hop neighbor
multipoint relay (MPR):
M
o Un nodo seleccionado por su vecino x, para retransmitir todos los mensajes de difusin que recibe de x, si no es un mensaje duplicado y si el tiempo de vida es >1
multipoint relay selector (MS)
Z X Y
o Un nodo que ha seleccionado su vecino, x como MPR

6 6
Tablas de encaminamiento
Todos los nodos gestionan una tabla de encaminamiento La estructura es:
1. 2. 3. R_dest_addr R_dest_addr ,, R_next_addr R_next_addr ,, R_dist R_dist ,, R_iface_addr R_iface_addr ,,
Cada entry indica que el nodo R_dest_addr est a R_dist hops de distancia, que el primer salto es a travs de R_next_addr. Este nodo se puede alcanzar por medio del interfaz local R_iface_addr Hay una entry por cada destino en la red La tabla se actualiza cada vez que se detecta una cambio de:
o the link set, o the neighbor set, o the 2-hop neighbor set, o the topology set, o the Multiple Interface Association Information Base,
La tabla se construye aplicando un algoritmo de shortest path

6 7
6 8
Implementaciones

A. B.
C. D.
Performance issues
A lot of work has been done in supporting QoS in the Internet, but unfortunately none of them can be directly used in MANETs because of the bandwidth constraints and dynamic network topology of MANETs. To support QoS, the link state information such as delay, bandwidth, cost, loss rate, and error rate in the network should be available and manageable. However, getting and managing the link state information in MANETs is very difficult because the quality of a wireless link is apt to change with the surrounding circumstances. The resource limitations and the mobility of hosts make things more complicated. Hard QoS guarantee is not possible in MANETs
o Adaptive QoS o Service Differentiation
See, for example:

o Carlos Miguel Tavares Calafate, M.P. Malumbres, Pietro Manzoni, "Performance of H.264 compressed video streams over 802.11b based MANETs", IEEE International Workshop on Wireless Ad Hoc Networking (WWAN 2004), Tokyo, March 2004.
7 0
Effects of congestion and mobility: PSNR
degradation due to mobility Bursty losses Several consecutive frames lost (video freezed) degradation due to congestion Random losses More uniform distortion decay
Video at 10Hz 200 seconds interval

7 1
Effects of congestion and mobility: jitter
Congestion jitter: relatively small frequent variations Mobility jitter: very large peaks occasional occurrences on route change
7 2
Main issues
The main issues to consider to achieve good quality video streaming are:
o MAC level QoS: IEEE 802.11e required to differentiate from bandwidth greedy best-effort traffic o Admission control: to avoid more connections than the MANET can handle o Increase routing effectiveness: even by using layer-2 aware routing protocols such as AODV or DSR, video transmission gaps are still too large to be handled by a video codec o H.264 codec tuning:
avoid high levels of packetization due to channel access overhead Under high levels of packet loss, random updating intra macroblocks is more effective that using I/P frames combinations The use of multiple reference frames proved to be a bad choice
7 3
QoS in MANETs, an integrated vision

QoS Model
o DiffServ o IntServ o FQMM (Flexible QoS Model for Manet QoS Signalling)
QoS Signalling
o INSIGNIA (in-band signalling) o dRSVP(dynamic RSVP)
QoS Routing
o QoS enabled routing (AODV/OLSR) o CEDAR(Core-Extraction Distributed Ad-hoc Routing) o Ticket based Probing (distributed QoS routing)
QoS MAC
o IEEE 802.11e o MACA/PR
(Multiple Access Collision Avoidance with Piggyback Reservation)
o prioritised binary countdown (PBC)
... and
7 4
o SWAN: integrated proposal

Mona Ghassemian, Kings College, September 2003
QoS in QoS in MANETs MANETs
Integrated Services
Attempt to modify Internet service model to support diverse application requirements Any data flow that desires better than best-effort delivery requests and reserves resources at routers along the path
o RSVP is the recommended reservation protocol
If insufficient resources are available, the flow is denied admission into the network Each router
o o o Maintains reservation state for each flow Classifies every packet and decides forwarding behavior Monitors the flow to ensure that it does not consume more than the reserved resources Enables fine-grained QoS and resource guarantees Not scalable, harder to administer
Advantages
o o
7 5
Disadvantages
Differentiated Services
Moves admission control and flow monitoring to the edge of the network Edge nodes classify and mark packets to receive a particular type of service
o o Diff Serv Code Point (DSCP) Finite set of DSCPs defined
Interior nodes determine the type of service for forwarded packets based on their DSCP values Advantages
o o o o More scalable No per-flow state Easier to administer Cannot provide the same per-flow guarantees as IntServ
Disadvantages
7 6
FQMM
FQMM is the first QoS Model proposed in 2000 for MANETs by Xiao et al. The model can be characterized as a hybrid IntServ/DiffServ Model as
o the highest priority is assigned per-flow provisioning. o the rest is assigned per-class provisioning.
Three types of nodes:

o Ingress (transmit) o Core (forward) o Egress (receive)
ingress core
2 1 3
egress
6 5
7 7

QoS Model
QoS Signalling
QoS Routing
o CEDAR(Core-Extraction Distributed Ad-hoc Routing) o QoS enabled routing (AODV/OLSR) o Ticket based Probing (distributed QoS routing)
QoS MAC
... and
7 8

QoS Signalling
Signaling is used to reserve and release resources. Prerequisites of QoS Signalling
o Reliable transfer of signals between routers o Correct Interpretation and activation of the appropriate mechanisms to handle the signal.
Signaling can be divided into In-band and Out-of-band

o In-band: integrated in data packets o Out-of-band: explicit use of control packets
Most papers support that In-band Signaling is more appropriate for MANETs.
7 9
INSIGNIA
INSIGNIA is the first signaling protocol designed solely for MANETs by Ahn et al. 1998.
o Lee, S.B., Ahn, G.S., Campbell, A.T., "Improving UDP and TCP Performance in Mobile Ad Hoc Networks with INSIGNIA", June 2001, IEEE Communication Magazine.
Can be characterized as an In-band RSVP protocol.

o It encapsulates control info in the IP Option field (called now INSIGNIA Option field). o It keeps flow state for the real time (RT) flows. o It is Soft State. The argument is that assurance that resources are released is more important than overhead that anyway exists.
INSIGNA tries to provide something better than best effort service for some flows, e.g., video, voice.
o QoS insensitive flows can be serviced in best effort manner: e-mail o QoS sensitive flows should be treated in better than best effort manner
8 0
INSIGNIA Features
Approach
o Adaptive QoS approach o Service Differentiation via packet prioritization
To provide adaptive QOS it uses:

o Fast Reservation o Fast Restoration o QoS reporting: a feedback mechanism o Adaptation according to network conditions
8 1
Seoung-Bum Lee, COMET Group, Netwokring 2000, Paris
INSIGNIA Principles
In band signaling -> to be responsive
o requires only single packet on new path to initiate the restoration after rerouting o explicit out-of-band signaling is not responsive enough and often fails to reach the target mobile nodes
Soft-state
o for management and maintenance of resource reservations o first packet on new path create states (if necessary) and subsequent packets refresh the previous associated reservations en-route o outstanding reservations and states automatically time out, typically in seconds range.
8 2
INSIGNIA IP option
SERVICE MODE
PAYLOAD BANDWIDTH INDICATOR INDICATOR
BANDWIDTH REQUEST
RES/BE
BQ/EQ
BW_IND
MAX
MIN
1 bit
1 bit
1 bit
16 bits
SERVICE MODE : adaptive (RES) service / best effort service PAYLOAD INDICATOR : base quality (BQ) packet / enhanced quality (EQ) packet BANDWIDTH INDICATOR : reflects the resource availability en route BANDWIDTH REQUEST : indicates the max/min BW requirements
8 3
Reservation Set-up
MS
M2 M1 M4 MD M3
QOS report : MAX reservation established

Packets Received at Destination Mobile Node
RES RES BQ EQ MAX MAX Max_BW Max_BW Min_BW Min_BW Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link
8 4
Re-routing / Restoration
M2
MS
M22 M M1
Rerouting Rerouting
MD M3
M4
immediate restoration
Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link
8 5
Re-routing / Degradation
EQ degradation : degraded to minimum service

M3
MS
M1 M4
M3
MD M5
Rerouting Rerouting bottleneck
node
M5
Packets Received at Destination Mobile Node

RES BE BQ EQ MIN Max_BW Max_BW Min_BW Min_BW
Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link
8 6
Adaptation : Scale Down

Packets sent at Source Mobile Node after Scaling Down to MINIMUM service
RES BE BQ EQ MAX Max_BW Min_BW -
Persistent Persistent EQ degradation EQ degradation
Scale down to MIN service

MS MD M4
M1
bottleneck node
M5
QOS report : :Scale Down QOS report Scale Down

Pkts Received at Destination after Scaling Down to MINIMUM service
RES BE BQ EQ MIN Max_BW Min_BW Legend RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link
8 7
Adaptation : Scale Up
Packets sent by Source Mobile Node in MIN service

RES BQ MAX Max_BW Min_BW
constant resource availability detected
MAX service re-initiated

MS
resource now available
M1 M4
MD
Pkts Received at Destination in MIN service
bottleneck bottleneck node node
M5
QOS report : Scale Up RES BQ MAX
Max_BW Legend
Min_BW
8 8
RES/BQ packet RES/EQ packet BE packet MAX reserved link MIN reserved link

QoS Model
QoS Signalling
QoS Routing
QoS MAC
... and
8 9

QoS Routing
Routing is an essential component for QoS. It can inform a source node of the bandwidth and QoS availability of a destination node We know that AODV is a successful an on-demand routing protocol based on the ideas of both DSDV and DSR. We also know that when a node in AODV desires to send a message to some destination node it initiates a Route Discovery Process (RREQ).
9 0
QoS for AODV

QoS for AODV was proposed in 2000 by C. Perkins and E. Royer. The main idea of making AODV QoS enabled is to add extensions to the route messages (RREQ, RREP). A node that receives a RREQ + QoS Extension must be able to meet the service requirement in order to rebroadcast the RREQ (if not in cache). In order to handle the QoS extensions some changes need to be on the routing tables AODV current fields.
o Destination Sequence Number, Interface, Hop Count, Next Hop, List of Precursors
AODV new fields. (4 new fields)

1. 2. 3. 4. Maximum Delay, Minimum Available Bandwidth, List of Sources Requesting Delay Guarantees and List of Sources Requesting Bandwidth Guarantees
9 1
QoS-sensitive extensions of AODV

QoS information is added to the RREQ packet Intermediate nodes forward the RREQ only if they have sufficient resources to meet the QoS requirement Resource information is updated in the RREQ by intermediate nodes Destination sends resource information back to source in the RREP message
S RREQ RREP
9 2
Other Challenges for QoS Routing and Admission Control
Simultaneous Intersecting Requests
Simultaneous Parallel Requests
P R
Q S
9 3
Problem and Motivation in Hybrid Networks

QoS models for different domains (fixed vs. ad hoc) will not converge in foreseeable future. A model is needed to define interoperability between the two sides (ad hoc and fixed domains). QoS requirements are likely to be more demanding for extranet traffic. Fixed access network
Wireless Ad hoc Intranet Traffic
Wireless Ad hoc
Extranet Traffic
9 4

QoS Model
QoS Signalling
QoS Routing
QoS MAC
... and
9 5


QoS Model
QoS Signalling
QoS Routing
QoS MAC
... and
9 6

9 7
SWAN Model

A. B.
C. D.
Modelo de consumo de energa

Energa consumida por una estacin depende de:
o Consumo del interfaz
Caractersticas del interfaz de red Operacin
o Suministro de energa o Tiempo de transmisin del paquete

Tamao del paquete Ancho de banda
E(p) = i * v * tp
Lucent WaveLAN 2.4 GHz, 11Mbps

o Recepcin 240mA o Transmisin 280mA o V = 5 voltios o tp = (ph/2*106 + pd/11*106)
Ph = tamao cabecera Pd = tamao datos
Etx(p) = 280mA * v * tp Erx(p) = 240mA * v * tp
9 9
Metodologa de evaluacin
J. C. Cano and P. Manzoni, A Performance Comparison of Energy Consumption for Mobile Ad Hoc Networks Routing Protocols,'' Proceedings of the 8th IEEE/ACM MASCOTS 2000, August 2000
Escenario bsico Patrn de escenario 25 estaciones inalmbricas 500m x 500m 15m/s de velocidad mxima Modelo random waypoint Patrn de trfico 20 fuentes CBR 4 paquetes/seg de 512 bytes
Estudio de sensibilidad Parmetros evaluados Patrn de movimiento Patrn de trfico Nmero de estaciones rea de la red
1 0 0
Escenario bsico
El consumo total depende del proceso de recepcin
o Proceso de recepcin=Recibir + Sobre-escucha (overhearing)
DSR reduce el consumo con respecto a DSDV y AODV

Mecanismos de tablas cache
El consumo elevado de TORA

Dependencia con el protocolo IMEP [Corson98]
Energa Tx
100%
Energa Rx
Consumo de Energa (%)
75%
50%
25%
0% DSR AODV DSDV TORA
1 0 1
Impacto del patrn de movimiento

Se varia la velocidad de las estaciones desde 0, 1, 5, 15 hasta 25 metros/seg Resultados:
o El consumo de energa de los protocolos reactivos se incrementa a medida que aumenta la velocidad de las estaciones o El consumo de los protocolos proactivos se mantiene constante
700
DSR AODV DSDV TORA
Consumo de energa (Julios)
600 500 400 300 200 100 0 0 5 10 15 20 25
1 0 2
Velocidad (m/s)
Impacto del nmero de estaciones

Se varia el nmero de estaciones desde 10, 25 hasta 50 estaciones El consumo aumenta con el nmero de estaciones
o Protocolos proactivos intercambio peridico de rutas o Protocolos reactivos procesos de mantenimiento de rutas
3500
DSR
AODV
DSDV
TORA
3000 2500 2000 1500 1000 500 0 10 20 30 40 50
1 0 3
Nmero de estaciones
Impacto del rea de la red

Se varia el rea de la red desde 250mx250m, 250mx500m, 500mx500m y 1000mx500m Los protocolos reactivos incrementan el consumo de energa ms rpido que los protocolos proactivos
1000
DSR
AODV
DSDV
TORA
800
600
400
200
0 250mx250m 500mx250m 500mx500m 1000mx500m
1 0 4
MANET rea
Impacto del trfico de red

Se ha modificado el nmero de fuentes de trfico CBR desde 10, 20 y 30 fuentes Todos los protocolos presentan un comportamiento estable
o Proactivos o Reactivos Rutas actualizadas aprendizaje de rutas
Incrementar el nmero de fuentes CBR es EQUIVALENTE a incrementar la tasa de envo

700
DSR
AODV
DSDV
TORA
600 500 400 300 200 100 0 10 20 30
Nmero de fuentes CBR
1 0 5
Conclusiones
El consumo de energa depende de las operaciones de recepcin de datos Protocolos de encaminamiento:
o Los protocolos reactivos (DSR y AODV) obtienen mejores prestaciones en la mayora de los escenarios considerados o DSR obtiene mejores prestaciones que AODV o En escenarios extremos (velocidad, tamao) se deben considerar aproximaciones proactivas
1 0 6

Aspectos relacionados: o Configuracin cero
zeroconf: Zero Configuration Networking o movilidad a nivel de red: mobileIP o Whats new?
zeroconf: Zero Configuration Networking

ZEROCONF: Grupo de trabajo del IETF
o Establecido en septiembre de 1999
o http://www.ietf.org/html.charters/zeroconf-charter.html
Objetivo mnimo: dos ordenadores conectados entre s mediante un cable cruzado por Ethernet, han de comunicarse entre s bajo IP, sin necesidad de intervencin humana, ni servidores DHCP o DNS
o 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 inalmbrico
o Microsoft NETBIOS provee para redes pequeas un sistema alternativo
1 0 8
zeroconf: reas de trabajo

Para lograr esta funcionalidad con IP en pequeas redes se crean cuatro reas de trabajo principales:
1. Asignar direcciones IP sin un servidor DHCP (con direccin 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
Las soluciones en cualquiera de las cuatro reas han de coexistir amigablemente con las redes actualmente configuradas
o Direccionamiento IP tanto de IPv4 como de IPv6
Los protocolos de Zeroconf no tienen que causar perjuicio alguno a la red, cuando una mquina configurada con Zeroconf sea conectada a la red actual
o Caractersticas de seguridad suficientes para prevenir que no sean menos seguros
1 0 9
zeroconf: objetivos
Las funciones habrn de ser definidas para dos topologas de red distintas
o Un segmento de red simple, donde los hosts son accesibles a travs de la capa de enlace mediante broadcasting o mensajes multicast o Un conjunto de segmentos de redes (en distintas subredes IP) interconectadas mediante un simple router
La configuracin automtica de una topologa arbitraria de routers y subredes queda fuera del mbito del grupo de trabajo
Definir cmo una red puede automticamente realizar una transicin desde el comportamiento de configurada a desconfigurada y viceversa
o Los mismos hosts han de ser capaces de funcionar en redes sin configuracin, as como con conectividad directa IP hacia Internet, incluyendo servicios DNS, etc. o Tambin ser posible que ambos modos (Zeroconf y administrado) puedan coexistir en la misma red, sin ser dichos modos mutuamente excluyentes
1 1 0
Simplicidad y facilidad de uso (la escalabilidad no debera ser un objetivo primordial del grupo de trabajo)
zeroconf: requerimientos
Protocolos TCP/IP inaceptables en redes emergentes
o o o o DNS DHCP LDAP MADCAP Protocol RFC 1034 y 1035 Domain Name Service RFC 2131 Dynamic Host Configuration Protocol RFC 2251 Lightweight Directory Access Protocol RFC 2730 Multicast Address Dynamic Client Allocation
Coexistencia y escalabilidad
o No es necesario usar Zeroconf simultneamente en las cuatro reas o La escalabilidad es importante pero no es un objetivo primordial
Requerimiento del protocolo de encaminamiento

o Protocolos que pretendan alcanzar un intervalo de subredes IP no deberan usar difusin o direccionamiento de enlace local
Requerimiento de conflictos y cambios de estado

o Tiene que responder a los cambios de estado y resolver conflictos de una manera puntual, ante los cambios de topologa u otros eventos como la aparicin o desaparicin de hosts (aplicable a todas las reas de protocolo)
1 1 1
zeroconf: consideraciones de seguridad

El principal avance de los protocolos Zeroconf es proveer configuracin de la red, all donde los servicios de configuracin no estn disponibles. Esto es ventajoso con operaciones seguras, pues los mecanismos de seguridad requieren generalmente alguna preconfiguracin (claves, certificados, etc.) Normalmente, los mecanismos de seguridad en protocolos IETF son de implementacin obligatoria, aunque una implementacin particular quiz puede permitir a un administrador desactivar operacionalmente un mecanismo de seguridad. En cualquier caso, las implementaciones han de ser seguras fuera de la caja y han de configurarse seguras por defecto Los protocolos Zeroconf no pueden ser menos seguros que los protocolos actualmente relacionados del IETF estndar Las amenazas a considerar incluyen ataques activos (v.g. denegacin de servicio) como ataques pasivos (escuchas a travs de la red), y los protocolos que requieren confidencialidad y/o integridad deben resolverse mediante integracin o usando los mecanismos estndar de seguridad
1 1 2

zeroconf: Zero Configuration Networking o Asignar direcciones IP
o Asignar direcciones IP multicast o Descubrir servicios
zeroconf/asignacin de direcciones IP: escenarios y requerimientos

Configuracin de la interfaz IP:
o Siempre incluye la configuracin de una direccin IP y de la mscara de red o Puede incluir alguna informacin de encaminamiento (p.ej., router por defecto) o Es necesario disponer de ella antes que ninguna comunicacin se lleve a cabo
Requerimientos:
o Ha de configurar una mscara de red apropiada o Ha de tener una direccin IP nica dentro de una subred o Ha de tener alguna informacin relativa al encaminamiento para la interred o Ha de tener una subred IP nica dentro de la interred, si sta existe o Tiene que resolver conflictos puntualmente ante los cambios de topologa
Consideraciones en IPv6
1 1 4
o IPv6 permite a un host seleccionar apropiadamente una direccin, una mscara de red e informacin de encaminamiento. As, ya existe una configuracin Zeroconf
zeroconf/asignacin de direcciones IP: estrategias

Existen tres estrategias principales: Conflict-detection allocation
o En este esquema los nodos conjeturan una IP (aleatoriamente o utilizando alguna informacin de la red) y luego deben utilizar algn mtodo para detectar direcciones duplicadas.
Conflict-free allocation
o 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 asignamiento de enteros para que los conjuntos sean disjuntos.
Best-effort allocation
o Los nodos responsables de la asignacin de direcciones intentan asignar direcciones IP no utilizadas en la medida de la informacin de que disponen y luego utilizan tcnicas de deteccin de conflictos para los casos en los que haya conflicto.
1 1 5
zeroconf/asignacin de direcciones IP: conflict-detection allocation - PWMRS

PWMRS
o C.E. Perkins, J.T. Malinen, R. Wakikawa, E.M. Belding-Royer, and Y. Sun, IP Address Autoconfiguration for Ad Hoc Networks, draftietfmanet-autoconf-01.txt, Internet Engineering Task Force, MANET Working Group, July 2000.
est limitado a protocolos reactivos de routing tiene altas latencias no soluciona la configuracin concurrente de varios nodos no contempla fusiones/particiones
Se utilizan direcciones de clase B con prefijo 169.254 / 16(IPv4) tiene extensiones para soportar IPv6. El nodo que intenta obtener una direccin IP utiliza inicialmente una temporal(para comunicarse con el resto) dentro del rango 0-2047, seleccionndola aleatoriamente. Elige otra, dentro del rango 2048-65534, como direccin tentativa.
1 1 6
zeroconf/asignacin de direcciones IP: conflict-detection allocation - PWMRS

El nodo enva un Address Request (AREQ) por broadcast a sus vecinos y arranca un temporizador.
o El AREQ contiene la direccin temporal y la tentativa.
Cuando un nodo recibe un AREQ comprueba que no coincida con su IP la direccin tentativa.
o Si no coincide reenva el mensaje a sus vecinos (broadcast) lo mismo hace con los AREP que no son para l. o Si coincide enva (por broadcast) un Address Reply (AREP).
Cuando un nodo enva AREQ espera AREP hasta que venza el time-out. Si es as repite el proceso AREQ_TIMES
o si no hay contestacin se queda la IP, considerndose configurado. o si el nodo recibe AREP, vuelve a iniciar el proceso con otra direccin.
La tcnica tambin puede utilizarse con Ipv6, con pequeas modificaciones. S.Cheshire IPv4 Address Conflict Detection draft-cheshire-ipv4acd-03.txt propone un mecanismo similar y para la resolucin de conflictos usa ARP.
1 1 7
zeroconf/asignacin de direcciones IP: conflict-detection allocation - Mejoras para el DAD

DAD fuerte:
o se refiere a cuando un algoritmo puede garantizar que detectar duplicados siempre que se produzcan. o La mayora de los mtodos conflict-detection utilizan time-outs en la comunicacin entre nodos a la hora de gestionar el DAD, con lo que su funcionalidad se fundamenta en que en la red las latencias estn acotadas: no se puede garantizar en una MANET
DAD dbil:
o 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 haya DA pero se debe garantizar que dados dos nodos (A y B) con la misma direccin IP, los paquetes dirigidos al nodo A le acaben llegando slo a l y lo mismo con el nodo B. o Weak Duplicate Address Detection in Mobile Ad Hoc Networks, Nitin Vaidya, ACM International Symposium on Mobile Ad Hoc Networking and Computing (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 Jeong et al. Ad Hoc IP Address Autoconfiguration draft-jeong-adhoc-ipaddr-autoconf-00.txt
1 1 8
zeroconf/asignacin de direcciones IP: conflict-detection allocation DAD dbil

La idea del mtodo es asociar un identificador (key) a cada nodo para poder detectar duplicados. Por ejemplo: aumentar la tabla LSR y los paquetes poniendo otra entrada donde se recoja el key de los nodos.
o De esta forma puede haber direcciones duplicadas pero los nodos saben para quin son los paquetes,consiguindose el objetivo de DAD dbil. o Para cada mensaje route_request, los nodos implicados debern aadir su par (IP,key). Lo mismo deber ocurrir en otros mensajes de descubrimiento de red como route_reply o route_error. o Se debern aadir nmeros de secuencia a los pares (IP,key).
1 1 9
zeroconf/asignacin de direcciones IP: conflict-free allocation

Prophet address allocation for large scale manet , Zhou, Ni, Mutka, SIGCOMM 2003
1 2 0
zeroconf/asignacin de direcciones IP: conflict-free allocation

Los autores enfocan el problema de la autoconfiguracin de direcciones IP como el de la asignacin de un conjunto de enteros dentro de un rango dado a los distintos nodos de la MANET
o Convenientemente realizada la asignacin, no tiene porqu haber conflictos. o El nodo inicial sabe a priori que conflictos se pueden producir, pudiendo evitarlos realizando la deteccin antes de la asignacin de direcciones
1 2 1
zeroconf/asignacin de direcciones IP: conflict-free allocation - Prophet

Ejemplo de funcionamiento:
o R[1,8] o f(n)=(address x state x11) mod 7 o cada nodo tiene asociado: (address, state of f(n)).
Cuando la red se inicia slo est A. Elige aleatoriamente el nmero 3 como direccin IP y como semilla para f(n). Cuando B intenta unirse, A calcula f(3)=(3 x 3 x11) mod 7=1 y se lo pasa a B como direccin IP y semilla. Adems actualiza su semilla con ese valor. Posteriormente C se aproxima a A y D a B. Cada uno calcula los valores independientemente (pero compartiendo semilla) de forma que
o para C: f(n)=f(1)=(3 x 1 x 11) mod 7=5 IP C=5 y el estado de A y C=5. o para B: f(n)=f(1)=( 1 x 1 x 11) mod 7=4 IP D=4 y el estado de B y D=4.
1 2 2
zeroconf/asignacin de direcciones IP: conflict-free allocation - Prophet eleccin de f(n)

Si R es suficientemente grande y f(n) est convenientemente diseada, se puede garantizar que las secuencias obtenidas satisfacen:
1. El intervalo entre la repeticin de dos nmeros en la secuencia es extremadamente largo. 2. La probabilidad de la ocurrencia de un mismo nmero en diferentes secuencias iniciadas con diferentes semillas es extremadamente baja(necesario para redes que se configuren independientemente y luego se fusionen).
Los autores proponen una solucin aproximada basada en la descomposicin en factores primos. Cualquier nmero puede representarse nicamente por:
De forma que si las tuplas (e1,e2,...,ek) tiene diferentes ei(i=1,...,k) habr diferentes n( y por lo tanto no conflicto en direcciones).
1 2 3
zeroconf/asignacin de direcciones IP: best effort allocation

S.Nesargi, R.Prakesh MANETconf:Configuration of hosts in mobile ad hoc networks, Proceedings of IEEE INFOCOM 2002 Protocolo distribuido, no impide el conflicto de direcciones pero garantiza la no duplicacin a costa de:
o mantener mucha informacin de estado por nodo o contemplar muchas ms posibilidades que el resto de mtodos (los otros lo dejan en manos del DAD y de la asignacin disjunta).
Independiente del protocolo de routing, del protocolo de acceso al medio y del HW. Todo el mecanismo est dirigido por el proceso de asignacin de direcciones, que es utilizado por los nodos para actualizar su informacin de estado de la red, detectar particiones/fusiones, cadas de nodos,.... Proceso de asignacin: interaccin entre el nodo que quiere acceder (requester) y otro nodo (alcanzable sin direccin IP) ya configurado (initiator) que le configurar.
1 2 4
zeroconf/asignacin de direcciones IP: Mtricas para la evaluacin

Grado de distribucin: los algoritmos tienen que ser lo ms distribuidos posibles. No existe un servidor central que pueda realizar el trabajo. 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 solucin requiere mucha comunicacin entre nodos (p.e., mantenimiento de informacin de estado),
o broadcast, etc. y como influirn eventos impredecibles como particiones/fusiones.
Distribucin de direcciones equilibrada: interesar que la distribucin sea lo ms aquprobable posible (respecto al conjunto de direcciones), pues entonces la probabilidad de conflicto ser baja, disminuyendo la sobrecarga de trfico. Latencia: Entendida como el tiempo que tarda en asignarse una direccin a un nodo. Escalabilidad: en MANETs, el tamao puede ser variable e impredecible con un rango dinmico potencialmente
o Adems interesarn soluciones donde la mayor parte de la comunicacin ocurra localmente pues si se usan broadcast y la red crece mucho la latencia puede disparase
1 2 5
Correccin: Entendida como la minimizacin del tiempo de vulnerabilidad (DAD) esto es los perodos de sombra en los que no se puede garantizar que haya duplicados.

zeroconf/asignacin de direcciones IP multicast escenarios y requerimientos

Rango en IPv4 de 224.0.0.0 a 239.255.255.255. mbitos segn RFC 2365
o Nodo local y punto local No especificados para IPv4 o Enlace local 224.0.0.0/24 o Local 239.255.0.0/16 o Organizacin local 239.192.0.0/14 o Global 224.0.1.0 a 238.255.255.255 o Una asignacin relativa equivale a un desplazamiento entero desde la direccin ms alta representada en 32 bits. As, 239.255.255.0/24 se reserva en el mbito local o Las direcciones Source-Specific Multicast (SSM) son: 232.0.0.0 a 232.255.255.255
1 2 7
El nodo local y las direcciones SSM no requieren protocolo o interaccin entre mltiples hosts Los mbitos global y de organizacin local se entienden para redes de mayor escala que los protocolos Zeroconf Los paquetes multicast deben restringir su alcance lmite, y suponemos que un router en la frontera es un boundary router como se describe en RFC 2365
zeroconf/asignacin de direcciones IP multicast escenarios y requerimientos

Asignacin de direcciones
o Hay que ser coherente desde la eleccin y la coordinacin hasta la reutilizacin o Requerimientos
Tiene que seleccionar una direccin multicast Ha de prevenir conflictos de asignacin de la misma direccin Tiene que permitir la liberacin de una direccin cuando no est ms en uso
Fuente mltiple
o Un sistema de intercomunicacin en el hogar es un ejemplo de aplicacin con mltiples fuentes de IP multicast, pues diversos orgenes pueden estar enviando paquetes destinados a la misma direccin IP multicast o El problema se presenta cuando una direccin puede continuar siendo vlida an despus de que el host que inici la asignacin haya desaparecido del grupo, es decir haya cado o simplemente abandonado el grupo multicast o Requerimiento: Un host distinto del que asigna las direcciones tiene que defender el mantenimiento de la asignacin de una direccin multicast
O. Catrina et al., Zeroconf Multicast Address Configuration Protocol (ZMAAP), Internet draft, October 2002
1 2 8
o Asigna direcciones nicas y se encarga de su gestin o Previene la reasignacin de direcciones asignadas

Escenarios y requerimientos
Servicio de descubrimiento
o Los protocolos de este servicio permiten a los usuarios seleccionar servicios y/o hosts por un nombre que es descubierto dinmicamente, mucho mejor que por un nombre y tipo que el usuario debiera conocer anticipadamente o Servicio de impresora
Las impresoras de red permiten enviar a diferentes clientes trabajos de impresin. Hay que averiguar sus caractersticas (localizacin, resolucin, estado, color, etc.) sin protocolos particulares de impresin Requerimientos
Tiene que permitir que un servicio sea descubierto Tiene que descubrir a travs de un identificador y/o tipo de servicio Ha de descubrir servicios sin usar ningn protocolo especfico de servicios Deber descubrir caractersticas del propio servicio Tiene que completar el servicio puntualmente (dcimas de segundo)
o Consideraciones en IPv6
Los protocolos de este servicio no tienen diferencias relacionadas con ZeroConf
Service Discovery Protocols (SDPs)

o SLP (Service Location Protocol) by IETF srvloc Working Group o UPnP (Universal Plug and Play) by Microsoft o Jini by Sun Microsystems
1 3 0
Service Location Protocol

Main components
o User Agent (UA)
discovers services that the devices they represent are requesting
o Service Agent (SA)

advertises the services they represent
o Directory Agent (DA)

accumulates service information from SA responds to service requests from UA
Implementation
o with a DA o without a DA
1 3 1
Service Location Protocol (cont.) With a DA
UA
DA
st SrvRq DAAdver t
SA
service:da
service:da: //129.187.222.102 service:printer color=true
ert AAdv D
service:da://129.187.222.102
SrvReg
Sr v Ac k
SrvRq
st
service:printer: //129.187.222.134 color=true, postscript=true,
ly SrvRp
service:printer: //129.187.222.134
AttrRq
st
ly AttrRp
color=true, postscript=true,
1 3 2
Service Location Protocol (cont.) Without a DA
UA
service:da
SA
SrvRq st
service:da: //129.187.222.102 service:printer color=true
er t AAdv S
SrvRq
st
ly SrvRp
service:printer: //129.187.222.134
AttrRq
st
ly AttrRp
color=true, postscript=true,
1 3 3
Universal Plug and Play

What is universal about UPnP? There are no device drivers UPnP networking is media independent UPnP devices can be implemented using any programming language, and on any operational system (SOAP) Major components
o device (logical device)
contains one or more services and/or devices
o service (logical functional unit)

exposes actions and models the state of a physical device with state variables
o control point
searches for devices (services)
1 3 4
Universal Plug and Play Networking

Step 1. Discovery Step 2. Description Step 3. Control Step 4. Eventing Step 5. Presentation
1 3 5
Universal Plug and Play Step 1. Discovery
multicast
control point 1 control point 2
advertise
device 2 service 1
advertise service 2 multicast
search
device 1 service 1
control point 3
response (unicast) service 2

1 3 6
Universal Plug and Play Step 2. Description
control point
UPnP description request
device
UPnP description for device service 1 UPnP description request
UPnP description for service
service 2
1 3 7
Universal Plug and Play Step 3. Control
control point
action request
device
service
result
query variable variable value
1 3 8
Universal Plug and Play Step 4. Eventing
control point
subscriber SID=uuid:1
device 1
subscription request subscription (uuid:1) renewal request subscription (uuid:1)
service 1
publisher
event message
cancellation (uuid:1)
control point
Subscriber SID=uuid:2
event message
1 3 9
Universal Plug and Play Step 5. Presentation
browser
presentation request presentation page
device service
control and/or status
1 4 0
Jini Main Aspects

service
o devices (printers, displays, disks) o software (applications, utilities) o information (databases, files) o users of the system
lookup service
o maps interfaces indicating service functionality to sets of objects implementing the service
RMI (Java Remote Invocation Method)
1 4 1
Jini Main Aspects (cont.)

service proxy object
o can be a complete implementation of a service o once a service is located, its proxy object will be uploaded by lookup service o client object contacts lookup service to download the proxy object
events
o objects register with other objects to get notifications o when services join or leave, events are signaled
1 4 2
Jini Discovery
A service provider seeks a lookup service.
lookup service
client
service provider
service object service attributes
1 4 3
Jini Join
A service provider registers a service object (proxy) and its service attributes with the lookup service.
lookup service
client
service provider
1 4 4
Jini Lookup
A client requests a service. A service object copy is moved to the client and used by the client to talk to the service.
lookup service
client
service provider
service attributes
1 4 5
Jini Client Uses Service

The client interacts directly with the service provider via the service proxy object.
lookup service
client
service provider
service attributes
1 4 6

mobileIP
IETF mobileip (IP Routing for Wireless/Mobile Hosts) working group
o http://www.ietf.org/html.charters/mobileip-charter.html
Referencias:
o C. Perkins, IP Mobility Support, RFC2002 o J. Solomon et al., Mobile-IPv4 Configuration Option for PPP IPCP, RFC2290 o Charles E. Perkins, Mobile IP: design principles and practices, Addison-Wesley Wireless Communications Series, October 1997
1 4 8
El problema
Esquema de direccionamiento de IP Identificadores de conexiones TCP/UDP
<129.34.16.43, sh port #, 128.8.128.45, mh_port #>
subnet A Internet
subnet B
Clase A
red Red
Host
1.0.0.0 .. 126.0.0.0
subnet C
Clase B
10
red Red
Host
128.0.0.0 .. 191.255.0.0
Clase C
110
Red
192.0.0.0 .. 223.255.255.0
Host
Clase D
1110
direccin multicast
224.0.0.0 239.255.255.255
1 4 9
1 5 0
Un agente en la red origen
Internet
nodo IP
4 Un agente en la red actual 3
La solucin
Arquitectura
HA
Internet subnet A subnet B
Mobile node (MN) Mobile node (MN)
o nodo que cambia su punto de o nodo que cambia su punto de conexin de una subred a otra conexin de una subred a otra
Home agent (HA) Home agent (HA)
HA
subnet C
o router en la subred home del o router en la subred home del MN que se encarga del tunneling MN que se encarga del tunneling de los datos hacia el MN de los datos hacia el MN o router en la subred actual o router en la subred actual (visitada) del MN que se encarga (visitada) del MN que se encarga del reenvo de los paquetes hacia del reenvo de los paquetes hacia el MN el MN
Foreign agent (FA) Foreign agent (FA)
1 5 1
Servicios de MobileIP
HA
Internet subnet A subnet B
Agent discovery Agent discovery
o los HA yylos FA hacen publica su o los HA los FA hacen publica su presencia en cada subred (o presencia en cada subred (o segmento de subred) en el que segmento de subred) en el que quieran proveer el servicio quieran proveer el servicio
Registration Registration
subnet C
o establecimiento de una o establecimiento de una conexin entre un FA o el HA yy conexin entre un FA o el HA un MN un MN

Tunneling Tunneling
o reenvo de los datagramas al MN o reenvo de los datagramas al MN por parte del HA por parte del HA
1 5 2
Esquema de funcionamiento de mobileIP

HA
agent discovery
agent adv msg agent disc msg
reg. request reg. request
registration
reg. accept/deny reg. accept/deny
tunnelling
1 5 3
Direccionamiento en dos niveles
subnet A: 132.4.16.
Internet subnet B
subnet C 128.8.128.
direccin de localizacin
128.8.128.Y
132.4.16.Z
1 5 4
direccin esttica
1 5 5
Home agent
Internet
nodo IP
Triangle routing
Foreign agent 3
Deteccin de movimiento
Problema: como establezco que un nodo ha cambiado de subred?
Lazy Cell Switching (LCS) (conmuta con lnea AZUL) Eager Cell Switching (ECS) (conmuta con lnea ROJA) Prefix comparison (conmuta con lnea ROJA) (requiere mas subredes) Notificacin por el nivel de enlace (incluyendo parmetros como la potencia de la seal, etc.) Las prestaciones de estas tcnicas dependes del patrn de movilidad, de la frecuencia de los advertisement LCS con potencia de las seal pude ser mejor que ECS
1 5 6
Lazy Cell Switching (LCS)

Movement detection with LCS is based on the lifetime field within the main body of the ICMP Router Advertisement portion of the agent advertisement A mobile node should, effectively, expire each advertisement at the end of its lifetime If the mobile node fails to receive another advertisement from the same agent within the specified lifetime, it should assume that it has lost contact with that agent. If the mobile node has previously received an agent advertisement from another agent for which the lifetime has not yet expired, the mobile node may immediately attempt registration with that other agent.
o Otherwise, the mobile node should attempt to discover a new agent with which to register, perhaps by broadcasting an agent solicitation
1 5 7
Eager Cell Switching (ECS)

A basic assumption about the mobility patterns of nomadic users
o movement is considered most likely to proceed along fairly straight lines o a mobile computer, once it first enters a new wireless cell, will usually continue to proceed further into that new cell and, by implication, further along the way out of its previous cell
Mobile computer switches right away to any new care-of address that might be available within the new cell Mobile nodes can switch to new care-of addresses without any interruption in connectivity to the Internet A list of current foreign agents must be maintained
o if a mobile node actually resides within range of two different foreign agents and is receiving beacons from both of them, the mobile node has to remember which was the most recently detected foreign agent and remain attached to that most recent one
1 5 8
Prefix Matching
Movement detection with prefix matching uses network prefixes If the prefixes differ, the mobile node may assume that it has moved If the prefix-matching method shows that the mobile node has moved, then a mobile node may choose instead to register with a foreign agent advertising a different network prefix, rather than reregister with its current care-of address The prefix-length extension may be used in some cases by a mobile node to determine whether a newly received agent advertisement was received on the same subnet as the mobile node's current careof address
1 5 9

IETF 65 MANET WG Minutes

Proceedings of the Sixty-Fifth Internet Engineering Task Force
o Dallas, TX, USA - March 19-24, 2006
The Sixty-Sixth IETF meeting will be held 9-14 July 2006.
o Summary: All the MANET Internet drafts (DYMO, OLSRv2, and SMF) were updated since Vancouver. They are moving along nicely. The biggest news is continued convergence. We now have a common MANET packet/message format (packetbb). DYMO, OLSRv2, and SMF have been modified to use the packetbb format. We have also agreed to carve out (from OLSRv2) a common MANET neighborhood discovery protocol (still unnamed).
Generalized Packet and Message Format

o draft-ietf-manet-packetbb-00.txt
DYMO
o draft-ietf-manet-dymo-04.txt
OLSR v2
o draft-ietf-manet-olsrv2-01.txt
SMF
o draft-ietf-manet-smf-02.txt
1 6 1
OSPF-MANET
MANET packet format

The framework consists of a specification of:
o a mechanism whereby new message types can be specified and (regardless of type, whether known or unknown) can still be correctly parsed and forwarded; o a generalized multi-message packet format, in which the header information contains the necessary information to allow single and multihop diffusion in MANETs, whilst also permitting unicast and multicast use of the format; o a mechanism whereby addresses can be represented in a compact way (address compression); o an extensibility mechanism whereby arbitrary attributes, through TLVs (type-length-value triplets), can be included and associated with a message, an address or a set of addresses, while being correctly parseable by a generic message parser.
1 6 2
DYMO
DYMO Reactive Protocol like AODV, but with path accumulation feature
I1
I2
I3
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Len | TTL |I|A| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TargetAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | THopCnt |Res|
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| RBPrefix |Res| RBHopCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . RBNodeAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBNodeSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RREQ RREQ RE-S RREQ RE-S RE-I1 RREQ RE-S RE-I1 RE-I2 RREQ RE-S RE-I1 RE-I2 RE-I3
RREP
RE-S Route Element with NL of S RERE-I1 Route Element with NL of I1 RE-
1 6 3
DYMO Route Maintenance

Avoid expiring good routes
o Update reverse route lifetime on data reception o Update forward route lifetime on data transmission
Inform sources of broken routes quickly

o Active links must be monitored
Several mechanisms available
Route Error (RERR) Optional additional invalid routes
1 6 4
DYMO vs AODV
Respuestas de Ian Chakeres a la pregunta: could you briefly explain what are the differences between DYMO and AODV
o 8 Mar 2005
There are several differences between AODV, AODV-bis, DSR and DYMO. To list just a few.
New packet format. Generic packet handling. Unsupported element handling. Optional path accumulation. Much more.
o 23 Mar 2006
DYMO is a simpler version of AODV. DYMO is easier to implement and has lower requirements (in terms of memory, code, etc.) than AODV. DYMO is close to what has been implemented for sensor networks, such as tinyAODV. AODV is no longer being explored in the MANET WG.
1 6 5
OLSR v2
The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of linkstate information. A secondary optimization is, that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse linkstate advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
1 6 6
Proactive QoS Routing: QOLSR

Optimized Link State Routing[RFC3626] Aiming at large and dense MANETs with lower mobility Only selected nodes as multi-point relays (MPRs) forwards broadcasting messages to reduce overhead of flooding MPR nodes periodically broadcast its selector list QoS extensions
o QOLSR[IETF Draft]: Hello messages and routing tables are extended with parameters of maximum delay and minimum bandwidth, and maybe more QoS parameters
Advantage: ease of integration in Internet infrastructure Disadvantages: Overhead to keep tables up to date
1 6 7
Black nodes: MPRs
http://www.ietf.org/internet-drafts/draft-badis-manet-qolsr-03.txt
SMF for MANET

Progress has been made in developing and implementing more efficient ways to flood control packets within MANET routing protocol. The main purpose of the Simplified Multicast Forwarding (SMF) framework is to adapt efficient flooding designs in MANET environments and apply these mechanisms to IP multicast packet forwarding. When efficient flooding is a sufficient technique, SMF can make multicast forwarding available to data flows within a MANET area. The SMF baseline design limits the scope to basic, best effort multicast forwarding and its applicability is intended to be constrained within a MANET area.
1 6 8
Hot Topics
reas de inters del MobiHoc 2006
o Applications, operating system, and middleware support o Transport, network, and MAC protocols o Energy-efficient algorithms o Quality of Service issues o Location discovery techniques o Network scaling and limits o Cross layer design o Network resilience, fault-tolerance, and reliability o Trust, security and privacy o Distributed sensing, actuation, control, and coordination o Measurements and practical experience from experimental systems and testbeds o Modeling and performance evaluation
y el programa final:
o Tutorial 1: Wireless Mesh Networks: Fundamentals, Basic Protocols and Research Issues o Tutorial 3: Pervasive Environments: Challenges and Solutions o Tutorial 5: Design Guidelines for Network Layer Protocols in Ad Hoc and Sensor Networks o Tutorial 2: Wireless Mesh Networks: Applications, Testbeds, Products and Standards o Tutorial 4: Delay/Disruption Tolerant Networking o Tutorial 6: Multimedia Conferencing in Mobile Ad Hoc Networks: Challenges and Early Approaches o Technical Session 1: Routing and Forwarding o Technical Session 2: Mobility Models o Technical Session 3: Analysis, Simulation and Experimentation o Technical Session 4: Connectivity and Coverage o Technical Session 5: Medium Access Control o Technical Session 6 : Location and Membership Services o Technical Session 7: Theory o Technical Session 8: Sensor Networks
1 6 9

Introduccin al simulador NS-2
agradecimientos/acknowledgments
Jae Chung, Mark Claypool o Worcester Polytechnic Institute Ya Xu y Haobo Yu o USC/ISI Polly Huang o AT&T Labs Research Hao-Li Wang o Department of Electrical and Computer Engineering, Iowa State University Sung Park o Network and Embedded Systems Lab (NESL) - Electrical Engineering, UCLA K. Sridharan Iyer, o Texas A&M University
What is NS
Discrete event simulator
o The VINT project : Virtual InterNet Testbed o UC Berkeley, Lawrence Berkeley National Lab, USC/ISI, Xerox PARC, AT&T Research o Packet-level o Link layer and up o Wired and wireless
Object-oriented
o Mixed C++ and Otcl
Most UNIX and UNIX-like systems

o FreeBSD o Solaris o Linux
Window 95/98/NT/2K
o Works, but with an effort
1 7 1
What you CAN do using NS-2

Simulate different scenarios with existing protocols (TCP/UDP) Wired Routing protocols - Distance Vector and Link State (with the link state patch) Ad-Hoc Routing protocols - DSR, AODV, TORA MAC protocols - 802.3, 802.11 (Wireless MAC) Scheduling disciplines - DropTail, RED, WFQ, DRR, LQD etc. Different traffic characterizations - Poisson, Exponential, Pareto etc. Modify NS-2 to implement your own versions of the above protocols or even code totally new protocols Measurement of Statistics:
o Throughput, Delay, Jitter etc. o Queue Monitoring, Drops at Queues. o Literally all that you will need to know with your simulations.
Graphic visualization - using nam (Network Animator) Emulation - A less known fact about ns-2
1 7 2
1 7 3
NS input & output
Basic tcl
proc test {} { proc test {} { set a 43 set a 43 set b 27 set b 27 set c [expr $a + $b] set c [expr $a + $b] set d [expr [expr $a - $b] * $c] set d [expr [expr $a - $b] * $c] for {set k 0} {$k < 10} {incr k} { for {set k 0} {$k < 10} {incr k} { if {$k < 5} { if {$k < 5} { puts "k < 5, pow = [expr pow($d, $k)]" puts "k < 5, pow = [expr pow($d, $k)]" } else { } else { puts "k >= 5, mod = [expr $d % $k]" puts "k >= 5, mod = [expr $d % $k]" } } } } } } test test
1 7 4
Basic OTcl
Class mom Class mom mom instproc greet {} { mom instproc greet {} { $self instvar age_ $self instvar age_ puts "$age_ years old mom: How are you doing?" puts "$age_ years old mom: How are you doing?" } } Class kid -superclass mom Class kid -superclass mom kid instproc greet {} { kid instproc greet {} { $self instvar age_ $self instvar age_ puts "$age_ years old kid: What's up, dude?" puts "$age_ years old kid: What's up, dude?" } } set a [new mom] set a [new mom] $a set age_ 45 $a set age_ 45 set b [new kid] set b [new kid] $b set age_ 15 $b set age_ 15 $a greet $a greet $b greet $b greet
1 7 5
Hello World - Interactive Mode

swallow 71% ns swallow 71% ns % set ns [new Simulator] % set ns [new Simulator] _o3 _o3 % $ns at 1 puts \Hello World!\ % $ns at 1 puts \Hello World!\ 1 1 % $ns at 1.5 exit % $ns at 1.5 exit 2 2 % $ns run % $ns run Hello World! Hello World! swallow 72% swallow 72%
1 7 6
Hello World - Batch Mode

simple.tcl simple.tcl
set set $ns $ns $ns $ns $ns $ns
ns [new Simulator] ns [new Simulator] at 1 puts \Hello World!\ at 1 puts \Hello World!\ at 1.5 exit at 1.5 exit run run
swallow 74% ns simple.tcl swallow 74% ns simple.tcl Hello World! Hello World! swallow 75% swallow 75%
1 7 7
Anatomy of NS Scripts
Create the event scheduler Create network Create protocol agents (connections) Generate traffic Turn on tracing Setup routing Insert errors Start event scheduler
1 7 8
Creating the Event Scheduler

Create event scheduler
o set ns [new Simulator]
Schedule events
o $ns at <time> <event> o <time>: any non-negative real numbers o <event>: any legitimate ns/tcl commands
Start scheduler (the end of your script!)

o $ns run
1 7 9
Creating the Network

Nodes
o set n0 [$ns node] o set n1 [$ns node]
Links and queuing

o $ns duplex-link $n0 $n1 <bandwidth> <delay> <queue_type> o <queue_type>: DropTail, RED, CBQ, FQ
application application
agent
attach-agent
agent
attach-agent
Node
1 8 0
Link
Node
Creating Connections: TCP

TCP
o set o set o $ns o $ns o $ns tcp [new Agent/TCP] tcpsink [new Agent/TCPSink] attach-agent $n0 $tcp attach-agent $n1 $tcpsink connect $tcp $tcpsink
application
application
agent
attach-agent
agent
attach-agent
Node
1 8 1
Link
Node
Creating Traffic: On Top of TCP

FTP
o set ftp [new Application/FTP] o $ftp attach-agent $tcp
application
application
agent
attach-agent
agent
attach-agent
Node
1 8 2
Link
Node
Inserting Errors
Creating Error Module
o set loss_module [new ErrorModel] o $loss_module set rate_ 0.01 o $loss_module unit pkt o $loss_module ranvar [new RandomVariable/Uniform] o $loss_module drop-target [new Agent/Null]
Inserting Error Module

o $ns lossmodel $loss_module $n0 $n1
1 8 3
Tracing
Trace packets on all links
o $ns trace-all [open test.out w]
<event> <time> <from> <to> <pkt> <size>--<flowid> <src> <dst> <seqno> <aseqno>
+ 1 0 2 cbr 210 ------- 0 0.0 3.1 0 0 - 1 0 2 cbr 210 ------- 0 0.0 3.1 0 0 r 1.00234 0 2 cbr 210 ------- 0 0.0 3.1 0 0
Trace packets on all links in nam-1 format

o $ns namtrace-all [open test.nam w]
1 8 4
1 8 5
Simple Simulation Example
TCL Script Step 1

#Create a simulator object set ns [new Simulator] #Open the NAM trace file set nf [open out.nam w] $ns namtrace-all $nf #Open the general trace file Set f [open out.tr w] $ns trace-all $f
1 8 6
TCL Script Step 2

#Create four nodes set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] #Create links between the nodes $ns duplex-link $n0 $n2 2Mb 10ms DropTail $ns duplex-link $n1 $n2 2Mb 10ms DropTail $ns duplex-link $n2 $n3 1.7Mb 20ms DropTail
1 8 7
TCL Script Step 3

#Set Queue Size of link (n2-n3) to 10 $ns queue-limit $n2 $n3 10 #Setup a TCP connection set tcp [new Agent/TCP] $ns attach-agent $n0 $tcp set sink [new Agent/TCPSink] $ns attach-agent $n3 $sink $ns connect $tcp $sink #Setup a FTP over TCP connection set ftp [new Application/FTP] $ftp attach-agent $tcp
1 8 8
TCL Script Step 4

#Setup a UDP connection set udp [new Agent/UDP] $ns attach-agent $n1 $udp set null [new Agent/Null] $ns attach-agent $n3 $null $ns connect $udp $null
#Setup a CBR over UDP connection set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp $cbr set packet_size_ 1000 $cbr set rate_ 1mb
1 8 9
TCL Script Step 5

#Schedule events for the CBR and FTP agents $ns at 0.1 "$cbr start" $ns at 1.0 "$ftp start" $ns at 4.0 "$ftp stop" $ns at 4.5 "$cbr stop"
#Call the finish procedure after 5 seconds of simulation time $ns at 5.0 "finish"
1 9 0
TCL Script Step 6

#Define a 'finish' procedure proc finish {} { global ns nf $ns flush-trace #Close the NAM trace file close $nf #Execute NAM on the trace file exec nam out.nam & exit 0 } #Run the simulation $ns run
1 9 1
1 9 2
Observing the behaviour using nam
Analyze trace file

Use some tools, like AWK or Perl, to analyze the trace file Use excel or xplot to plot the results
+ r + r + r + r + 0.001 2 0 tcp 1000 ------- 0 2.0 1.0 0 0 0.001 2 0 tcp 1000 ------- 0 2.0 1.0 0 0 0.0028 2 0 tcp 1000 ------- 0 2.0 1.0 0 0 0.0028 0 1 tcp 1000 ------- 0 2.0 1.0 0 0 0.0028 0 1 tcp 1000 ------- 0 2.0 1.0 0 0 0.009884 0 1 tcp 1000 ------- 0 2.0 1.0 0 0 0.009884 1 0 ack 40 ------- 0 1.0 2.0 0 1 0.009884 1 2 ack 40 ------- 0 1.0 2.0 0 1 0.013128 1 0 ack 40 ------- 0 1.0 2.0 0 1 0.013128 0 2 ack 40 ------- 0 1.0 2.0 0 1 0.013128 0 2 ack 40 ------- 0 1.0 2.0 0 1 0.01416 0 2 ack 40 ------- 0 1.0 2.0 0 1 0.01416 2 0 tcp 1000 ------- 0 2.0 1.0 1 2 0.01416 2 0 tcp 1000 ------- 0 2.0 1.0 1 2
1 9 3

Introduccin al simulador NS-2 o NS to simulate wireless network
Wireless Simulation in ns-2

Contributed from CMUs Monarch project (Wireless extension to ns2) Various modules were added to ns-2 to simulate node mobility and wireless networking
o Mobile Node o Ad-hoc Routing(DSR, DSDV, TORA, AODV) o MAC802.11 o Radio Propagation Model o Channel
1 9 5
Mobile Node Modules

Agent
o Responsible for packet generations and receptions o Can think of it as an Application layer o CBR(Constant Bit Rate), TCP, Sink, FTP, etc.
RTagent(DSDV, TORA, AODV) or DSR

o Ad-hoc network routing protocols o Configure multi hop routes for packets
LL (Link Layer)
o Runs data link protocols o Fragmentation and reassembly of packet o Runs Address Resolution Protocol(ARP) to resolve IP address to MAC address conversions
1 9 6
Mobile Node Modules (Continued)

IFq (Interface Queue)
o PriQueue is implemented to give priority to routing protocol packets o Supports filter to remove packets destined to specific address
Mac Layer
o IEEE 802.11 protocol is implemented o Uses RTS/CTS/DATA/ACK pattern for all unicast pkts and DATA for broadcast pkts
NetIF (Network Interfaces)

o Hardware interface used by mobilenode to access the channel o Simulates signal integrity, collision, tx error o Mark each transmitted packet with transmission power, wavelength etc.
Radio Propagation Model

o Uses Friss-space attenuation(1/r2) at near distance and Two ray ground (1/r4) at far distance o Decides whether the packet can be received by the mobile node with given distance, transmit power and wavelength o Implements Omni Directional Antenna module which has unity gain for all direction
1 9 7
A first example
The file simple-wireless.tcl is under <NSRoot>/ns-allinone2.1b9/nstutorial/examples/simple-wireless.tcl
cd into the directory and type ns simple-wireless.tcl to run the simulation The simulation will generate a trace file named simple.tr
1 9 8
Setting Up Variables
#============================================================ # Define options #============================================================ set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# Antenna type set val(ll) LL ;# Link layer type set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type set val(ifqlen) 50 ;# max packet in ifq set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(rp) DSDV ;# ad-hoc routing protocol set val(nn) 2 ;# number of mobilenodes
1 9 9
Setting Up Variables
#Instantiate simulator object set ns_ [new Simulator] #Setup Trace File set tracefd [open simple.tr w] $ns_ trace-all $tracefd #Create Topography set topo [new Topography] $topo load_flatgrid 500 500 #Create Object God create-god $val(nn)
2 0 0
Configuring Mobilenode
# Configure nodes $ns_ node-config -adhocRouting $val(rp) -macType $val(mac) -ifqLen $val(ifqlen) -propType $val(prop) -topoInstance $topo -agentTrace ON -macTrace OFF
-llType $val(ll) \ -ifqType $val(ifq) \ -antType $val(ant) \ -phyType $val(netif) \ -channelType $val(chan) \ -routerTrace ON \ -movementTrace OFF
for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node ] $node_($i) random-motion 0 ;# disable random motion }
2 0 1
Configuring Movement
Configure Initial Position
$node_(0) set X_ 5.0 $node_(0) set Y_ 2.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 390.0 $node_(1) set Y_ 385.0 $node_(1) set Z_ 0.0
Create Movement
# Node_(1) starts to move towards node_(0) $ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0" $ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0" # Node_(1) then starts to move away from node_(0) $ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0"
2 0 2
Setup traffic flow

set tcp [new Agent/TCP] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns_ attach-agent $node_(0) $tcp $ns_ attach-agent $node_(1) $sink $ns_ connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns_ at 10.0 "$ftp start"
FTP TCP Sink
2 0 3
node_(0)
node_(1)
Set Stop Time and Start Simulation

Set Simulation Stop Time
for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at 150.0 "$node_($i) reset"; } $ns_ at 150.0001 "stop" $ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt" proc stop {} { global ns_ tracefd close $tracefd }
Finally, Start The Simulation
puts "Starting Simulation..." $ns_ run
2 0 4
Trace File
r 100.381997477 _1_ AGT --- 82 tcp 1060 [13a 1 0 800] ------- [0:0 1:0 32 1] [32 0] 1 0 r: receive event, 100.381997477:time stamps, _1_: node 1, AGT: trace generated by agent, 82: event(pkt) id, tcp: tcp packet, 1060: packet size, 13a(hex): expected duration of pkt transmission (not working), 1: sender mac id, 0: transmitter mac id, 800: pkt type IP (806 for ARP), 0:0: sender address:port# 1:0: receiver address:port#, 32: TTL 1: next hop address, [32 0]: TCP sequence #, ack #
2 0 5
Another simple wireless simulation(1)

Scenario
o containing 3 mobile nodes o moving within 670mX670m flat topology o using DSDV ad hoc routing protocol o Random Waypoint mobility model o TCP and CBR traffic o See:
ns-2/tcl/ex/wireless-demo-csci694.tcl
2 0 6
Another simple wireless simulation(2)

#Define Global Variables set ns_ [new Simulator] set topo [new Topography] $topo load_flatgrid 670 670
; create a ns simulator instance ; create a topology and ; define it in 670x670 area
#Define standard ns/nam trace set tracefd [open 694demo.tr w] $ns_ trace-all $tracefd set namtrace [open 694demo.nam w] $ns_ namtrace-all-wireless $namtrace 670 670 #Create God set god_ [create-god 3]
God is used to store an array of the shortest number of hops required to reach from one node to an other. CAN BE OMITTED!!
2 0 7
Another simple wireless simulation (3)

#Define how a mobile node should be created $ns_ node-config -adhocRouting DSDV\ -llType LL \ -macType Mac/802_11\ -ifqLen 50 \ -ifqType Queue/DropTail/PriQueue \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \ -channelType Channel/WirelessChannel \ -topoInstance $topo -agentTrace ON \ -routerTrace OFF \ -macTrace OFF
2 0 8
Another simple wireless simulation (4)

#Create a mobile node and attach it to the channel set node [$ns_ node] $node random-motion 0 ;# disable random motion
Use for loop to create 3 nodes: for {set i < 0} {$i<3} {incr i} { set node_($i) [$ns_ node] }
2 0 9
Another simple wireless simulation: Movement file

$ns_ at 50.000000000000 "$node_(2) setdest 369.463244915743 170.519203111152 3.371785899154" $ns_ at 51.000000000000 "$node_(1) setdest 221.826585497093 80.855495003839 14.909259208114" $ns_ at 33.000000000000 "$node_(0) setdest 89.663708107313 283.494644426442 19.153832288917" $node_(2) set Z_ 0.000000000000 $node_(2) set Y_ 199.373306816804 $node_(2) set X_ 591.256560093833 #Define node movement model $node_(1) set Z_ 0.000000000000 source movement-scenario-files $node_(1) set Y_ 345.357731779204 e.g., scen-3-test $node_(1) set X_ 257.046298323157 $node_(0) set Z_ 0.000000000000 $node_(0) set Y_ 239.438009831261 $node_(0) set X_ 83.364418416244
2 1 0
Another simple wireless simulation: Traffic Scenario

set udp_(0) [new Agent/UDP] $ns_ attach-agent $node_(0) $udp_(0) set null_(0) [new Agent/Null] $ns_ attach-agent $node_(2) $null_(0) set cbr_(0) [new Application/Traffic/CBR] $cbr_(0) set packetSize_ 512 $cbr_(0) set interval_ 4.0 $cbr_(0) set random_ 1 $cbr_(0) set maxpkts_ 10000 $cbr_(0) attach-agent $udp_(0) $ns_ connect $udp_(0) $null_(0) $ns_ at 127.93667922166023 "$cbr_(0) start" set tcp [new Agent/TCP] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns_ attach-agent $node_(1) $tcp $ns_ attach-agent $node_(2) $sink $ns_ connect $tcp $sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns_ at 150.00000000000000 "$ftp start"
#Define traffic model source traffic-scenario-files e.g., cbr-3-test
2 1 1
Another simple wireless example(5)

#Define node initial position in nam for {set i 0} {$i < 3 } { incr i} { $ns_ initial_node_position $node_($i) 20 } #Tell ns/nam the simulation stop time $ns_ at 200.0 $ns_ nam-end-wireless 200.00 $ns_ at 200.00 $ns_ halt #Start your simulation $ns_ run
2 1 2
The setdest mobility generator

Mobile Movement Generator
./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] [-x maxx] [-y maxy] > [outdir/movement-file] Example: ./setdest -n 20 -p 2.0 -s 10.0 -t 200 -x 500 -y 500 > scen-20-test and the output will be written in a file called scen-20-test.
Random movement
$node start
See ns-2/indep-utils/cmu-scen-gen/setdest/
2 1 3
The traffic patterns generators

ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections] [-rate rate] Generating CBR traffic patterns
o ns cbrgen.tcl -type cbr -nn 10 -seed 1 -mc 8 -rate 4.0
Generating TCP traffic patterns

o ns cbrgen.tcl -type tcp -nn 25 -seed 0 -mc 20
See ns-2/indep-utils/cmu-scen-gen/
2 1 4
Related software
TraceGraph: trace files analyser
o http://www.geocities.com/tracegraph/
BonnMotion: A mobility scenario generation and analysis tool

o http://web.informatik.uni-bonn.de/IV/Mitarbeiter/dewaal/BonnMotion/
nscript: a graphical user interface to create ns-2 simulation scripts

o http://www.people.virginia.edu/%7Eec3z/software.html
Blueware: Bluetooth Simulator for ns

o http://nms.lcs.mit.edu/projects/blueware/
BlueHoc: Bluetooth Performance Evaluation Tool

o http://www-124.ibm.com/developerworks/opensource/bluehoc/
2 1 5

Redes Manet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redes Manet

Uploaded by

Copyright:

Available Formats

Tema 4.

Redes inalmbricas Ad Hoc

Conceptos generales Encaminamiento i. DSR

ii. AODV iii. OLSR Calidad de servicio Control de potencia

Redes Inalmbricas y Computacin Ubicua/2006-2007

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Mobile Ad-hoc Networks (MANETs)

En una MANET la movilidad ha un importancia crucial.

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Porqu las redes ad hoc?

Las redes ad hoc

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Un caso ejemplar: Traffic networks

o Cooperative driver assistance:

o Decentralized floating car data:

o User communications and information services:

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Entornos asimtricos; pueden variar:

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Retos de las redes ad hoc

Limitaciones de las redes ad hoc

o relativas al carcter mvil de las estaciones

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Tema 4.Redes inalmbricas Ad Hoc

Conceptos generales Encaminamiento i. DSR

ii. AODV iii. OLSR Calidad de servicio

Redes Inalmbricas y Computacin Ubicua/2006-2007

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

o Which is the best path? o Who decides - source or intermediate nodes?

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Who determines route?

o Destination (hop-by-hop) routing [Like postal service]

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

MANET Routing Properties

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Why is Routing in MANET different ?

Dynamic Solution much more difficult to be deployed

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Tipos de protocolos de encaminamiento

La tercera va: los protocolos hbridos Aspectos a tener en consideracin

o Overhead del descubrimiento y del mantenimiento de la ruta

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

manet Working Group

Purpose of MANET working group

Approaches are intended to be:

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Description of Working Group

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Goals and Milestones

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Uso del flooding para la entrega de datos

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Uso del flooding para la entrega de datos

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Uso del flooding para la entrega de datos

S E B C A H G K N I recibe la trama pero no la reenva por que ya lo ha hecho D F J M

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Uso del flooding para la entrega de datos

S E B C A H G K N I recibe la trama de J y de K (entre ellos son hidden) posible colisin D F J M

Redes Inalmbricas y Computacin Ubicua/2006-2007 Redes Inalmbricas y Computacin Ubicua/2006-2007

Uso del flooding para la entrega de datos