Redes Manet PDF

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

Ubicua/2006-2007
Computacin Ubicua/2006-2007 Mobile Ad-hoc Networks (MANETs)
Redes formadas por nodos mviles con conexin inalmbrica.

No utilizan ninguna infraestructura preexistente
Inalmbricas yy Computacin
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
Redes Inalmbricas
Redes
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Las redes ad hoc

o Se pueden desplegar de forma flexible en entornos que no disponen de
infraestructura fija
Redes
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Un caso ejemplar: Traffic networks
Coches inteligentes y carreteras Por ejemplo: FleetNet Internet on the
inteligentes. Los sistemas de abordo Road. Ad Hoc Radio Network for Inter-
hablan con la carreteras. Vehicle Communications
o http://www.fleetnet.de
Ofrece:
Redes Inalmbricas
o Cooperative driver assistance:

Emergency notification
Overtaking assistance
Obstacle warning
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Varios tipos
Entorno completamente simtrico

o todos los nodos tiene capacidades y responsabilidades idnticas
Redes Inalmbricas
Entornos asimtricos; pueden variar:

o Los radios de transmisin
o La duracin de las bateras
Redes
o La capacidad de proceso
o Capacidad de encaminamiento
o Las tecnologas utilizadas
A
A menos
menos que
que est
est indicado
indicado dede otra
otra
manera,
manera, se
se asume
asume implcitamente
implcitamente el el
entorno
entorno completamente simtrico en el
completamente simtrico en el
que todos los nodos tienen idnticas
que todos los nodos tienen idnticas
capacidades
capacidades yy responsabilidades
responsabilidades
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Retos de las redes ad hoc
Cmo encaminar paquetes entre estaciones
Cmo hacerlo de forma eficiente
Otros retos:
o Calidad de servicio
o Configuracin
o Descubrimiento de servicios
o Seguridad y privacidad
Redes Inalmbricas
o Prestaciones TCP
o ...
Limitaciones de las redes ad hoc
Redes
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
[Corson99] , S. Corson and J. Macker, Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and
6 Evaluation Considerations, RFC 2501, January 1999.
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Visin general
aplicaciones
Middleware
TCP/UDP
TCP
seguridad
zeroconf
MobileIP
Redes Inalmbricas
IP
Redes
MANETs Mobile ad hoc networking: imperatives and challenges,

Imrich Chlamtac, Marco Conti, Jennifer J.-N. Liu,
sensores IEEE 802.11 Bluetooth Ad Hoc Networks, Elsevier, 1 (2003).
7
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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?
Redes Inalmbricas
msg
Redes
9
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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]
Redes Inalmbricas
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
Redes
Intermediate nodes look at destination in header, consult internal tables to

determine appropriate next hop
1
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
o Loop Freedom
o Demand Based Operation
o Security
Redes
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)
1 o Efficiency
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
o energy consumption
o host position
Dynamic Solution much more difficult to be deployed
Redes
1
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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 Que
Que solucin
solucin adoptar
adoptar depende
depende del
del tipo
tipo di
di trafico
trafico yy del
del tipo
tipo de
de movilidad!!
movilidad!!
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
Approaches are intended to be:

o relatively lightweight in nature
o suitable for multiple hardware and wireless environments, and address
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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)
Redes Inalmbricas
Both IPv4 and IPv6 will be supported.

Routing security requirements and issues will also be addressed.
Redes
1
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Goals and Milestones
Done Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues.
Done Agenda bashing, discussion of charter and of mobile ad hoc networking draft.
Done Discuss proposed protocols and issues. Redefine charter.
Done Publish Informational RFC on manet design considerations

Done Review the WG Charter and update
Done Submit AODV specification to IESG for publication as Experimental RFC
Done Develop I-D for potential common manet encapsulation protocol approach
Done Submit initial I-D(s) of candidate proposed routing protocols and design frameworks
Done Promote implementation, revision, and testing of initial proposed I-D(s)

Redes Inalmbricas
Done Explore basic performance and implementation issues of initial approaches
Done Explore proposed proactive protocol design commonalities
Done Submit DSR specification to IESG for publication as Experimental RFC
Done Submit OLSR specification to IESG for publication as Experimental RFC
Done Submit TBRPF specification to IESG for publication as Experimental RFC

Redes
Done Develop a further focused problem statement and address an approach for a common engineering work effort
Done Reevaluate the WG's potential based on the problem statement consensus
Mar 05 Submit initial ID of RMP for WG review
Mar 05 Submit initial ID of PMP for WG review
Mar 05 Submit inital ID of generalized MANET flooding approach
Jun 05 Revise WG documents and review
Nov 05 Document initial implementation progress and experience Revise documents based upon implementation experience
Feb 06 Submit RMP specification and supporting documentation to IESG for publications as Proposed Standard
Feb 06 Submit PMP specification and supporting documentation to IESG for publications as Proposed Standard
Feb 06 Submit MANET flooding specification to IESG for publication as Experimental Standard
1 Mar 06 Review and update milestones
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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

Redes Inalmbricas
Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004.

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
Redes
T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausen-

manet-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/draft-
ietf-manet-smf-00.txt
Y muchos ms:
o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list
1
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.

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

Redes Inalmbricas
Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004.

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
Redes
T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausen-

manet-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/draft-
ietf-manet-smf-00.txt
Y muchos ms:
o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list
1
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Uso del flooding para la entrega de datos
Una primera nodo que acaba de enviar una trama

Y
solucin se basa
en utilizar flooding nodo que acaba de recibir una trama
Z
controlado envio broadcast de una trama
S L
E
Redes Inalmbricas
B M
F
C J
Redes
D
A G
H K
N
I
destino
1
9
Ubicua/2006-2007
Y
nodo que acaba de enviar una trama
nodo que acaba de recibir una trama

Z
envio broadcast de una trama
S L
E
Redes Inalmbricas
B F M
C J
Redes
A G D
H
K
N
I
posible colisin!!
2
0
Ubicua/2006-2007
Y

Z
S L
E
Redes Inalmbricas
B F M
J
C
Redes
A G D
H K
N
I
recibe la trama pero no la

reenva por que ya lo ha
2 hecho
1
Ubicua/2006-2007
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I
recibe la trama de J y de K
(entre ellos son hidden)
2 posible colisin
2
Ubicua/2006-2007
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I
D no reenva por que es el

destino final
2
3
Ubicua/2006-2007
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I
El
Elflooding
floodingha
hateminado!
teminado!
2
4
Ubicua/2006-2007
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
Desventajas
Redes Inalmbricas
Sencillo
Overhead potencialmente muy alto
Es ms eficiente si la tasa de envo es
baja el overhead de los procesos de o en el peor de los casos todos los
bsqueda y mantenimiento de rutas nodos alcanzable por el nodo
explicitas resulte ser ms alto fuente recibirn los datos
Redes
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
Potencialmente la entrega de los datos es menos fiable a causa del uso de
es ms fiable, por que se pueden difusiones.
utilizar mltiples rutas. o Ej.: las difusiones con el MAC de
?
IEEE 802.11 son pocos fiables
2
5
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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.
Redes
Uso del send buffer

Uso de RREQ identifier
2
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Uso del Route Request en DSR
Y
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
Redes Inalmbricas
B M
F
C J
Redes
D
A G
H K
N
I
destino
2
8
Ubicua/2006-2007
Y

Z
L
E [S,E]
S L
Redes Inalmbricas
B F M
C [S,C] J
Redes
A G D
H
K
N
I
posible colisin!!
2
9
Ubicua/2006-2007
Y

Z
L
S L
E
Redes Inalmbricas
B F [S,E,F] M
J
C
Redes
A G [S,C,G] D
H K
N
I
recibe el RREQ pero no lo

3 hecho
0
Ubicua/2006-2007
Y

Z
L
S L
E M
Redes Inalmbricas
B F J [S,E,F,J]
C
Redes
A G D
K[S,C,G,K]
H
N
I
3 posible colisin
1
Ubicua/2006-2007
Y

Z
L
L
S
E M [S,E,F,J,M]
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I

destino final
3
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Uso del Route Reply
En destino D al recibir el primer RREQ enva un Route Y

Reply (RREP)
RREP se enva usando la ruta obtenida invirtiendo la
que est en el RREQ que se ha recibido Z

Redes Inalmbricas
S RREP [S,E,F,J,D] L
E M
B F
J
C
Redes
A G D
H K
N
I
3
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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

Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Los nodos intermedio utilizan solo y nicamente la ruta incluida en

la cabecera para saber a quien tienen que reenviar el paquete.
Redes
3
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Data Delivery in DSR
La cabecera de los paquetes Y
va creciendo al aumentar de
la longitud de la ruta
Z
DATA [S,E,F,J,D]
S L
E M
B F
Redes Inalmbricas
J
C
A G D
Redes
H K
N
I
3
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
4. Cuando el nodo E retransmite Data [S,E,F,J,D] descubre la ruta

[E,F,J,D] hacia el nodo D Y
Z
Redes
E L
S
M
B F
J
C
A D
H G K
N
I
3
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
un route discovery
Posible problema del uso de las caches:
o en entornos altamente mviles el uso de las caches puede afectar las
Y
Redes
prestaciones
Z
E L
S
M
B F
J
C
A K D
H G
N
I
3
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 Y
confirmar que ese enlace se puede
utilizar para transmitir datos.
Redes Inalmbricas
o Ack del MAC (p.ej., 802.11) Z

o Passive acks
o DSR-specific ACK S L
E RERR [J-D] M
B F
Redes
J
C
A G D
H K
N
I
3
9
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Tcnica de Automatic route shortening para optimizar las rutas

o Uso de gratuitous Route Reply
Uso de flujos de datos: los flows
Redes
4
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 DSR: ventajas y desventajas
Se gestionan solo las rutas entre nodos El tamao de la cabecera crece al crecer
que quieren comunicarse de la ruta debido al uso del source
routing
o se reduce la carga para El flooding de las peticiones de ruta
mantener varias rutas puede potencialmente alcanzar todos los

nodos en la red.
Hay que evitar las colisiones producidas
El uso de la cache puede reducir la por la retransmisin de los RREQ
carga de futuros procesos de route
o se insertan retardos aleatorio
discovery
Redes Inalmbricas
antes de enviar el RREQ.

Aumento de la contienda para el acceso
Un solo proceso de RR puede producir al canal si se producen demasiadas RR
variar rutas hacia el destino gracias a por nodos que usan sus caches
las respuestas de las caches de los o Problema de la tormenta de
Redes
nodos intermedios 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
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007
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
Redes Inalmbricas
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
Redes
AODV mantiene la caracterstica del DSR que las rutas son

mantenidas solo para los nodos que quieren comunicar
4
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Bi-directional links are required!

Redes
4 Thanks to Raoul Reuter

4
Redes Inalmbricas
Redes Ubicua/2006-2007
Computacin Ubicua/2006-2007 Distance Vector (Tables)
1 2
A B C
Dest. Next Metric Dest. Next Metric Dest. Next Metric
A A 0 A A 1 A B 3
B B 1 B B 0 B B 2
C B 3 C C 2 C C 0

5
Inalmbricas yy Computacin Ubicua/2006-2007
Computacin Ubicua/2006-2007 Distance Vector (Update)
B broadcasts the new routing

information to his neighbors
Redes Inalmbricas
Routing table
is updated (A, 1) (A, 1)
(B, 0) (B, 0)
(C, 1) (C, 1)
Redes
1 1
A B C
A A 0 A A 1 A B 3 2
B B 1 B B 0 B B 1
C B 3 2 C C 1 C C 0

6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Distance Vector (New Node)
broadcasts to update
tables of C, B, A with
new entry for D
Redes Inalmbricas
(A, 1) (A, 2)
(B, 0) (B, 1)
(C, 1) (C, 0)
(D, 2) (D, 1) (D, 0)
Redes
1 1 1
A B C D
A A 0 A A 1 A B 2
B B 1 B B 0 B B 1
C B 2 C C 1 C C 0
D B 3 D C 2 D D 1

7
Ubicua/2006-2007
Broken Link and consequent Loops

1 1 1
A B C D
Dest. Next Metric Dest.c Next Metric Dest. Next Metric

D B 3 D C 2 D D
B
1
Redes Inalmbricas
Redes
(D, 2) (D, 2)
1 1 1
A B C D

D B 3 D C 2 D B 3

8
Ubicua/2006-2007
create the Count to Infinity problem

Redes Inalmbricas
(D,5)
(D,4) (D,4)
(D,3)
Redes
(D,2) (D,2)
1 1 1
A B C D
Dest. Next Metric Dest.c Next Metric Dest. Next Metric

D B 3, 5, D C 2, 4, 6 D B 3, 5,

9
Ubicua/2006-2007
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.
Redes Inalmbricas
Redes

0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Cuando el destino recibe el Route Request, responde enviando un

Route Reply
Redes
El Route Reply recorre la ruta activada a travs del envo del Route
Request
5
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Envio del Route Request
Y
nodo que acaba de recibir una trama Z
envi broadcast de una trama RREQ
S L
E
Redes Inalmbricas
B M
F
C J
Redes
D
A G
H K
N
I
destino
5
2
Ubicua/2006-2007
Y

Z
Links de la ruta inversa
S L
E
Redes Inalmbricas
B F M
C J
Redes
A G D
H
K
N
I
posible colisin!!
5
3
Ubicua/2006-2007
Y

Z
S L
E
Redes Inalmbricas
B F M
J
C
Redes
A G D
H K
N
I
recibe la trama pero no la

5 hecho
4
Ubicua/2006-2007
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I
5 posible colisin
5
Ubicua/2006-2007
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I

destino final
5
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Envio del Route Reply
Y

Z
S L
E M
Redes Inalmbricas
B F
J
C
Redes
A G D
H K
N
I
5
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 Z
S L
E M
Redes Inalmbricas
F
B
J
C
Redes
A G D
H K
N
I
5
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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),
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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

Redes Inalmbricas
may be used as an indication of link failure

Redes
6
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
A B C D
E
o C efecta un route discovery buscando a D. EL nodo A recibe el RREQ,
Redes
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 B C D
E
6
2
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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.
Redes
No requiere modificar la estructura de los paquetes IP
6
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 LSR vs. OLSR
La sobrecarga de hacer broadcasting
de la informacin sobre el estado de Son
los enlaces se reduce limitando el necesarias
24
numero de nodos que reenvan esta

retransmisio
informacin nes para
o Una difusin desde el nodo X es difundir el
reenviada solo por sus multipoint mensaje
hasta tres
relays salto de
Redes Inalmbricas
o Los multipoint relays del nodo X distancia

nodo que retransmite
son sus vecinos escogidos de
manera que cada vecino two-hop
de X sea un vecino one-hop de
Redes
por lo menos un multipoint relay Son necesarias

de X 11
retransmisione
o Cada nodo transmite su lista de s para difundir
vecinos en mensajes peridicos, el mensaje
de forma que todos los nodos hasta tres
salto de
puedan saber cuales son sus distancia
vecinos two-hops, para poder
escoger sus multipoint relays
6 nodo que retransmite
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
seal es recibida por un vecino.

P
o strict 2-hop neighbor
multipoint relay (MPR): M
o Un nodo seleccionado por su
Redes
vecino x, para retransmitir todos Z

los mensajes de difusin que X Y
recibe de x, si no es un mensaje
duplicado y si el tiempo de vida
es >1
multipoint relay selector (MS)
o Un nodo que ha seleccionado su
vecino, x como MPR
6
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Tablas de encaminamiento
Todos los nodos gestionan una tabla de encaminamiento

La estructura es:
1. R_dest_addr R_next_addr R_dist R_iface_addr

2. R_dest_addr R_next_addr R_dist R_iface_addr
3. ,, ,, ,, ,,
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
Redes Inalmbricas
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:
Redes
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
8
6
Redes
Redes Inalmbricas
Implementaciones
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
surrounding circumstances.
The resource limitations and the mobility of hosts make things more
complicated.
Hard QoS guarantee is not possible in MANETs
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Effects of congestion and mobility: PSNR
degradation due to mobility

Bursty losses
Several consecutive
frames lost (video
freezed)
Redes Inalmbricas
degradation due to congestion

Redes
Random losses
More uniform
distortion decay
Video at 10Hz 200 seconds interval

7
1
Computacin Ubicua/2006-2007 Effects of congestion and mobility: jitter
Congestion jitter:
relatively small
frequent variations
Redes Inalmbricas
Mobility jitter:
Redes
very large peaks

occasional
occurrences on route
change
7
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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)
Redes Inalmbricas
QoS Routing
o QoS enabled routing (AODV/OLSR)
o CEDAR(Core-Extraction Distributed Ad-hoc Routing)
o Ticket based Probing (distributed QoS routing)
Redes
QoS MAC
o IEEE 802.11e
QoS
QoS in
o MACA/PR
(Multiple Access Collision Avoidance
with Piggyback Reservation) in
MANETs
o prioritised binary countdown (PBC)
7
... and
o SWAN: integrated proposal
MANETs
4 Mona Ghassemian, Kings College, September 2003
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
into the network

Each router
o Maintains reservation state for each flow
o Classifies every packet and decides forwarding behavior
Redes
o Monitors the flow to ensure that it does not consume more than the
reserved resources
Advantages
o Enables fine-grained QoS and resource guarantees
Disadvantages
o Not scalable, harder to administer
7
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 Diff Serv Code Point (DSCP)
o Finite set of DSCPs defined
Redes Inalmbricas
Interior nodes determine the type of service for forwarded packets

based on their DSCP values
Advantages
o More scalable
Redes
o No per-flow state
o Easier to administer
Disadvantages
o Cannot provide the same per-flow guarantees as IntServ
7
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
Three types of nodes:

core
o Ingress (transmit)
o Core (forward)
o Egress (receive) 2
Redes
4
ingress
3
1
egress
6 7
5
7
Ubicua/2006-2007
QoS Model
o DiffServ
o IntServ

QoS Signalling
Redes Inalmbricas
QoS Routing
Redes
QoS MAC
o IEEE 802.11e
QoS
QoS in
o MACA/PR
MANETs
7
... and
MANETs
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
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
Redes
Most papers support that In-band Signaling is more appropriate for

MANETs.
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 INSIGNIA Features
Approach
o Adaptive QoS approach
o Service Differentiation via packet prioritization
To provide adaptive QOS it uses:

o Fast Reservation
Redes Inalmbricas
o Fast Restoration
o QoS reporting: a feedback mechanism
o Adaptation according to network conditions
Redes
8
1 Seoung-Bum Lee, COMET Group, Netwokring 2000, Paris
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
o outstanding reservations and states automatically time out, typically in

seconds range.
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 INSIGNIA IP option
SERVICE PAYLOAD BANDWIDTH BANDWIDTH

MODE INDICATOR INDICATOR REQUEST

RES/BE BQ/EQ BW_IND MAX MIN
1 bit 1 bit 1 bit 16 bits

Redes Inalmbricas
SERVICE MODE : adaptive (RES) service / best effort service

Redes
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
Redes Inalmbricas Ubicua/2006-2007
Computacin Ubicua/2006-2007 Reservation Set-up
M2
MS
M1 MD
M3
M4
Redes
QOS report : MAX reservation established

Packets Received at Destination Mobile Node Legend
RES BQ MAX Max_BW Min_BW RES/BQ packet

RES/EQ packet
RES EQ MAX Max_BW Min_BW
BE packet
MAX reserved link
8 MIN reserved link
Computacin Ubicua/2006-2007 Re-routing / Restoration
M2
Redes Inalmbricas
M
M22
MS
M1 MD
M3
Rerouting
Rerouting
M4
Redes
immediate restoration
Legend
RES/BQ packet
RES/EQ packet
BE packet
MAX reserved link
8 MIN reserved link
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Re-routing / Degradation
EQ degradation
: degraded to minimum service

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

Legend
RES BQ MIN Max_BW Min_BW
RES/BQ packet
BE EQ - Max_BW Min_BW
RES/EQ packet
BE packet
MAX reserved link
8 MIN reserved link
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Adaptation : Scale Down
Packets sent at Source Mobile Node after Scaling Down to MINIMUM service
RES BQ MAX Max_BW Min_BW

Persistent
Persistent
BE EQ - - - EQdegradation
EQ degradation
Scale down to MIN service

Redes Inalmbricas
MS
M1 MD
M5
M4 bottleneck
node
Redes
QOS
QOSreport
report: :Scale
ScaleDown
Down
Pkts Received at Destination after Scaling Down to MINIMUM service Legend
RES BQ MIN Max_BW Min_BW RES/BQ packet

RES/EQ packet
BE EQ - - -
BE packet
MAX reserved link
8 MIN reserved link
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Adaptation : Scale Up
Packets sent by Source Mobile Node in MIN service constant resource availability
detected
RES BQ MAX Max_BW Min_BW
resource now available

MAX service re-initiated
Redes Inalmbricas
MS
M1 MD
M5
M4 bottleneck
bottleneck
node
Redes
node
Pkts Received at Destination in MIN service
QOS
RESreport
BQ : Scale
MAX Up Max_BW Min_BW
Legend
RES/BQ packet
RES/EQ packet
BE packet
MAX reserved link
8 MIN reserved link
Ubicua/2006-2007
QoS Model
o DiffServ
o IntServ

QoS Signalling
Redes Inalmbricas
QoS Routing
Redes
QoS MAC
o IEEE 802.11e
QoS
QoS in
o MACA/PR
MANETs
8
... and
MANETs
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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).
Redes Inalmbricas
Redes

0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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).
Redes Inalmbricas
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
Redes
Precursors
AODV new fields. (4 new fields)
1. Maximum Delay,
2. Minimum Available Bandwidth,
3. List of Sources Requesting Delay Guarantees and
4. List of Sources Requesting Bandwidth Guarantees
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 S D
Redes Inalmbricas
Destination sends resource information

back to source in the RREP message RREQ
Redes
RREP
9
2
Ubicua/2006-2007
Other Challenges for QoS Routing and Admission Control
Simultaneous
Intersecting X
Requests
Redes Inalmbricas
Redes
Simultaneous P Q
Parallel Requests
R S
9
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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

Redes Inalmbricas
traffic.
Fixed
Redes
access network
Wireless Ad hoc
Wireless Ad hoc
Intranet Traffic Extranet Traffic

4
Ubicua/2006-2007
QoS Model
o DiffServ
o IntServ

QoS Signalling
Redes Inalmbricas
QoS Routing
Redes
QoS MAC
o IEEE 802.11e
QoS
QoS in
o MACA/PR
MANETs
9
... and
MANETs
Ubicua/2006-2007
QoS Model
o DiffServ
o IntServ

QoS Signalling
Redes Inalmbricas
QoS Routing
Redes
QoS MAC
o IEEE 802.11e
QoS
QoS in
o MACA/PR
MANETs
9
... and
MANETs
7
9
Redes
Redes Inalmbricas
SWAN Model
Tema 4.-
B. Encaminamiento
i. DSR
ii. AODV
iii. OLSR

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 E(p) = i * v * tp
o Tiempo de transmisin del paquete
Tamao del paquete
Redes Inalmbricas
Ancho de banda
Lucent WaveLAN 2.4 GHz, 11Mbps
o Recepcin 240mA
Redes
o Transmisin 280mA
o V = 5 voltios
o tp = (ph/2*106 + pd/11*106)
Ph = tamao cabecera Etx(p) = 280mA * v * tp

Pd = tamao datos
Erx(p) = 240mA * v * tp
9
9
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
15m/s de velocidad mxima

Modelo random waypoint
Patrn de trfico Estudio de sensibilidad
20 fuentes CBR Parmetros evaluados
Redes
4 paquetes/seg de 512 bytes Patrn de movimiento

Patrn de trfico
Nmero de estaciones
rea de la red
1
0
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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]
Redes Inalmbricas
Energa Tx Energa Rx
100%
Consumo de Energa (%)
75%
Redes
50%
25%
0%
DSR AODV DSDV TORA
1
0
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
700
DSR AODV DSDV TORA
Consumo de energa (Julios)
600
500
Redes
400
300
200
100
0
0 5 10 15 20 25
Velocidad (m/s)
1
0
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
3500
DSR AODV DSDV TORA
3000
2500
Redes
2000
1500
1000
500
0
10 20 30 40 50
Nmero de estaciones
1
0
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
1000
DSR AODV DSDV TORA
800
Redes
600
400
200
0
250mx250m 500mx250m 500mx500m 1000mx500m
MANET rea
1
0
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 Rutas actualizadas
o Reactivos aprendizaje de rutas
Incrementar el nmero de fuentes CBR es EQUIVALENTE a
Redes Inalmbricas
incrementar la tasa de envo

700
DSR AODV DSDV TORA
600
500
Redes
400
300
200
100
0
10 20 30
Nmero de fuentes CBR

1
0
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
aproximaciones proactivas
Redes
1
0
6
Tema 4.-
Aspectos relacionados:
o Configuracin cero
zeroconf: Zero Configuration Networking
o movilidad a nivel de red: mobileIP
o Whats new?

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
simplemente a un hub
Apple con Macs dotados de IEEE 802.11 Airport lo hace de modo
inalmbrico
Redes
o Microsoft NETBIOS provee para redes pequeas un sistema alternativo
1
0
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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 Simplicidad y facilidad de uso (la escalabilidad no debera ser un
1
0
objetivo primordial del grupo de trabajo)
Ubicua/2006-2007
Computacin Ubicua/2006-2007 zeroconf: requerimientos
Protocolos TCP/IP inaceptables en redes emergentes

o DNS RFC 1034 y 1035 Domain Name Service
o DHCP RFC 2131 Dynamic Host Configuration Protocol

o LDAP RFC 2251 Lightweight Directory Access Protocol
o MADCAP RFC 2730 Multicast Address Dynamic Client Allocation
Protocol
Coexistencia y escalabilidad
Redes Inalmbricas
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
Redes
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
1 de protocolo)
1
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Tema 4.-
o Asignar direcciones IP
o Asignar direcciones IP multicast
o Descubrir servicios

zeroconf/asignacin de direcciones IP:
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Requerimientos:
o Ha de configurar una mscara de red apropiada
o Ha de tener una direccin IP nica dentro de una subred
Redes
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 o IPv6 permite a un host seleccionar apropiadamente una direccin, una
1 mscara de red e informacin de encaminamiento. As, ya existe una
4 configuracin Zeroconf
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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.
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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, draft-
ietfmanet-autoconf-01.txt, Internet Engineering Task Force, MANET

Working Group, July 2000.
est limitado a protocolos reactivos de routing
tiene altas latencias
Redes Inalmbricas
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.
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
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.
Redes
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-ipv4-
acd-03.txt propone un mecanismo similar y para la resolucin de
conflictos usa ARP.
1
1
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
1
1 Jeong et al. Ad Hoc IP Address Autoconfiguration draft-jeong-adhoc-ip-
8 addr-autoconf-00.txt
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
son los paquetes,consiguindose

el objetivo de DAD dbil.
o Para cada mensaje route_request,
los nodos implicados debern aadir
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 conflict-free allocation
Prophet address allocation for large scale manet , Zhou, Ni, Mutka,
SIGCOMM 2003
Redes Inalmbricas
Redes
1
2
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Redes
1
2
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 conflict-free allocation - Prophet
Ejemplo de funcionamiento: Cuando la red se inicia slo est A.
o R[1,8] Elige aleatoriamente el nmero 3 como
direccin IP y como semilla para f(n).
o f(n)=(address x state x11) mod 7
Cuando B intenta unirse, A calcula

o cada nodo tiene asociado: f(3)=(3 x 3 x11) mod 7=1 y se lo pasa a
(address, state of f(n)). B como direccin IP y semilla. Adems
actualiza su semilla con ese valor.
Posteriormente C se aproxima a A y D
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
luego se fusionen).
Los autores proponen una solucin aproximada basada en la
descomposicin en factores primos. Cualquier nmero puede
representarse nicamente por:
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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).
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
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.
Redes
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
Correccin: Entendida como la minimizacin del tiempo de vulnerabilidad
1
(DAD) esto es los perodos de sombra en los que no se puede garantizar
2
5 que haya duplicados.
Tema 4.-

zeroconf/asignacin de direcciones IP multicast
Ubicua/2006-2007
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
Redes Inalmbricas
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
Redes
232.255.255.255
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
1 se describe en RFC 2365
2
7
zeroconf/asignacin de direcciones IP multicast
Ubicua/2006-2007
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
Redes Inalmbricas
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
Redes
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
o Asigna direcciones nicas y se encarga de su gestin
o Previene la reasignacin de direcciones asignadas
1
2
8
Tema 4.-

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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)
Redes
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
1
by Sun Microsystems
3
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
responds to service requests from UA

Implementation
o with a DA
Redes
o without a DA
1
3
1
Ubicua/2006-2007
Service Location Protocol (cont.)
With a DA
UA DA SA
st
SrvRq service:da
DAAdver
vert t
D AA d service:da://129.187.222.102
SrvReg
service:da:
Redes Inalmbricas
//129.187.222.102 service:printer:
//129.187.222.134
SrvRq Sr v Ac
service:printer st k color=true, postscript=true,
color=true
ly
SrvRp
Redes
service:printer:
//129.187.222.134
AttrRq
st
ly
AttrRp
color=true,
postscript=true,
1
3
2
Ubicua/2006-2007
Service Location Protocol (cont.)
Without a DA
UA SA
SrvRq
service:da st
A Ad v er t
S
service:da:
Redes Inalmbricas
//129.187.222.102
SrvRq
service:printer st
color=true
ly
SrvRp
Redes
service:printer:
//129.187.222.134 AttrRq
st
ly
AttrRp
color=true,
postscript=true,
1
3
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
variables
o control point
searches for devices (services)
1
3
4
Ubicua/2006-2007
Universal Plug and Play
Networking
Step 1. Discovery
Step 2. Description
Step 3. Control
Step 4. Eventing
Step 5. Presentation
Redes Inalmbricas
Redes
1
3
5
Ubicua/2006-2007
Inalmbricas yy Computacin Step 1. Discovery
control advertise device 2

point 1
multicast
service 1
control
Redes Inalmbricas
advertise
point 2 service 2
multicast
Redes
device 1
search
control
service 1
point 3
response (unicast)
service 2
1
3
6
Ubicua/2006-2007
Inalmbricas yy Computacin Step 2. Description
control UPnP description request device

point
UPnP description for device

Redes Inalmbricas
service 1
UPnP description request

Redes
UPnP description for service service 2
1
3
7
Ubicua/2006-2007
Inalmbricas yy Computacin Step 3. Control
control device
point
action request service
Redes Inalmbricas
result
Redes
query variable
variable value
1
3
8
Ubicua/2006-2007
Inalmbricas yy Computacin Step 4. Eventing
control device 1
point subscription request
subscriber service 1
SID=uuid:1 subscription (uuid:1) publisher
renewal request
Redes Inalmbricas
subscription (uuid:1)
event message
Redes
cancellation (uuid:1)
control
point event message
Subscriber
SID=uuid:2
1
3
9
Ubicua/2006-2007
Inalmbricas yy Computacin Step 5. Presentation
browser device
presentation request
service
Redes Inalmbricas
presentation page
control and/or status

Redes
1
4
0
Ubicua/2006-2007
Jini
Main Aspects
service
o devices (printers, displays, disks)
o software (applications, utilities)

o information (databases, files)
o users of the system
lookup service
Redes Inalmbricas
o maps interfaces indicating service functionality to sets of objects

implementing the service
RMI (Java Remote Invocation Method)
Redes
1
4
1
Ubicua/2006-2007
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
Redes Inalmbricas
o objects register with other objects to get notifications

o when services join or leave, events are signaled
Redes
1
4
2
Ubicua/2006-2007
Jini
Discovery
A service provider seeks a lookup service.
lookup service
Redes Inalmbricas
Redes
client service
provider
service object
service attributes
1
4
3
Ubicua/2006-2007
Jini
Join
A service provider registers a service object (proxy) and its service attributes with the
lookup service.
lookup service
Redes Inalmbricas
service object
service attributes
Redes
client service
provider
service object
service attributes
1
4
4
Ubicua/2006-2007
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
Redes Inalmbricas
service object
service attributes
Redes
client service
provider
service attributes
1
4
5
Ubicua/2006-2007
Jini
Client Uses Service
The client interacts directly with the service provider via the service proxy object.
lookup service
Redes Inalmbricas
service object
service attributes
Redes
client service
provider
service attributes
1
4
6
Tema 4.-
o Configuracin cero
o Whats new?

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
1
4
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Clase A 0 red
Red Host
subnet C
1.0.0.0 .. 126.0.0.0
Clase B red Host

Redes
10 Red
128.0.0.0 .. 191.255.0.0
Clase C 110 Red Host
192.0.0.0 .. 223.255.255.0
Clase D 1110 direccin multicast
224.0.0.0 239.255.255.255
1
4
9
0
5
1
Redes
Redes Inalmbricas
la red origen
Un agente en
1
Internet
nodo IP
2
4
la red actual
Un agente en
3
La solucin
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Arquitectura
HA
Internet
subnet A
subnet B

Mobile
Mobile node
node (MN)
(MN)
Redes Inalmbricas
oo nodo
nodo que
que cambia
cambia su
su punto
punto de
de
conexin
conexin de
de una
una subred
subred aa otra
otra
subnet C

Home
Home agent
agent (HA)
(HA)
HA oo router
router en
en la
la subred
subred home
home del
del
Redes
MN
MN que
que se
se encarga
encarga deldel tunneling
tunneling
de
de los
los datos
datos hacia
hacia el
el MN
MN

Foreign
Foreign agent
agent (FA)
(FA)
oo router
router en
en la
la subred
subred actual
actual
(visitada)
(visitada) del
del MN
MN queque se
se encarga
encarga
del
del reenvo
reenvo dede los
los paquetes
paquetes hacia
hacia
el
el MN
MN
1
5
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Servicios de MobileIP
HA
Internet
subnet A
subnet B

Agent
Agentdiscovery
discovery
Redes Inalmbricas
oolos
losHA
HAyylos
losFA
FAhacen
hacenpublica
publicasusu
presencia
presenciaenencada
cadasubred
subred(o (o subnet C
segmento
segmentode desubred)
subred)enenelelque
que
quieran proveer el servicio
quieran proveer el servicio
Redes

Registration
Registration
ooestablecimiento
establecimientode
deuna
una
conexin
conexin entre un FAooelelHA
entre un FA HAyy
un
unMN
MN

Tunneling
Tunneling
ooreenvo
reenvode
delos
losdatagramas
datagramasalalMN
MN
por parte del HA
por parte del HA
1
5
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Esquema de funcionamiento de mobileIP
HA
agent agent adv msg

discovery agent disc msg
reg. request
reg. request
registration
Redes Inalmbricas
reg. accept/deny
reg. accept/deny
Redes
tunnelling
1
5
3
Computacin Ubicua/2006-2007 Direccionamiento en dos niveles
subnet A: Internet
132.4.16.
subnet B
Redes Inalmbricas
subnet C direccin de
128.8.128. localizacin
Redes
128.8.128.Y
132.4.16.Z
1 direccin esttica
5
4
5
5
1
Redes
Redes Inalmbricas
agent
Home
1
Internet
nodo IP
2
4
agent
Foreign
3
Triangle routing
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Deteccin de movimiento
Problema: como establezco que un nodo ha cambiado de subred?
Redes Inalmbricas
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)
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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 care-
of address
Redes
1
5
9
Tema 4.-
o Configuracin cero
o Whats new?

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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
Redes
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 OSPF-MANET
6
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 multi-
hop diffusion in MANETs, whilst also permitting unicast and multicast
Redes Inalmbricas
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
Redes
(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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 DYMO
DYMO Reactive Protocol like AODV, but with path accumulation

feature
S I1 I2 I3 D
Redes Inalmbricas
RREQ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | TTL |I|A| Res | RREQ RREQ RREQ RREQ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. TargetAddress . RE-S RE-S RE-S RE-S
RE-I1 RE-I1 RE-I1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetSeqNum |
Redes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RE-I2 RE-I2

| THopCnt |Res|
RE-I3
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 RREP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G| RBPrefix |Res| RBHopCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. RBNodeAddress .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RE-
RE-S Route Element with NL of S
| RBNodeSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RE-
RE-I1 Route Element with NL of I1
| NL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
6
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Route Error (RERR)

Optional additional invalid routes
Redes
1
6
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
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
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 OLSR v2
The key optimization of OLSRv2 is that of multipoint relays,
providing an efficient mechanism for network-wide broadcast of link-
state 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 link-
state advertisements (i.e. reduces the number of network-wide
broadcasts) and that these advertisements contain only a subset of
Redes Inalmbricas
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.
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
parameters of maximum delay and minimum bandwidth, and maybe more QoS
parameters
Advantage: ease of integration

Redes
in Internet infrastructure
Disadvantages: Overhead to keep
tables up to date
1 Black nodes: MPRs

6
7
http://www.ietf.org/internet-drafts/draft-badis-manet-qolsr-03.txt
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
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
Redes
multicast forwarding and its applicability is intended to be

constrained within a MANET area.
1
6
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Hot Topics
reas de inters del MobiHoc 2006 y el programa final:
o Applications, operating system, and o Tutorial 1: Wireless Mesh Networks:
middleware support Fundamentals, Basic Protocols and
o Transport, network, and MAC protocols Research Issues
o Energy-efficient algorithms o Tutorial 3: Pervasive Environments:

o Quality of Service issues Challenges and Solutions
o Location discovery techniques o Tutorial 5: Design Guidelines for Network
Layer Protocols in Ad Hoc and Sensor
o Network scaling and limits Networks
o Cross layer design o Tutorial 2: Wireless Mesh Networks:
o Network resilience, fault-tolerance, and Applications, Testbeds, Products and
reliability Standards
Redes Inalmbricas
o Trust, security and privacy o Tutorial 4: Delay/Disruption Tolerant

o Distributed sensing, actuation, control, and Networking
coordination o Tutorial 6: Multimedia Conferencing in
o Measurements and practical experience Mobile Ad Hoc Networks: Challenges and
from experimental systems and testbeds Early Approaches
o Modeling and performance evaluation o Technical Session 1: Routing and
Redes
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
1 o Technical Session 8: Sensor Networks
6
9
Tema 4.-
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

Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Object-oriented
o Mixed C++ and Otcl
Most UNIX and UNIX-like systems
Redes
o FreeBSD
o Solaris
o Linux
Window 95/98/NT/2K
o Works, but with an effort
1
7
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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.
Redes Inalmbricas
Modify NS-2 to implement your own versions of the above protocols

or even code totally new protocols
Measurement of Statistics:
Redes
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
3
7
1
Redes
Redes Inalmbricas
NS input & output
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Basic tcl
proc
proc test
test {}
{} {{
set
set aa 43
43
set
set bb 27
27
set
set cc [expr
[expr $a$a ++ $b]
$b]
set
set dd [expr
[expr [expr
[expr $a$a -- $b]
$b] ** $c]
$c]
for
for {set
{set kk 0}
0} {$k
{$k << 10}
10} {incr
{incr k}
k} {{
if
if {$k
{$k << 5}
5} {{
Redes Inalmbricas
puts
puts "k"k << 5,
5, pow
pow == [expr
[expr pow($d,
pow($d, $k)]"
$k)]"
}} else
else {{
puts
puts "k"k >=
>= 5,
5, mod
mod == [expr
[expr $d
$d %% $k]"
$k]"
}}
Redes
}}
}}
test
test
1
7
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Basic OTcl
Class
Class mom
mom
mom
mom instproc
instproc greet
greet {}
{} {{
$self
$self instvar
instvar age_
age_
puts
puts "$age_
"$age_ years
years old
old mom:
mom: How
How are
are you
you doing?"
doing?"
}}
Class
Class kid
kid -superclass
-superclass mom
mom
kid
kid instproc
instproc greet
greet {}
{} {{
$self
$self instvar
instvar age_
Redes Inalmbricas
age_
puts
puts "$age_
"$age_ years
years old
old kid:
kid: What's
What's up,
up, dude?"
dude?"
}}
set
set aa [new
[new mom]
mom]
Redes
$a
$a set
set age_
age_ 45
45
set
set bb [new
[new kid]
kid]
$b
$b set
set age_
age_ 15
15
$a
$a greet
greet
$b
$b greet
greet
1
7
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Hello World - Interactive Mode
swallow
swallow 71%
71% ns
ns
%% set
set ns
ns [new
[new Simulator]
Simulator]
_o3
_o3
%% $ns
$ns at
at 11 puts
puts \Hello
\Hello World!\
World!\
11
%% $ns
$ns at
at 1.5
1.5 exit
exit
22
Redes Inalmbricas
%% $ns
$ns run
run
Hello
Hello World!
World!
swallow
swallow 72%
72%
Redes
1
7
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Hello World - Batch Mode
simple.tcl
simple.tcl
set
set ns
ns [new
[new Simulator]
Simulator]
$ns
$ns at
at 11 puts
puts \Hello
\Hello World!\
World!\
$ns
$ns at
at 1.5
1.5 exit
exit
$ns
$ns run
run
swallow
swallow 74%
74% ns
ns simple.tcl
simple.tcl
Hello
Hello World!
World!
Redes Inalmbricas
swallow
swallow 75%
75%
Redes
1
7
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Anatomy of NS Scripts
Create the event scheduler

Create network
Create protocol agents (connections)

Generate traffic
Turn on tracing
Setup routing
Redes Inalmbricas
Insert errors
Start event scheduler
Redes
1
7
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Start scheduler (the end of your script!)

o $ns run
Redes
1
7
9
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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>
Redes Inalmbricas
o <queue_type>: DropTail, RED, CBQ, FQ
application application
Redes
agent agent
attach-agent attach-agent
Node Link Node
1
8
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Creating Connections: TCP
TCP
o set tcp [new Agent/TCP]
o set tcpsink [new Agent/TCPSink]

o $ns attach-agent $n0 $tcp
o $ns attach-agent $n1 $tcpsink
o $ns connect $tcp $tcpsink
Redes Inalmbricas
Redes
agent agent
Node Link Node
1
8
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Creating Traffic: On Top of TCP
FTP
o set ftp [new Application/FTP]
o $ftp attach-agent $tcp

Redes Inalmbricas
Redes
agent agent
Node Link Node
1
8
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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]
Redes Inalmbricas
Inserting Error Module

o $ns lossmodel $loss_module $n0 $n1
Redes
1
8
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Trace packets on all links in nam-1 format

o $ns namtrace-all [open test.nam w]
Redes
1
8
4
5
8
1
Redes
Redes Inalmbricas
Simple Simulation Example
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
#Open the general trace file

Set f [open out.tr w]
Redes
$ns trace-all $f
1
8
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 TCL Script Step 2
#Create four nodes

set n0 [$ns node]
set n1 [$ns node]

set n2 [$ns node]
set n3 [$ns node]
Redes Inalmbricas
#Create links between the nodes

$ns duplex-link $n0 $n2 2Mb 10ms DropTail
$ns duplex-link $n1 $n2 2Mb 10ms DropTail
Redes
$ns duplex-link $n2 $n3 1.7Mb 20ms DropTail
1
8
7
Ubicua/2006-2007
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
Redes Inalmbricas
set sink [new Agent/TCPSink]

$ns attach-agent $n3 $sink
$ns connect $tcp $sink
Redes
#Setup a FTP over TCP connection

set ftp [new Application/FTP]
$ftp attach-agent $tcp
1
8
8
Ubicua/2006-2007
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
Redes Inalmbricas
#Setup a CBR over UDP connection

Redes
set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp
$cbr set packet_size_ 1000
$cbr set rate_ 1mb
1
8
9
Ubicua/2006-2007
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"
Redes Inalmbricas
Redes
#Call the finish procedure after 5 seconds of simulation time

$ns at 5.0 "finish"
1
9
0
Ubicua/2006-2007
TCL Script Step 6
#Define a 'finish' procedure

proc finish {} {
global ns nf
$ns flush-trace
#Close the NAM trace file
close $nf
Redes Inalmbricas
#Execute NAM on the trace file

exec nam out.nam &
exit 0
Redes
#Run the simulation

$ns run
1
9
1
2
9
1
Redes
Redes Inalmbricas
Observing the behaviour using nam
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Analyze trace file
Use some tools, like AWK or Perl, to analyze the trace file
Use excel or xplot to plot the results
+ 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
r 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
Redes Inalmbricas
- 0.0028 0 1 tcp 1000 ------- 0 2.0 1.0 0 0

r 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
Redes
- 0.009884 1 2 ack 40 ------- 0 1.0 2.0 0 1

r 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
r 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
Tema 4.-
Introduccin al simulador NS-2
o NS to simulate wireless network

Ubicua/2006-2007
Computacin Ubicua/2006-2007 Wireless Simulation in ns-2
Contributed from CMUs Monarch project (Wireless extension to ns-

2)
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)
Redes Inalmbricas
o MAC802.11
o Radio Propagation Model
o Channel
Redes
1
9
5
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
o Configure multi hop routes for packets

LL (Link Layer)
o Runs data link protocols
o Fragmentation and reassembly of packet
Redes
o Runs Address Resolution Protocol(ARP) to resolve IP address to MAC

address conversions
1
9
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
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.
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 A first example
The file simple-wireless.tcl is under <NSRoot>/ns-allinone2.1b9/ns-
tutorial/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

Redes Inalmbricas
Redes
1
9
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
set val(ll) LL ;# Link layer type

set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set val(ifqlen) 50 ;# max packet in ifq
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Setting Up Variables
#Instantiate simulator object

set ns_ [new Simulator]
#Setup Trace File

set tracefd [open simple.tr w]
$ns_ trace-all $tracefd
Redes Inalmbricas
#Create Topography
set topo [new Topography]
$topo load_flatgrid 500 500
Redes
#Create Object God

create-god $val(nn)
2
0
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Configuring Mobilenode
# Configure nodes
$ns_ node-config -adhocRouting $val(rp) -llType $val(ll) \
-macType $val(mac) -ifqType $val(ifq) \

-ifqLen $val(ifqlen) -antType $val(ant) \
-propType $val(prop) -phyType $val(netif) \
-topoInstance $topo -channelType $val(chan) \
Redes Inalmbricas
-agentTrace ON -routerTrace ON \
-macTrace OFF -movementTrace OFF
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
$node_(1) set Z_ 0.0
Create Movement
Redes
# Node_(1) starts to move towards node_(0)

$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0"
# Node_(1) then starts to move away from node_(0)
2
0
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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]
Redes Inalmbricas
$ftp attach-agent $tcp $ns_ at 10.0 "$ftp start"
FTP
Redes
TCP Sink
node_(0) node_(1)
2
0
3
Ubicua/2006-2007
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...\" ;
Redes Inalmbricas
$ns_ halt" proc stop {} { global ns_ tracefd close $tracefd }
Finally, Start The Simulation

Redes
puts "Starting Simulation..."

$ns_ run
2
0
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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,
Redes Inalmbricas
1060: packet size,

13a(hex): expected duration of pkt transmission (not working),
1: sender mac id,
0: transmitter mac id,
Redes
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
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
o See:
ns-2/tcl/ex/wireless-demo-csci694.tcl
Redes
2
0
6
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Another simple wireless simulation(2)
#Define Global Variables

set ns_ [new Simulator] ; create a ns simulator instance
set topo [new Topography] ; create a topology and

$topo load_flatgrid 670 670 ; define it in 670x670 area
#Define standard ns/nam trace
Redes Inalmbricas
set tracefd [open 694demo.tr w]

$ns_ trace-all $tracefd
set namtrace [open 694demo.nam w]
Redes
$ns_ namtrace-all-wireless $namtrace 670 670
#Create God God is used to store an array of the shortest

number of hops required to reach from one
set god_ [create-god 3] node to an other.
CAN BE OMITTED!!
2
0
7
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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 \
Redes Inalmbricas
-antType Antenna/OmniAntenna \
-propType Propagation/TwoRayGround \
-phyType Phy/WirelessPhy \
Redes
-channelType Channel/WirelessChannel \
-topoInstance $topo
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
2
0
8
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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:

Redes Inalmbricas
for {set i < 0} {$i<3} {incr i} {

set node_($i) [$ns_ node]
Redes
2
0
9
Ubicua/2006-2007
Computacin Ubicua/2006-2007 Another simple wireless simulation: Movement file
$ns_ at 50.000000000000 "$node_(2) setdest 369.463244915743 170.519203111152

3.371785899154"
14.909259208114"
19.153832288917"
$node_(2) set Z_ 0.000000000000
$node_(2) set Y_ 199.373306816804
Redes Inalmbricas
$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
$node_(1) set X_ 257.046298323157
e.g., scen-3-test
Redes
$node_(0) set Z_ 0.000000000000

$node_(0) set Y_ 239.438009831261
$node_(0) set X_ 83.364418416244
2
1
0
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
$cbr_(0) attach-agent $udp_(0)

$ns_ connect $udp_(0) $null_(0)
#Define traffic model
$ns_ at 127.93667922166023 "$cbr_(0) start"
source traffic-scenario-files
set tcp [new Agent/TCP] e.g., cbr-3-test
Redes
$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"
2
1
1
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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

Redes Inalmbricas
$ns_ at 200.0 $ns_ nam-end-wireless 200.00

$ns_ at 200.00 $ns_ halt
#Start your simulation

Redes
$ns_ run
2
1
2
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
and the output will be written in a file called scen-20-test.
Random movement
Redes
$node start
See ns-2/indep-utils/cmu-scen-gen/setdest/
2
1
3
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Generating TCP traffic patterns

o ns cbrgen.tcl -type tcp -nn 25 -seed 0 -mc 20
Redes
See ns-2/indep-utils/cmu-scen-gen/
2
1
4
Ubicua/2006-2007
Computacin Ubicua/2006-2007 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
Redes Inalmbricas
Blueware: Bluetooth Simulator for ns

o http://nms.lcs.mit.edu/projects/blueware/
BlueHoc: Bluetooth Performance Evaluation Tool
Redes
o http://www-124.ibm.com/developerworks/opensource/bluehoc/
2
1
5

Redes Manet PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Redes Manet PDF

Cargado por

Copyright:

Formatos disponibles

Tema 4.

Redes Inalmbricas y Computacin Ubicua/2006-2007

Redes formadas por nodos mviles con conexin inalmbrica.

o Existen soluciones hbridas conocidas como redes mesh

Disponer de infraestructura cableada fija o puntos de acceso no

Las redes ad hoc

o Cooperative driver assistance:

o Decentralized floating car data:

Entorno completamente simtrico

Entornos asimtricos; pueden variar:

o relativas al medio inalmbrico

MANETs Mobile ad hoc networking: imperatives and challenges,

Redes Inalmbricas y Computacin Ubicua/2006-2007

o Which is the best path?

Shortest time (lowest latency)

Source specifies entire route

Intermediate nodes look at destination in header, consult internal tables to

o Sleep period operation

Rate of link failure/repair may be high when nodes move fast

o Los tradicionales protocolos link-state y distance-vector son proactivos

Aspectos a tener en consideracin

Los protocolos reactivos pueden tener mayor latencia

IETF WG: Mobile Ad-hoc Networks (manet)

Purpose of MANET working group

Approaches are intended to be:

Using mature components from previous work on experimental

o Reactive MANET Protocol (RMP)

Both IPv4 and IPv6 will be supported.

Done Discuss proposed protocols and issues. Redefine charter.

Done Publish Informational RFC on manet design considerations

Done Review the WG Charter and update

Done Submit AODV specification to IESG for publication as Experimental RFC

Done Promote implementation, revision, and testing of initial proposed I-D(s)

Done Explore basic performance and implementation issues of initial approaches

Done Explore proposed proactive protocol design commonalities

Done Submit DSR specification to IESG for publication as Experimental RFC

Done Submit OLSR specification to IESG for publication as Experimental RFC

Done Submit TBRPF specification to IESG for publication as Experimental RFC

Mar 05 Submit initial ID of RMP for WG review

Mar 05 Submit initial ID of PMP for WG review

Mar 05 Submit inital ID of generalized MANET flooding approach

Jun 05 Revise WG documents and review

1 Mar 06 Review and update milestones

(AODV) Routing. Request for Comments (Experimental) 3561, July 2003.

R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-Path

Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004.

T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausen-

(AODV) Routing. Request for Comments (Experimental) 3561, July 2003.

R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-Path

Forwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004.

T. Clausen. The Optimized Link-State Routing Protocol version 2, draft-clausen-

Una primera nodo que acaba de enviar una trama

nodo que acaba de recibir una trama

nodo que acaba de recibir una trama

recibe la trama pero no la

nodo que acaba de recibir una trama

nodo que acaba de recibir una trama

D no reenva por que es el

nodo que acaba de recibir una trama

o Ej.: en el caso que los nodos

Redes Inalmbricas y Computacin Ubicua/2006-2007

David B. Johnson, David A. Maltz, Yih-Chun Hu, The Dynamic

Redes de tamao medio (200 nodos), admite altas velocidades