Unidad 2 Redes Manet

Redes Inalámbricas y Computación Ubicua/2006-2007

Tema 4.-Redes inalámbricas Ad Hoc

A. Conceptos generales B. Encaminamiento

i. DSRii. AODViii. OLSR

C. Calidad de servicioD. Control de potencia

Nitin H. Vaidya, “Tutorial on Mobile Ad Hoc Networks: Routing, MAC and Transport Issues” disponible en http://www.crhc.uiuc.edu/wireless/tutorials.htmlagradecimientos/acknowledgments

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

2

Mobile Ad-hoc Networks (MANETs)

Redes formadas por nodos móviles con conexión inalámbrica.No utilizan ninguna infraestructura preexistente

o Existen soluciones híbridas conocidas como “redes mesh”En una MANET la movilidad ha un importancia crucial.

o Las rutas varían en el tiempoo Problemas de particionamiento

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

3

¿Porqué las redes ad hoc?

Disponer de infraestructura cableada fija o puntos de acceso no siempre es posible o viable

o No resulta práctico en entornos civiles de carácter temporalo No se disponeo Puede haber sido destruida, por ejemplo en entornos de desastres

naturales

Las redes ad hoco Se pueden desplegar de forma flexible en entornos que no disponen de

infraestructura fija

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

4

Un caso “ejemplar”: Traffic networks

“Coches inteligentes” y “carreteras inteligentes”. Los sistemas de abordo “hablan” con la “carreteras”.

Por ejemplo: FleetNet – Internet on the Road. Ad Hoc Radio Network for Inter-Vehicle Communications

o http://www.fleetnet.de

Ofrece:o Cooperative driver assistance:

Emergency notificationOvertaking assistanceObstacle warning

o Decentralized floating car data:Traffic jam monitorDynamic navigationRoute weather forecast

o User communications andinformation services:

Hot-spot Internet accessInter-vehicle chatDistributed games

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

5

Varios tipos

Entorno completamente simétricoo todos los nodos tiene capacidades y responsabilidades idénticas

Entornos asimétricos; pueden variar:o Los radios de transmisión o La duración de las bateríaso La capacidad de procesoo Capacidad de encaminamientoo Las tecnologías utilizadas

A menos que esté indicado de otra manera, se asume implícitamente el entorno completamente simétrico en el que todos los nodos tienen idénticas capacidades y responsabilidades

A menos que esté indicado de otra manera, se asume implícitamente el entorno completamente simétrico en el que todos los nodos tienen idénticas capacidades y responsabilidades

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

6

Retos de las redes ad hoc

Cómo encaminar paquetes entre estacionesCómo hacerlo de forma eficienteOtros retos:o Calidad de servicioo Configuracióno Descubrimiento de servicioso Seguridad y privacidado Prestaciones TCPo ...

Limitaciones de las redes ad hoc o relativas al medio inalámbrico

Radio de transmisión limitado (Encaminamiento complejo)

Ancho de banda reducidoErrores de transmisión/perdidas de paquetesSeguridad restringida

o relativas al carácter móvil de las estacionesTopología dinámicas (rutas dinámicas)Energía reducida

[Corson99] , S. Corson and J. Macker, “Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”, RFC 2501, January 1999.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

7

Visión general

“Mobile ad hoc networking: imperatives and challenges”, Imrich Chlamtac, Marco Conti, Jennifer J.-N. Liu, Ad Hoc Networks, Elsevier, 1 (2003).

segu

ridad

sensores

IPze

roco

nfTCPTCP/UDP

MobileIP

IEEE 802.11 Bluetooth

aplicacionesMiddleware

MANETs





C. Calidad de servicio

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

9

Routing Overview

Network with nodes, edgesGoal: transfer message from one node to another

o Which is the “best” path?o Who decides - source or

intermediate nodes?

msg

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

10

Routing Overview

Which path?o Generally try to optimize one of the following:

Shortest path (fewest hops)Shortest time (lowest latency)Shortest weighted path (utilize available bandwidth, battery)

Who determines route?o Source (“path”) routing [Like airline travel]

Source specifies entire routeIntermediate nodes just forward to specified next hop

o Destination (“hop-by-hop”) routing [Like postal service]Source specifies only destination in message headerIntermediate nodes look at destination in header, consult internal tables to determine appropriate next hop

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

11

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 StartingAdapt to network conditionsQualitative Properties

o Distributed operation o Loop Freedomo Demand Based Operationo Security o Sleep period operationo Unidirectional link support

Quantitative Propertieso End-to-End data throughputo Delayso Route Acquisition timeo Out of order delivery (percentage)o Efficiency

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

12

Why is Routing in MANET different ?

Host mobilityo link failure/repair due to mobility may have different characteristics than

those due to other causesRate of link failure/repair may be high when nodes move fastNew performance criteria are used

o route stability despite mobilityo energy consumptiono host position

Dynamic Solution much more difficult to be deployed

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

13

Tipos de protocolos de encaminamiento

Protocolos proactivoso Determinan las rutas independientemente del modelo de tráfico o Los tradicionales protocolos link-state y distance-vector son proactivos

Protocolos reactivoso Mantiene las rutas solamente si es necesario

La tercera vía: los protocolos híbridosAspectos a tener en consideración

o Tiempo de espera para el descubrimiento de la rutaLos protocolos proactivos normalmente tienen una latencia menor gracias al uso de cachesLos 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 rutaLos protocolos reactivos pueden tener un overhead menor por que buscan las rutas únicamente cuando es necesarioLos protocolos proactivos pueden tener un overhead mayor por que siempre están actualizando las rutas

¡¡Que solución adoptar depende del tipo di trafico y del tipo de movilidad!!¡¡Que solución adoptar depende del tipo di trafico y del tipo de movilidad!!

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

14

manet Working Group

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

Purpose of MANET working groupo standardize IP routing protocol functionality suitable for wireless routing

application within both static and dynamic topologies with increased dynamics due to node motion or other factors.

Approaches are intended to be:o relatively lightweight in natureo suitable for multiple hardware and wireless environments, and address

scenarioso MANETs are deployed at the edges of an IP infrastructureo hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers)

should also be supported by MANET specifications and management features.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

15

Description of Working Group

Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications:

o Reactive MANET Protocol (RMP)o Proactive MANET Protocol (PMP)

Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

16

Goals and Milestones

Review and update milestonesMar 06

Submit MANET flooding specification to IESG for publication as Experimental StandardFeb 06

Submit PMP specification and supporting documentation to IESG for publications as Proposed StandardFeb 06

Submit RMP specification and supporting documentation to IESG for publications as Proposed StandardFeb 06

Document initial implementation progress and experience Revise documents based upon implementation experienceNov 05

Revise WG documents and reviewJun 05

Submit inital ID of generalized MANET flooding approachMar 05

Submit initial ID of PMP for WG reviewMar 05

Submit initial ID of RMP for WG reviewMar 05

Reevaluate the WG's potential based on the problem statement consensusDone

Develop a further focused problem statement and address an approach for a common engineering work effortDone

Submit TBRPF specification to IESG for publication as Experimental RFCDone

Submit OLSR specification to IESG for publication as Experimental RFCDone

Submit DSR specification to IESG for publication as Experimental RFCDone

Explore proposed proactive protocol design commonalitiesDone

Explore basic performance and implementation issues of initial approachesDone

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

Submit initial I-D(s) of candidate proposed routing protocols and design frameworksDone

Develop I-D for potential common manet encapsulation protocol approachDone

Submit AODV specification to IESG for publication as Experimental RFCDone

Review the WG Charter and updateDone

Publish Informational RFC on manet design considerationsDone

Discuss proposed protocols and issues. Redefine charter.Done

Agenda bashing, discussion of charter and of mobile ad hoc networking draft.Done

Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues.Done

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

17

Protocolos propuestos

D. Johnson, D. Maltz, and Y-C. Hu. The Dynamic Source Routing Protocol for MobileAd 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.txtC. 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.txtT. Clausen and P. Jacquet. Optimized Link State Routing Protocol OLSR. Request forComments (Experimental) 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt

R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-PathForwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004. http://www.ietf.org/rfc/rfc3684.txtI. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET On-demand(DYMO) Routing, draft-ietf-manet-dymo-02.txt. Internet Draft (work in progress), June2005. http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-02.txtT. 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.txtJ. 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 más:o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

18

Protocolos propuestos

D. Johnson, D. Maltz, and Y-C. Hu. The Dynamic Source Routing Protocol for MobileAd 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.txtC. 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.txtT. Clausen and P. Jacquet. Optimized Link State Routing Protocol OLSR. Request forComments (Experimental) 3626, October 2003. http://www.ietf.org/rfc/rfc3626.txt

R. Ogier, F. Templin, and M. Lewis. Topology Dissemination Based on Reverse-PathForwarding (TBRPF). Request for Comments (Experimental) 3684. February 2004. http://www.ietf.org/rfc/rfc3684.txtI. Chakeres, E. Belding-Royer, and C. Perkins. Dynamic MANET On-demand(DYMO) Routing, draft-ietf-manet-dymo-02.txt. Internet Draft (work in progress), June2005. http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-02.txtT. 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.txtJ. 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 más:o http://en.wikipedia.org/wiki/Ad_hoc_protocol_list

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

19

Uso del flooding para la entrega de datos

A

B

S

H

C

E

Z

I

G

F

KN

L

J

M

D

Y

nodo que acaba de recibir una trama

envio broadcast de una trama

nodo que acaba de enviar una trama

destino

Una primera solución se basa en utilizar floodingcontrolado

Una primera solución se basa en utilizar floodingcontrolado

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

20


A

B

S

H

C

E

Z

I

G

F

KN

L

J

M

D

Y

posible colisión!!




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

21


A

B

S

H

C

E

Z

I

G

F

K

N

L

J M

D

Y

recibe la trama pero no la reenvía por que ya lo ha hecho




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

22


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

recibe la trama de J y de K (entre ellos son hidden) posible colisión




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

23


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

D no reenvía por que es el destino final




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

24


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

El flooding ha teminado!El flooding ha teminado!




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

25


VentajasSencilloEs más eficiente si la tasa de envío es baja el overhead de los procesos de búsqueda y mantenimiento de rutas explicitas resulte ser más alto

o Ej.: en el caso que los nodos transmitan pocos mensajes de tamaño pequeño y que la topología varíe muy a menudo

Potencialmente la entrega de los datos es más fiable, por que se pueden utilizar múltiples rutas.

DesventajasOverhead potencialmente muy alto

o en el peor de los casos todos los nodos alcanzable por el nodo fuente recibirán los datos

Potencialmente la entrega de los datos es menos fiable a causa del uso de difusiones.

o Ej.: las difusiones con el MAC de IEEE 802.11 son pocos fiables

¿?

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.






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

27

Dynamic Source Routing (DSR)

David B. Johnson, David A. Maltz, Yih-Chun Hu, “The DynamicSource Routing Protocol for Mobile Ad Hoc Networks”, <draft-ietf-manet-dsr-10.txt>

Redes de tamaño medio (200 nodos), admite altas velocidadesCuando el nodo S desea enviar un paquete al nodo D, pero no tieneuna ruta hacia D, inicia un descubrimiento de la ruta (routediscovery). El nodo fuente S hace un flooding de Route Request (RREQ)Cada nodo añade su propio identificador cuando reenvía un RREQ. Uso del “send buffer”Uso de RREQ identifier

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

28

Uso del Route Request en DSR

A

B

S [S]

H

C

E

I

G

F

KN

J

M

D

destino

L

nodo que acaba de recibir una RREQ

lista de IDs añadidos al RREQ

nodo que acaba de enviar una RREQ

[X,Y]

Y

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

29


A

B

S

H

C [S,C]

E [S,E]

Z

I

G

F

KN

L

J

M

D

Y

posible colisión!!

L




[X,Y]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

30


A

B

S

H

C

E

Z

I

G [S,C,G]

F [S,E,F]

K

N

L

J M

D

Y

recibe el RREQ pero no lo reenvía por que ya lo ha hecho

L




[X,Y]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

31


A

B

S

H

C

E

Z

I

G

F

K[S,C,G,K]

N

L

J [S,E,F,J]M

D

Y


L




[X,Y]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

32


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M [S,E,F,J,M]

D

Y


L




[X,Y]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

33

Uso del Route Reply

En destino D al recibir el primer RREQ envía un RouteReply (RREP)RREP se envía usando la ruta obtenida invirtiendo la que está en el RREQ que se ha recibido

Y

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

RREP [S,E,F,J,D]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

34

Route Reply en DSR

El Route Reply puede ser enviado invirtiendo la ruta en el RouteRequest (RREQ) solo si tenemos la garantía 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 (asimétricos) entonces el RREP tiene que utilizar un route discovery desde D hacia S

o A menos que D ya tenga una ruta hacia So Si un route discovery es iniciado por D hacia S, entonces el Route Reply

es piggybacked hacia S desde D.

El uso del estándar IEEE 802.11 para enviar datos implica que los canales son bi-direccionales (por que se utilizan los ACKs)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

35

Dynamic Source Routing (DSR)

Cuando el nodo S recibe el RREP, memoriza en cache la ruta

Cuando el nodo S envía un paquete de datos a D, la ruta está incluida en la cabecera

o por eso el nombre de source routing

Los nodos intermedio utilizan solo y únicamente la ruta incluida en la cabecera para saber a quien tienen que reenviar el paquete.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

36

Data Delivery in DSR

La cabecera de los paquetes va creciendo al aumentar de la longitud de la ruta

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y

DATA [S,E,F,J,D]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

37

Optimizaciones de DSR: Route Caching (1/2)

Cada nodo guarda en cache todas las rutas que pueda descubrir1. Cuando el nodo S descubre la ruta [S,E,F,J,D] hacia el nodo D, el

nodo S descubre también la ruta [S,E,F] hacia el nodo F2. 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 S3. 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 D4. Cuando el nodo E retransmite Data [S,E,F,J,D] descubre la ruta

[E,F,J,D] hacia el nodo D

A

B

S

H

C

E

Z

I

G

F

KN

L

J

M

D

Y

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

38

Optimizaciones de DSR: Route Caching (2/2)

Los nodos, además pueden descubrir rutas por medio del overhearingUso de las caches:

o Cuando un nodo X recibe un Route Request para un nodo D y tiene en su cache una ruta hacia ese nodo puede contestar directamente

o Cuando el nodo S descubre que una ruta al nodo D está interrumpida, utiliza otra ruta, si existe, de su cache local. Si no, el nodo S comienza un route discovery

Posible problema del uso de las caches:o en entornos altamente móviles el uso de las caches puede afectar las

prestaciones

A

B

S

H

C

EZ

I

G

F

KN

L

JM

D

Y

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

39

Route Error (RERR)

J envía un route error a S utilizando la ruta J-F-E-S cuando su intento de entregar el paquete de datos a D fallaLos nodos que escuchan el RERR actualizan sus cachesCada nodo es responsable de confirmar que ese enlace se puede utilizar para transmitir datos.

o Ack del MAC (p.ej., 802.11)o Passive ackso DSR-specific ACK

Y

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

RERR [J-D]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

40

Características adicionales

Técnica del “Expading ring” en la búsqueda de rutas utilizando el campo TTL de los paquetes

o “non propagating” Route RequestTécnica de “Route salvaging” en el mantenimiento de las rutas

o Sustitución dinámica de las rutas por nodos intermedioso El numero de salvamientos es limitado

Técnica de “Automatic route shortening” para optimizar las rutaso Uso de “gratuitous” Route Reply

Uso de flujos de datos: los “flows”

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

41

DSR: ventajas y desventajas

Se gestionan solo las rutas entre nodos que quieren comunicarse

o se reduce la carga para mantener varias rutas

El uso de la cache puede reducir la carga de futuros procesos de routediscovery

Un solo proceso de RR puede producir variar rutas hacia el destino gracias a las respuestas de las caches de los nodos intermedios

El tamaño de la cabecera crece al crecerde la ruta debido al uso del sourceroutingEl flooding de las peticiones de ruta puede potencialmente alcanzar todos los nodos en la red. Hay que evitar las colisiones producidas por la retransmisión de los RREQ

o se insertan retardos aleatorio antes de enviar el RREQ.

Aumento de la contienda para el acceso al canal si se producen demasiadas RR por nodos que usan sus caches

o Problema de la tormenta de Route Reply.

o se puede evitar forzando un nodo a no enviar un RREP si escucha otro RREP con una ruta más corta

Un nodo intermedio puede corromper las caches de otros nodos enviando RREP utilizando una cache obsoleta






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

43

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 3561El DSR incluye el encaminamiento fuente en la cabecera de los paquetes. Si el tamaño de los paquetes resultantes es muy grandepuede afectar a las prestaciones, sobre todo si los paquetes de datos son pequeñosAODV intenta mejorar DSR utilizando tablas de encaminamiento en los nodos de forma que los paquetes no tengan que llevar información sobre de la rutaAODV mantiene la característica del DSR que las rutas son mantenidas solo para los nodos que quieren comunicar

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

44

Distance Vector

Basic Routing Protocolo known also as Distributed Bellman-Ford or RIP

Every node maintains a routing tableo all available destinationso the next node to reach to destinationo the number of hops to reach the destination

Periodically send table to all neighbors to maintain topologyBi-directional links are required!

Thanks to Raoul Reuter

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

45

Distance Vector (Tables)

C

0BB

1AA

2CC

…MetricNextDest.

1BB

0AA

3BC

…MetricNextDest.

1 2

2BB

3BA

0CC

…MetricNextDest.

BA


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

46

(A, 1)(B, 0)(C, 1)

(A, 1)(B, 0)(C, 1)

Distance Vector (Update)

C

0BB

1AA

1CC

…MetricNextDest.

1BB

0AA

3 2BC

…MetricNextDest.

1 1

1BB

3 2BA

0CC

…MetricNextDest.

BA

B broadcasts the new routing information to his neighbors

Routing table is updated


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

47

(D, 0)

(A, 2)(B, 1)(C, 0)(D, 1)

(A, 1)(B, 0)(C, 1)(D, 2)

Distance Vector (New Node)

C1 1

BA D1

broadcasts to update tables of C, B, A with new entry for D

1DD

0CC

1BB

2BA

…MetricNextDest.

2CD

0BB

1AA

1CC

…MetricNextDest.

3BD

1BB

0AA

2BC

…MetricNextDest.


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

48

(D, 2)(D, 2)

Distance Vector

Broken Link and consequent Loops…

C1 1

BA D1

3BD

………

…MetricNextDest.

2CD

………

…MetricNextDest.

3BD

………

…MetricNextDest.


C1 1

BA D1

2CD

………

…MetricNextDest.c

3BD

………

…MetricNextDest.

1BD

………

…MetricNextDest.

∞DD

………

…MetricNextDest.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

49

(D,2)

(D,4)

(D,3)

(D,5)

(D,2)

(D,4)

Distance Vector

… create the “Count to Infinity” problem

C1 1

BA D1

3, 5, …BD

………

…MetricNextDest.

3, 5, …BD

………

…MetricNextDest.

2, 4, 6…CD

………

…MetricNextDest.c


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

50

Distance Vector

Issues in ad-hoc networks:o Loops

Bandwidth reduction in networkUnnecessary work for loop nodes

o Count to InfinityVery slow adaptation to topology changes.


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

51

AODV

Los mensajes de Route Requests (RREQ) son reenviados de manera similar a DSR

Cuando un nodo retransmite un Route Request, activa también una ruta inversa que apunta a la fuente

o AODV supone canales bidireccionales

Cuando el destino recibe el Route Request, responde enviando un Route Reply

El Route Reply recorre la ruta activada a través del envío del RouteRequest

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

52

Envio del Route Request

A

B

S

H

C

E

Z

I

G

F

KN

L

J

M

D

Y


envió broadcast de una trama RREQ


destino

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

53


A

B

S

H

C

E

Z

I

G

F

KN

L

J

M

D

Y

posible colisión!!




Links de la ruta inversa

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

54


A

B

S

H

C

E

Z

I

G

F

K

N

L

J M

D

Y

recibe la trama pero no la reenvía por que ya lo ha hecho





Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

55


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

56


A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

57

Envio del Route Reply

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

Y





Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

58

Setup del la ruta de envío

A

B

S

H

C

E

Z

I

G

F

K

N

L

J

M

D

YLos enlaces de la ruta de envío son establecido cuando el mensaje de RREP recorre la ruta inversa

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

59

Route Reply in AODV

Detalles sobre el uso del route replyo Un nodo intermedio (no el destino final) puede también enviar un Route

Reply (RREP) si conoce una ruta más reciente que la que “se sabe” el sender S

o Para determinar se la ruta conocida por un nodo intermedio es más reciente se utilizan los destination sequence numbers

Si Node:dsn >= RREQ:dsn no reenvioo La probabilidad que un nodo intermedio envíe un Route Reply es inferior

en AODV que en DSRUn Route Request nuevo desde S para un destino se le asigna un destinationsequence number más alto. Un nodo intermedio que conoce la ruta, pero con un numero de secuencia más pequeño, no puede enviar un Route Reply

Timeoutso Una entry de una tabla de encaminamiento que esta memorizando un

reverse path es cancelada después de un intervalo de timeouteste intervalo tiene que ser suficientemente largo para que el RREP pueda volver hacia atrás

o Una entry de una tabla de encaminamiento que esta memorizando un forward path es cancelada si no utilizada después de un intervalo active_route_timeout

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

60

Notificación sobre interrupción 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 deel intervalo active_route_timeout , paquete que ha sido reenviado utilizando esa entryCuando una una enlace 1-hop in una tabla de encaminamiento se interrumpe, se avisan a todos los vecinos activoLas interrupciones de enlaces se propagan utilizando los mensajes de Route Error, que también sirven para actualizar los destinationsequence numbers

o cuando un nodo X no puede reenviar un paquete desde S a D sobre el link (X,Y), genera un mensaje RERR

o el nodo X incrementa el destination sequence number para D en su cacheo este numero, una vez incrementado (=N) es incluido en el RERRo cuando el nodo S recibe el RERR, activa un un nuevo proceso de búsqueda de D

utilizando un destination sequence number como mínimo de valor igual a No 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

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

61

Link Failure Detection

Hello messages: Neighboring nodes periodically exchange hello message

Absence of hello message is used as an indication of link failure

Alternatively, failure to receive several MAC-level acknowledgement may be used as an indication of link failure

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

62

Por que los Sequence Numbers in AODV

Para evitar la presencia de rutas viejas o no validaso permite determinar cual de las rutas es más nueva

Para prevenir la formación de bucleso Suponiendo que A no sabe nada de la interrupción del enlace C-D por

que el RERR enviado por C se ha perdido

o C efectúa un route discovery buscando a D. EL nodo A recibe el RREQ, por ejemplo vía la ruta C-E-A

o El nodo A contestara por que A conoce una ruta hacia D pasando por Bo Obtenemos un bucle, por ejemplo, C-E-A-B-C

A B C DE

A B C D

E






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

64

Optimized Link State Routing (OLSR)

Thomas Clausen, Philippe Jacquet, Project Hipercom INRIA, “Optimized Link State Routing Protocol”, RFC 3626

Protocolo proactivo basado en una optimización de los clásicos protocolos link-state, como el OSPF. Adapto para redes donde el trafico es random y esporádico entre un gran numero de nodos, y cuando los nodos que intercomunican varían en el tiempoEsta preparado para suportar extensiones, como funcionamiento ensleep mode, routing multicast, etc.No requiere modificar la estructura de los paquetes IP

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

65

LSR vs. OLSR

La sobrecarga de hacer broadcastingde la información sobre el estado de los enlaces se reduce limitando el numero de nodos que reenvían esta información

o Una difusión desde el nodo X es reenviada solo por sus multipointrelays

o Los multipoint relays del nodo X son sus vecinos escogidos de manera que cada vecino two-hopde X sea un vecino one-hop de por lo menos un multipoint relayde X

o Cada nodo transmite su lista de vecinos en mensajes periódicos, de forma que todos los nodos puedan saber cuales son sus vecinos two-hops, para poder escoger sus multipoint relays

Son necesarias 11retransmisiones para difundir el mensaje hasta tres salto de distancia

Son necesarias 24retransmisiones para difundir el mensaje hasta tres salto de distancia

nodo que retransmite

nodo que retransmite

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

66

Terminología

Los nodos pueden tener diferentes interfaces OLSR, cada una con su propia dirección IP

o A cada nodo se le asigna una única dirección IP de referencia (‘main address’)

neighbor: x es vecino de y si y puede ‘escuchar’ la señal de x

o 2-hop neighbor: un nodo cuya señal es recibida por un vecino.

o strict 2-hop neighbormultipoint relay (MPR):

o Un nodo seleccionado por su vecino x, para retransmitir todos los mensajes de difusión que 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

S

M

X YZ

P

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

67

Tablas de encaminamiento

Todos los nodos gestionan una tabla de encaminamientoLa 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 través de R_next_addr. Este nodo se puede alcanzar por medio del interfaz local R_iface_addrHay una entry por cada destino en la redLa tabla se actualiza cada vez que se detecta una cambio de:

o the link set, o the neighbor set, o the 2-hop neighbor set, o the topology set, o the Multiple Interface Association Information Base,

La tabla se construye aplicando un algoritmo de shortest path

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

68

Implementaciones






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

70

Performance issues

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

o Adaptive QoSo 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.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

71

Effects of congestion and mobility: PSNR

Video at 10Hz → 200 seconds interval

Bursty losses

Several consecutiveframes lost (video freezed)

Random losses

More uniformdistortion decay

degradation due to mobility

degradation due to congestion

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

72

Effects of congestion and mobility: jitter

Congestion jitter:

relatively small

frequent variations

Mobility jitter:

very large peaks

occasionaloccurrences on routechange

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

73

Main issues

The main issues to consider to achieve good quality video streamingare:

o MAC level QoS: IEEE 802.11e required to differentiate from bandwidthgreedy 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 routingprotocols 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 overheadUnder high levels of packet loss, random updating intra macroblocks is more effective that using I/P frames combinationsThe use of multiple reference frames proved to be a bad choice

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

74

QoS in MANETs, an integrated vision

QoS Modelo DiffServo IntServo FQMM (Flexible QoS Model for Manet QoS Signalling)

QoS Signallingo INSIGNIA (in-band signalling)o dRSVP(dynamic RSVP)

QoS Routingo QoS enabled routing (AODV/OLSR)o CEDAR(Core-Extraction Distributed Ad-hoc Routing)o Ticket based Probing (distributed QoS routing)

QoS MACo IEEE 802.11eo MACA/PR

(Multiple Access Collision Avoidance with Piggyback Reservation)

o prioritised binary countdown (PBC)... and

o SWAN: integrated proposalMona Ghassemian, King’s College, September 2003

QoS in MANETsQoS in MANETs

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

75

Integrated Services

Attempt to modify Internet service model to support diverse application requirementsAny data flow that desires better than best-effort delivery requests and reserves resources at routers along the patho RSVP is the recommended reservation protocol

If insufficient resources are available, the flow is denied admission into the networkEach router o Maintains reservation state for each flow o Classifies every packet and decides forwarding behavioro Monitors the flow to ensure that it does not consume more than the

reserved resourcesAdvantageso Enables fine-grained QoS and resource guarantees

Disadvantageso Not scalable, harder to administer

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

76

Differentiated Services

Moves admission control and flow monitoring to the edge of the networkEdge nodes classify and mark packets to receive a particular type of service o Diff Serv Code Point (DSCP)o Finite set of DSCPs defined

Interior nodes determine the type of service for forwarded packets based on their DSCP valuesAdvantageso More scalable o No per-flow stateo Easier to administer

Disadvantageso Cannot provide the same per-flow guarantees as IntServ

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

77

FQMM

FQMM is the first QoS Model proposed in 2000 for MANETs by Xiaoet al.The model can be characterized as a “hybrid” IntServ/DiffServ Model as

o the highest priority is assigned per-flow provisioning.o the rest is assigned per-class provisioning.

Three types of nodes:o Ingress (transmit)o Core (forward)o Egress (receive)

1

2

5

34

6 7

ingress

egress

core

Mona Ghassemian, King’s College, September 2003

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

78




QoS Routingo CEDAR(Core-Extraction Distributed Ad-hoc Routing)o QoS enabled routing (AODV/OLSR)o Ticket based Probing (distributed QoS routing)






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

79

QoS Signalling

Signaling is used to reserve and release resources.

Prerequisites of QoS Signallingo Reliable transfer of signals between routerso Correct Interpretation and activation of the appropriate mechanisms to

handle the signal.

Signaling can be divided into “In-band” and “Out-of-band”o In-band: integrated in data packetso Out-of-band: explicit use of control packets

Most papers support that “In-band” Signaling is more appropriate for MANETs.


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

80

INSIGNIA

INSIGNIA is the first signaling protocol designed solely for MANETsby Ahn et al. 1998.

o Lee, S.B., Ahn, G.S., Campbell, A.T., "Improving UDP and TCP Performance in Mobile Ad Hoc Networks with INSIGNIA", June 2001, IEEE Communication Magazine.

Can be characterized as an “In-band RSVP” protocol.o It encapsulates control info in the IP Option field (called now INSIGNIA

Option field).o It keeps flow state for the real time (RT) flows.o It is “Soft State”. The argument is that assurance that resources are

released is more important than overhead that anyway exists.INSIGNA tries to provide something better than best effort service for some flows, e.g., video, voice.

o QoS insensitive flows can be serviced in best effort manner: e-mailo QoS sensitive flows should be treated in better than best effort manner


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

81

INSIGNIA Features

Approacho Adaptive QoS approacho Service Differentiation via packet prioritization

To provide adaptive QOS it uses:o Fast Reservationo Fast Restorationo QoS reporting: a feedback mechanismo Adaptation according to network conditions

Seoung-Bum Lee, COMET Group, Netwokring 2000, Paris

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

82

INSIGNIA Principles

In band signaling -> to be responsive o requires only single packet on new path to initiate the restoration after

reroutingo explicit out-of-band signaling is not responsive enough and often fails to

reach the target mobile nodes

Soft-stateo for management and maintenance of resource reservationso first packet on new path create states (if necessary) and subsequent

packets refresh the previous associated reservations en-routeo outstanding reservations and states automatically time out, typically in

seconds range.


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

83

INSIGNIA IP option

SERVICEMODE

1 bit1 bit 1 bit 16 bits

BANDWIDTHINDICATOR

BANDWIDTH REQUEST

PAYLOADINDICATOR

MAX MINBQ/EQRES/BE BW_IND

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

PAYLOAD INDICATOR : base quality (BQ) packet / enhanced quality (EQ) packet

BANDWIDTH INDICATOR : reflects the resource availability en route

BANDWIDTH REQUEST : indicates the max/min BW requirements


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

84

M1

M2

M3

M4

MS MD

RES/BQ packetRES/EQ packet

Legend

BE packetMAX reserved linkMIN reserved link

QOS report : MAX reservation established

RES BQ MAX Max_BW Min_BW

RES EQ MAX Max_BW Min_BW

Packets Received at Destination Mobile Node

Reservation Set-up


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

85

ReroutingRerouting

M2

M1M3

M4

MS MD

M2

immediate restoration

M2


Legend


Re-routing / Restoration


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

86

M3

M5


Legend


ReroutingRerouting

M1

M4

MS MD

ReroutingRerouting

M3

M5

bottlenecknode

EQ degradation: degraded to minimum service

M5

M3

RES BQ MIN Max_BW Min_BW

BE EQ - Max_BW Min_BW

Packets Received at Destination Mobile Node

Re-routing / Degradation


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

87

QOS report : Scale Down

PersistentEQ degradation

PersistentEQ degradation

M1

M4

MS MD

M5

Scale down to MIN service

bottlenecknode


Legend


QOS report : Scale Down


BE EQ - - -

Packets sent at Source Mobile Node after “Scaling Down” to MINIMUM service

RES BQ MIN Max_BW Min_BW

BE EQ - - -

Pkts Received at Destination after “Scaling Down to MINIMUM service

Adaptation : Scale Down


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

88

bottlenecknode

bottlenecknode

M1

M4

MS MD

QOS report : Scale Up

constant resource availabilitydetected

MAX service re-initiated


Legend


M5

resource now available

QOS report : Scale Up

resource now available

constant resource availabilitydetected


Packets sent by Source Mobile Node in MIN service


Pkts Received at Destination in MIN service

Adaptation : Scale Up


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

89










Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

90

QoS Routing

Routing is an essential component for QoS. It can inform a source node of the bandwidth and QoS availability of a destination nodeWe 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).


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

91

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 extensionsto the route messages (RREQ, RREP).A node that receives a RREQ + QoS Extension must be able tomeet the service requirement in order to rebroadcast the RREQ (ifnot in cache).In order to handle the QoS extensions some changes need to be on the routing tablesAODV current fields.o Destination Sequence Number, Interface, Hop Count, Next Hop, List of

Precursors

AODV new fields. (4 new fields)1. Maximum Delay, 2. Minimum Available Bandwidth, 3. List of Sources Requesting Delay Guarantees and4. List of Sources Requesting Bandwidth Guarantees


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

92

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 requirementResource information is updated in the RREQ by intermediate nodes

Destination sends resource information back to source in the RREP message

S D

RREQRREP

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

93

Other Challenges for QoS Routing and Admission Control

X

R S

P Q

Simultaneous Intersecting Requests

Simultaneous Parallel Requests

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

94

Problem and Motivation in Hybrid Networks

QoS models for different domains (fixed vs. ad hoc) will not converge in foreseeable future.

A model is needed to define interoperability between the two sides (ad hoc and fixed domains).

QoS requirements are likely to be more demanding for extranet traffic.

Wireless Ad hoc Wireless Ad hoc

Fixed access network

Intranet Traffic Extranet Traffic


Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

95










Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

96










Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

97

SWAN Model






Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

99

Modelo de consumo de energía

Energía consumida por una estación depende de:o Consumo del interfaz

Características del interfaz de redOperación

o Suministro de energíao Tiempo de transmisión del paquete

Tamaño del paqueteAncho de banda

Lucent WaveLAN 2.4 GHz, 11Mbpso Recepción 240mAo Transmisión 280mAo V = 5 voltioso tp = (ph/2*106 + pd/11*106)

Ph = tamaño cabeceraPd = tamaño datos

Etx(p) = 280mA * v * tpErx(p) = 240mA * v * tp

E(p) = i * v * tp

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

100

Metodología de evaluación

Escenario básicoPatrón de escenario

25 estaciones inalámbricas500m x 500m15m/s de velocidad máximaModelo random waypoint

Patrón de tráfico20 fuentes CBR 4 paquetes/seg de 512 bytes

Estudio de sensibilidadParámetros evaluados

Patrón de movimientoPatrón de tráficoNúmero de estacionesÁrea de la red

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

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

101

Escenario básico

El consumo total depende del proceso de recepcióno Proceso de recepción=Recibir + Sobre-escucha (overhearing)

DSR reduce el consumo con respecto a DSDV y AODVMecanismos de tablas cache

El consumo elevado de TORA Dependencia con el protocolo IMEP [Corson98]

0%

25%

50%

75%

100%

DSR AODV DSDV TORA

Con

sum

o de

Ene

rgía

(%)

Energía Tx Energía Rx

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

102

Impacto del patrón de movimiento

Se varia la velocidad de las estaciones desde 0, 1, 5, 15 hasta 25 metros/segResultados:

o El consumo de energía 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

0

100

200

300

400

500

600

700

0 5 10 15 20 25

Velocidad (m/s)

Con

sum

o de

ene

rgía

(Jul

ios)

DSR AODV DSDV TORA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

103

Impacto del número de estaciones

Se varia el número de estaciones desde 10, 25 hasta 50 estacionesEl consumo aumenta con el número de estaciones

o Protocolos proactivos intercambio periódico de rutaso Protocolos reactivos procesos de mantenimiento de rutas

0

500

1000

1500

2000

2500

3000

3500

10 20 30 40 50

Número de estaciones

Con

sum

o de

ene

rgía

(Jul

ios)

DSR AODV DSDV TORA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

104

Impacto del área de la red

Se varia el área de la red desde 250mx250m, 250mx500m, 500mx500m y 1000mx500mLos protocolos reactivos incrementan el consumo de energía más rápido que los protocolos proactivos

0

200

400

600

800

1000

250mx250m 500mx250m 500mx500m 1000mx500m

MANET Área

Con

sum

o de

ene

rgía

(Jul

ios)

DSR AODV DSDV TORA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

105

Impacto del tráfico de red

Se ha modificado el número de fuentes de tráfico CBR desde 10, 20 y 30 fuentesTodos los protocolos presentan un comportamiento estable

o Proactivos Rutas actualizadaso Reactivos aprendizaje de rutas

Incrementar el número de fuentes CBR es EQUIVALENTE a incrementar la tasa de envío

0

100

200

300

400

500

600

700

10 20 30

Número de fuentes CBR

Con

sum

o de

ene

rgía

(Jul

ios)

DSR AODV DSDV TORA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

106

Conclusiones

El consumo de energía depende de las operaciones de recepción de datos Protocolos de encaminamiento:

o Los protocolos reactivos (DSR y AODV) obtienen mejores prestaciones en la mayoría de los escenarios considerados

o DSR obtiene mejores prestaciones que AODVo En escenarios extremos (velocidad, tamaño) se deben considerar

aproximaciones proactivas



Aspectos relacionados:o Configuración cero

zeroconf: Zero Configuration Networkingo movilidad a nivel de red: mobileIPo What’s new?

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

108

zeroconf: Zero Configuration Networking

ZEROCONF: Grupo de trabajo del IETF o Establecido en septiembre de 1999o http://www.ietf.org/html.charters/zeroconf-charter.html

Objetivo mínimo: dos ordenadores conectados entre sí mediante uncable cruzado por Ethernet, han de comunicarse entre sí bajo IP, sin necesidad de intervención humana, ni servidores DHCP o DNSo AppleTalk actualmente ya hace esto muy bien, conectando

simplemente a un hubApple con Macs dotados de IEEE 802.11 Airport lo hace de modo inalámbrico

o Microsoft NETBIOS provee para redes pequeñas un sistema alternativo

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

109

zeroconf: áreas de trabajo

Para lograr esta funcionalidad con IP en pequeñas redes se crean cuatro áreas de trabajo principales:1. Asignar direcciones IP sin un servidor DHCP (con dirección de red,

router...)2. Traducir entre nombres y direcciones IP sin un servidor DNS3. Descubrir servicios, como por ejemplo impresoras, sin un Servicio de

Directorio4. Asignar direcciones IP multicast sin un servidor MADCAPLas soluciones en cualquiera de las cuatro áreas han de coexistir amigablemente con las redes actualmente configuradaso Direccionamiento IP tanto de IPv4 como de IPv6Los protocolos de Zeroconf no tienen que causar perjuicio alguno a la red, cuando una máquina configurada con Zeroconf sea conectada a la red actual o Características de seguridad suficientes para prevenir que no sean menos

seguros

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

110

zeroconf: objetivos

Las funciones habrán de ser definidas para dos topologías de reddistintaso Un segmento de red simple, donde los hosts son accesibles a través

de la capa de enlace mediante broadcasting o mensajes multicasto Un conjunto de segmentos de redes (en distintas subredes IP)

interconectadas mediante un simple routerLa configuración automática de una topología arbitraria de routers y subredes queda fuera del ámbito del grupo de trabajo

Definirá cómo una red puede automáticamente realizar una transición desde el comportamiento de configurada a desconfigurada y viceversao Los mismos hosts han de ser capaces de funcionar en redes sin

configuración, así como con conectividad directa IP hacia Internet, incluyendo servicios DNS, etc.

o También será posible que ambos modos (Zeroconf y administrado) puedan coexistir en la misma red, sin ser dichos modos mutuamente excluyentes

Simplicidad y facilidad de uso (la escalabilidad no debería ser un objetivo primordial del grupo de trabajo)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

111

zeroconf: requerimientos

Protocolos TCP/IP inaceptables en redes emergenteso DNS RFC 1034 y 1035 Domain Name Serviceo DHCP RFC 2131 Dynamic Host Configuration Protocolo LDAP RFC 2251 Lightweight Directory Access Protocolo MADCAP RFC 2730 Multicast Address Dynamic Client Allocation

ProtocolCoexistencia y escalabilidado No es necesario usar Zeroconf simultáneamente en las cuatro áreaso La escalabilidad es importante pero no es un objetivo primordial

Requerimiento del protocolo de encaminamientoo Protocolos que pretendan alcanzar un intervalo de subredes IP no

deberían usar difusión o direccionamiento de enlace localRequerimiento de conflictos y cambios de estadoo Tiene que responder a los cambios de estado y resolver conflictos de

una manera puntual, ante los cambios de topología u otros eventos como la aparición o desaparición de hosts (aplicable a todas las áreas de protocolo)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

112

zeroconf: consideraciones de seguridad

El principal avance de los protocolos Zeroconf es proveer configuración de la red, allá donde los servicios de configuración no están disponibles. Esto es ventajoso con operaciones seguras, pues los mecanismos de seguridad requieren generalmente alguna preconfiguración (claves, certificados, etc.)Normalmente, los mecanismos de seguridad en protocolos IETF son de implementación obligatoria, aunque una implementación particular quizá puede permitir a un administrador desactivar operacionalmente un mecanismo de seguridad. En cualquier caso, las implementaciones han de ser “seguras fuera de la caja” y han de configurarse seguras por defectoLos protocolos Zeroconf no pueden ser menos seguros que los protocolos actualmente relacionados del IETF estándarLas amenazas a considerar incluyen ataques activos (v.g. denegación de servicio) como ataques pasivos (escuchas a través de la red), y los protocolos que requieren confidencialidad y/o integridad deben resolverse mediante integración o usando los mecanismos estándar de seguridad



zeroconf: Zero Configuration Networkingo Asignar direcciones IPo Asignar direcciones IP multicasto Descubrir servicios

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

114

zeroconf/asignación de direcciones IP:escenarios y requerimientos

Configuración de la interfaz IP: o Siempre incluye la configuración de una dirección IP y de la máscara de

redo Puede incluir alguna información de encaminamiento (p.ej., router por

defecto)o Es necesario disponer de ella antes que ninguna comunicación se lleve

a caboRequerimientos:

o Ha de configurar una máscara de red apropiadao Ha de tener una dirección IP única dentro de una subredo Ha de tener alguna información relativa al encaminamiento para la

interredo Ha de tener una subred IP única dentro de la interred, si ésta existeo Tiene que resolver conflictos puntualmente ante los cambios de

topologíaConsideraciones en IPv6

o IPv6 permite a un host seleccionar apropiadamente una dirección, una máscara de red e información de encaminamiento. Así, ya existe una configuración Zeroconf

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

115

zeroconf/asignación de direcciones IP:estrategias

Existen tres estrategias principales:Conflict-detection allocation

o En este esquema los nodos conjeturan una IP (aleatoriamente o utilizando alguna información de la red) y luego deben utilizar algún método para detectar direcciones duplicadas.

Conflict-free allocationo En este esquema no hay conflicto de direcciones, ya que se

implementan mecanismos que controlan a priori que no pueda existir un solapamiento de las direcciones. Se basan en algoritmos de asignamiento de enteros para que los conjuntos sean disjuntos.

Best-effort allocationo Los nodos responsables de la asignación de direcciones intentan

asignar direcciones IP no utilizadas en la medida de la información de que disponen y luego utilizan técnicas de detección de conflictos para los casos en los que haya conflicto.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

116

zeroconf/asignación de direcciones IP:conflict-detection allocation - PWMRS

PWMRSo 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 routingtiene altas latenciasno soluciona la configuración concurrente de varios nodosno contempla fusiones/particiones

Se utilizan direcciones de clase B con prefijo 169.254 / 16(IPv4) tiene extensiones para soportar IPv6.El nodo que intenta obtener una dirección IP utiliza inicialmente una temporal(para comunicarse con el resto) dentro del rango 0-2047, seleccionándola aleatoriamente.Elige otra, dentro del rango 2048-65534, como dirección tentativa.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

117

zeroconf/asignación de direcciones IP:conflict-detection allocation - PWMRS

El nodo envía un Address Request (AREQ) por broadcast a sus vecinos y arranca un temporizador.

o El AREQ contiene la dirección temporal y la tentativa.Cuando un nodo recibe un AREQ comprueba que no coincida con su IP la dirección tentativa.

o Si no coincide reenvía el mensaje a sus vecinos (broadcast) lo mismo hace con los AREP que no son para él.

o Si coincide envía (por broadcast) un Address Reply (AREP).Cuando un nodo envía AREQ espera AREP hasta que venza el time-out. Si es así repite el proceso AREQ_TIMES

o si no hay contestación se queda la IP, considerándose configurado.o si el nodo recibe AREP, vuelve a iniciar el proceso con otra dirección.

La técnica también puede utilizarse con Ipv6, con pequeñas modificaciones. S.Cheshire “IPv4 Address Conflict Detection” draft-cheshire-ipv4-acd-03.txt propone un mecanismo similar y para la resolución de conflictos usa ARP.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

118

zeroconf/asignación de direcciones IP:conflict-detection allocation - Mejoras para el DADDAD fuerte:

o se refiere a cuando un algoritmo puede garantizar que detectará duplicados siempre que se produzcan.

o La mayoría de los métodos conflict-detection utilizan time-outs en la comunicación entre nodos a la hora de gestionar el DAD, con lo que su funcionalidad se fundamenta en que en la red las latencias esténacotadas: no se puede garantizar en una MANET

DAD débil:o será cuando no se puede garantizar el DAD en determinadas

circunstancias, pero esto es tolerable para el funcionamiento normal de la red. se permite que haya DA pero se debe garantizar que dados dos nodos (A y B) con la misma dirección IP, los paquetes dirigidos al nodo A le acaben llegando sólo a él y lo mismo con el nodo B.

o “Weak Duplicate Address Detection in Mobile Ad Hoc Networks”, Nitin Vaidya, ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), June 2002

K. Weniger: Passive Duplicate Address Detection in Mobile Ad hoc Networks, In Proceedings of IEEE WCNC 2003, New Orleans, USA, Mar. 2003 Jeong et al. “Ad Hoc IP Address Autoconfiguration” draft-jeong-adhoc-ip-addr-autoconf-00.txt

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

119

zeroconf/asignación de direcciones IP:conflict-detection allocation – DAD débil

La idea del método 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 quién son los paquetes,consiguiéndose el objetivo de DAD débil.

o Para cada mensaje route_request, los nodos implicados deberán añadir su par (IP,key). Lo mismo deberá ocurrir en otros mensajes de descubrimiento de red como route_reply o route_error.

o Se deberán añadir números de secuencia a los pares (IP,key).

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

120

zeroconf/asignación de direcciones IP:conflict-free allocation

“Prophet address allocation for large scale manet” , Zhou, Ni, Mutka, SIGCOMM 2003

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

121

zeroconf/asignación de direcciones IP:conflict-free allocation

Los autores enfocan el problema de la autoconfiguración de direcciones IP como el de la asignación de un conjunto de enteros dentro de un rango dado a los distintos nodos de la MANET

o Convenientemente realizada la asignación, no tiene porqué haber conflictos.

o El nodo inicial sabe a priori que conflictos se pueden producir, pudiendo evitarlos realizando la detección antes de la asignación de direcciones

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

122

zeroconf/asignación de direcciones IP:conflict-free allocation - Prophet

Ejemplo de funcionamiento: o R∈[1,8]o f(n)=(address x state x11) mod 7 o cada nodo tiene asociado:

(address, state of f(n)).

Cuando la red se inicia sólo está A. Elige aleatoriamente el número 3 como dirección IP y como semilla para f(n). Cuando B intenta unirse, A calcula f(3)=(3 x 3 x11) mod 7=1 y se lo pasa a B como dirección IP y semilla. Además actualiza su semilla con ese valor. Posteriormente C se aproxima a A y D a B. Cada uno calcula los valores independientemente (pero compartiendo semilla) de forma que

o para C: f(n)=f(1)=(3 x 1 x 11) mod 7=5 IP C=5 y el estado de A y C=5.

o para B: f(n)=f(1)=( 1 x 1 x 11) mod 7=4

IP D=4 y el estado de B y D=4.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

123

zeroconf/asignación de direcciones IP:conflict-free allocation - Prophet elección de f(n)

Si R es suficientemente grande y f(n) está convenientemente diseñada, se puede garantizar que las secuencias obtenidas satisfacen:

1. El intervalo entre la repetición de dos números en la secuencia es extremadamente largo.

2. La probabilidad de la ocurrencia de un mismo número en diferentes secuencias iniciadas con diferentes semillas es extremadamente baja(necesario para redes que se configuren independientemente yluego se fusionen).

Los autores proponen una solución aproximada basada en la descomposición en factores primos. Cualquier número puede representarse únicamente por:

De forma que si las tuplas (e1,e2,...,ek) tiene diferentes ei(i=1,...,k) habrá diferentes n( y por lo tanto no conflicto en direcciones).

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

124

zeroconf/asignación de direcciones IP:best effort allocation

S.Nesargi, R.Prakesh “MANETconf:Configuration of hosts in mobile ad hoc networks”, Proceedings of IEEE INFOCOM 2002Protocolo distribuido, no impide el conflicto de direcciones pero garantiza la no duplicación a costa de:

o mantener mucha información de estado por nodo o contemplar muchas más posibilidades que el resto de métodos (los

otros lo dejan en manos del DAD y de la asignación disjunta).Independiente del protocolo de routing, del protocolo de acceso al medio y del HW.Todo el mecanismo está dirigido por el proceso de asignación de direcciones, que es utilizado por los nodos para actualizar su información de estado de la red, detectar particiones/fusiones, caídas de nodos,....

Proceso de asignación: interacción entre el nodo que quiere acceder (requester) y otro nodo (alcanzable sin dirección IP) ya configurado (initiator) que le configurará.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

125

zeroconf/asignación de direcciones IP:Métricas para la evaluación

Grado de distribución: los algoritmos tienen que ser lo más 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 solución requiere mucha comunicación entre nodos (p.e., mantenimiento de información de estado),

o broadcast, etc. y como influirán eventos impredecibles como particiones/fusiones. Distribución de direcciones equilibrada: interesará que la distribución sea lo más aquíprobable posible (respecto al conjunto de direcciones), pues entonces la probabilidad de conflicto será baja, disminuyendo la sobrecarga de tráfico.Latencia: Entendida como el tiempo que tarda en asignarse una dirección aun nodo. Escalabilidad: en MANETs, el tamaño puede ser variable e impredecible con un rango dinámico potencialmente

o Además interesarán soluciones donde la mayor parte de la comunicación ocurra localmente pues si se usan broadcast y la red crece mucho la latencia puede disparase

Corrección: Entendida como la minimización del tiempo de vulnerabilidad (DAD) esto es los períodos de sombra en los que no se puede garantizar que haya duplicados.




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

127

zeroconf/asignación de direcciones IP multicastescenarios y requerimientos

Rango en IPv4 de 224.0.0.0 a 239.255.255.255. Ámbitos según RFC 2365

o Nodo local y punto local No especificados para IPv4o Enlace local 224.0.0.0/24o Local 239.255.0.0/16o Organización local 239.192.0.0/14o Global 224.0.1.0 a 238.255.255.255o Una asignación relativa equivale a un desplazamiento entero desde la

dirección más alta representada en 32 bits. Así, 239.255.255.0/24 se reserva en el ámbito local

o Las direcciones Source-Specific Multicast (SSM) son: 232.0.0.0 a 232.255.255.255

El nodo local y las direcciones SSM no requieren protocolo o interacción entre múltiples hostsLos ámbitos global y de organización local se entienden para redes de mayor escala que los protocolos ZeroconfLos paquetes multicast deben restringir su alcance límite, y suponemos que un router en la frontera es un boundary router como se describe en RFC 2365

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

128

zeroconf/asignación de direcciones IP multicastescenarios y requerimientos

Asignación de direccioneso Hay que ser coherente desde la elección y la coordinación hasta la reutilizacióno Requerimientos

Tiene que seleccionar una dirección multicastHa de prevenir conflictos de asignación de la misma direcciónTiene que permitir la liberación de una dirección cuando no esté más en uso

Fuente múltipleo Un sistema de intercomunicación en el hogar es un ejemplo de aplicación con

múltiples fuentes de IP multicast, pues diversos orígenes pueden estar enviando paquetes destinados a la misma dirección IP multicast

o El problema se presenta cuando una dirección puede continuar siendo válida aún después de que el host que inició la asignación haya desaparecido del grupo, es decir haya caído o simplemente abandonado el grupo multicast

o Requerimiento: Un host distinto del que asigna las direcciones tiene que “defender” el mantenimiento de la asignación de una dirección multicast

O. Catrina et al., “Zeroconf Multicast Address Configuration Protocol (ZMAAP),” Internet draft, October 2002

o Asigna direcciones únicas y se encarga de su gestióno Previene la reasignación de direcciones asignadas




Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

130

Escenarios y requerimientos

Servicio de descubrimientoo Los protocolos de este servicio permiten a los usuarios seleccionar servicios y/o

hosts por un nombre que es descubierto dinámicamente, mucho mejor que por un nombre y tipo que el usuario debiera conocer anticipadamente

o Servicio de impresoraLas impresoras de red permiten enviar a diferentes clientes trabajos de impresión. Hay que averiguar sus características (localización, resolución, estado, color, etc.) sin protocolos particulares de impresiónRequerimientos

– Tiene que permitir que un servicio sea descubierto– Tiene que descubrir a través de un identificador y/o tipo de servicio– Ha de descubrir servicios sin usar ningún protocolo específico de servicios– Deberá descubrir características del propio servicio– Tiene que completar el servicio puntualmente (décimas de segundo)

o Consideraciones en IPv6Los protocolos de este servicio no tienen diferencias relacionadas con ZeroConf

Service Discovery Protocols (SDPs)o SLP (Service Location Protocol)

by IETF srvloc Working Groupo UPnP (Universal Plug and Play)

by Microsofto Jini

by Sun Microsystems

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

131

Service Location Protocol

Main componentso User Agent (UA)

discovers services that the devices they represent are requestingo Service Agent (SA)

advertises the services they represento Directory Agent (DA)

accumulates service information from SAresponds to service requests from UA

Implementationo with a DAo without a DA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

132

Service Location Protocol (cont.)With a DA

UA DA SA

SrvAck

AttrRqst

SrvRqstservice:da

DAAdvertservice:da://129.187.222.102

SrvRegservice:printer://129.187.222.134color=true, postscript=true,…

DAAdvertservice:da:

//129.187.222.102

SrvRqstservice:printercolor=true

SrvRplyservice:printer://129.187.222.134

AttrRplycolor=true,

postscript=true,…

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

133

Service Location Protocol (cont.)Without a DA

UA SA

AttrRqst

SAAdvertservice:da:

//129.187.222.102

SrvRqstservice:printercolor=true

SrvRplyservice:printer://129.187.222.134

AttrRplycolor=true,

postscript=true,…

SrvRqstservice:da

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

134

Universal Plug and Play

What is „universal“ about UPnP?There are no device driversUPnP networking is media independentUPnP devices can be implemented using any programming language, and on any operational system (SOAP)Major components

o device (logical device)contains one or more services and/or devices

o service (logical functional unit)exposes actions and models the state of a physical device with state variables

o control point searches for devices (services)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

135

Universal Plug and PlayNetworking

Step 1. DiscoveryStep 2. DescriptionStep 3. ControlStep 4. EventingStep 5. Presentation

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

136

Universal Plug and PlayStep 1. Discovery

controlpoint 2

service 1

device 2

service 2

controlpoint 1

advertise

advertise

mul

ticas

t

service 1

device 1

service 2

controlpoint 3

search mul

ticas

t

response (unicast)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

137

Universal Plug and PlayStep 2. Description

service 1

device

service 2

controlpoint

UPnP description for device

UPnP description for service

UPnP description request

UPnP description request

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

138

Universal Plug and PlayStep 3. Control

service

device controlpoint

action request

query variable

result

variable value

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

139

Universal Plug and PlayStep 4. Eventing

service 1publisher

device 1controlpoint subscriberSID=uuid:1…

controlpoint SubscriberSID=uuid:2…

subscription request

subscription (uuid:1…)

subscription (uuid:1…)

renewal request

cancellation (uuid:1…)

event message

event message

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

140

Universal Plug and PlayStep 5. Presentation

service

device browser presentation request

presentation page

control and/or status

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

141

JiniMain Aspects

service o devices (printers, displays, disks)o software (applications, utilities)o information (databases, files)o users of the system

lookup serviceo maps interfaces indicating service functionality to sets of objects

implementing the serviceRMI (Java Remote Invocation Method)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

142

JiniMain Aspects (cont.)

service proxy objecto can be a complete implementation of a serviceo once a service is located, its proxy object will be uploaded by lookup

serviceo client object contacts lookup service to download the proxy object

eventso objects register with other objects to get notificationso when services join or leave, events are signaled

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

143

JiniDiscovery

A service provider seeks a lookup service.

serviceprovider

client

lookup service

service object

service attributes

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

144

JiniJoin

A service provider registers a service object (proxy) and its service attributes with the lookup service.

serviceprovider

client

lookup service

service object

service attributes

service object

service attributes

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

145

JiniLookup

A client requests a service. A service object copy is moved to the client and used by the client to talk to the service.

serviceprovider

client

lookup service

service object

service attributes

service attributes

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

146

JiniClient Uses Service

The client interacts directly with the service provider via the service proxy object.

serviceprovider

client

lookup service

service object

service attributes

service attributes





Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

148

mobileIP

IETF mobileip (IP Routing for Wireless/Mobile Hosts) working groupo http://www.ietf.org/html.charters/mobileip-charter.html

Referencias:o C. Perkins, “IP Mobility Support”, RFC2002o J. Solomon et al., “Mobile-IPv4 Configuration Option for PPP IPCP”,

RFC2290o Charles E. Perkins, “Mobile IP: design principles and practices”,

Addison-Wesley Wireless Communications Series, October 1997

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

149

El problema

Esquema de direccionamiento de IPIdentificadores de conexiones TCP/UDP

<129.34.16.43, sh port #,128.8.128.45, mh_port #> Internetsubnet A

subnet B

subnet C

Clase A

Clase B

Clase C

red

red

Host

Host

Red0

Red

Red

dirección multicastClase D

1.0.0.0 ….. 126.0.0.0

128.0.0.0 ….. 191.255.0.0

192.0.0.0 ….. 223.255.255.0

224.0.0.0 …… 239.255.255.255

Host01

011

111 0

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

150

La solución

Internet

Un agente enla red origen

nodo IP

1

2 3

4 Un agente enla red actual

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

151

Mobile node (MN)o nodo que cambia su punto de

conexión de una subred a otraHome agent (HA)

o router en la subred “home” del MN que se encarga del tunneling de los datos hacia el MN

Foreign agent (FA)o router en la subred actual

(visitada) del MN que se encarga del reenvío de los paquetes hacia el MN

Mobile node (MN)o nodo que cambia su punto de

conexión de una subred a otraHome agent (HA)

o router en la subred “home” del MN que se encarga del tunneling de los datos hacia el MN

Foreign agent (FA)o router en la subred actual

(visitada) del MN que se encarga del reenvío de los paquetes hacia el MN

Arquitectura

Internetsubnet A

subnet B

subnet C

HA

HA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

152

Agent discoveryo los HA y los FA hacen publica su

presencia en cada subred (o segmento de subred) en el que quieran proveer el servicio

Registrationo establecimiento de una

“conexión” entre un FA o el HA y un MN

Tunnelingo reenvío de los datagramas al MN

por parte del HA

Agent discoveryo los HA y los FA hacen publica su

presencia en cada subred (o segmento de subred) en el que quieran proveer el servicio

Registrationo establecimiento de una

“conexión” entre un FA o el HA y un MN

Tunnelingo reenvío de los datagramas al MN

por parte del HA

Servicios de MobileIP

Internet

subnet B

subnet C

subnet A

HA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

153

Esquema de funcionamiento de mobileIP

agent adv msg

reg. request

agent disc msgagentdiscovery

tunnelling

reg. request

reg. accept/deny

reg. accept/deny

registration

HA

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

154

Direccionamiento en dos niveles

Internetsubnet A:132.4.16.

subnet B

subnet C128.8.128.

128.8.128.Y

132.4.16.Z

dirección de localización

dirección estática

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

155

Triangle routing

Internet

Homeagent Foreign

agent

nodo IP

1

2 3

4

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

156

Detección de movimiento

Problema: ¿como establezco que un nodo ha cambiado de subred?

Lazy Cell Switching (LCS) (conmuta con línea AZUL)Eager Cell Switching (ECS) (conmuta con línea ROJA)Prefix comparison (conmuta con línea ROJA) (requiere mas subredes)Notificación por el nivel de enlace (incluyendo parámetros como la potencia de la señal, etc.)Las prestaciones de estas técnicas dependes del patrón de movilidad, de la frecuencia de los advertisementLCS con potencia de las señal pude ser mejor que ECS

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

157

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 advertisementA mobile node should, effectively, expire each advertisement at the end of its lifetimeIf the mobile node fails to receive another advertisement from the same agent within the specified lifetime, it should assume that it has lost contact with that agent.If the mobile node has previously received an agent advertisement from another agent for which the lifetime has not yet expired, the mobile node may immediately attempt registration with that otheragent.

o Otherwise, the mobile node should attempt to discover a new agent with which to register, perhaps by broadcasting an agent solicitation

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

158

Eager Cell Switching (ECS)

A basic assumption about the mobility patterns of nomadic userso movement is considered most likely to proceed along fairly straight lineso a mobile computer, once it first enters a new wireless cell, will usually

continue to proceed further into that new cell and, by implication, further along the way out of its previous cell

Mobile computer switches right away to any new care-of address that might be available within the new cell Mobile nodes can switch to new care-of addresses without any interruption in connectivity to the InternetA list of current foreign agents must be maintained

o if a mobile node actually resides within range of two different foreign agents and is receiving beacons from both of them, the mobile node has to remember which was the most recently detected foreign agent and remain attached to that most recent one

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

159

Prefix Matching

Movement detection with prefix matching uses network prefixesIf the prefixes differ, the mobile node may assume that it has movedIf 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 addressThe 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





Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

161

IETF 65 MANET WG Minutes

Proceedings of the Sixty-Fifth Internet Engineering Task Forceo 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 packetbbformat. We have also agreed to carve out (from OLSRv2) a common MANET neighborhood discovery protocol (still unnamed).

Generalized Packet and Message Formato draft-ietf-manet-packetbb-00.txt

DYMOo draft-ietf-manet-dymo-04.txt

OLSR v2 o draft-ietf-manet-olsrv2-01.txt

SMFo draft-ietf-manet-smf-02.txt

OSPF-MANET

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

162

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 correctlyparsed and forwarded;

o a generalized multi-message packet format, in which the headerinformation contains the necessary information to allow single and multi-hop diffusion in MANETs, whilst also permitting unicast and multicastuse of the format;

o a mechanism whereby addresses can be represented in a compact way(address compression);

o an extensibility mechanism whereby arbitrary attributes, through TLVs(type-length-value triplets), can be included and associated with a message, an address or a set of addresses, while being correctlyparseable by a generic message parser.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

163

DYMO

DYMO – Reactive Protocol like AODV, but with path accumulation feature

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TargetAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | THopCnt |Res|

SS I1I1 I2I2 I3I3 DD

RREQRREQ

RREPRREP

RREQRE-S

RREQRE-SRE-I1

RREQRE-SRE-I1

RREQRE-SRE-I1

RE-I2 RE-I2RE-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| RBPrefix |Res| RBHopCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . RBNodeAddress . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBNodeSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RERE--S Route Element with NL of SS Route Element with NL of S

RERE--I1 Route Element with NL of I1I1 Route Element with NL of I1

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

164

DYMO Route Maintenance

Avoid expiring good routeso Update reverse route lifetime on data receptiono Update forward route lifetime on data transmission

Inform sources of broken routes quicklyo Active links must be monitored

Several mechanisms available

Route Error (RERR)Optional additional invalid routes

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

165

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 2005There are several differences between AODV, AODV-bis, DSR and DYMO. To list just a few.

– New packet format. – Generic packet handling. – Unsupported element handling. – Optional path accumulation. – Much more.

o 23 Mar 2006DYMO is a simpler version of AODV. DYMO is easier to implement and has lower requirements (in terms of memory, code, etc.) than AODV. DYMO isclose to what has been implemented for sensor networks, such as tinyAODV. AODV is no longer being explored in the MANET WG.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

166

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-stateinformation: each node maintains information of all destinations, butonly a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-widebroadcasts) and that these advertisements contain only a subset oflinks (i.e. reduces the size of each network-wide broadcast). Thepartial link-state information thus obtained allows each OLSRv2node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by notrequiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stackis routing table management. OLSRv2 is particularly suitable for large and dense networks as thetechnique of MPRs works well in this context.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

167

Proactive QoS Routing: QOLSR

Optimized Link State Routing[RFC3626]

Aiming at large and dense MANETs with lower mobilityOnly selected nodes as multi-point relays (MPRs) forwards broadcasting messages to reduce overhead of flooding MPR nodes periodically broadcast its selector listQoS extensions

o QOLSR[IETF Draft]: Hello messages and routing tables are extended with parameters of maximum delay and minimum bandwidth, and maybe more QoSparameters

Advantage: ease of integration in Internet infrastructureDisadvantages: Overhead to keep tables up to date

Black nodes: MPRs

http://www.ietf.org/internet-drafts/draft-badis-manet-qolsr-03.txt

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

168

SMF for MANET

Progress has been made in developing and implementing more efficient ways to flood control packets within MANET routingprotocol. 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 packetforwarding. When efficient flooding is a sufficient technique, SMF can makemulticast forwarding available to data flows within a MANET area. The SMF baseline design limits the scope to basic, best effortmulticast forwarding and its applicability is intended to be constrained within a MANET area.

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

169

Hot Topics

Áreas de interés del MobiHoc 2006o Applications, operating system, and

middleware supporto Transport, network, and MAC protocolso Energy-efficient algorithmso Quality of Service issueso Location discovery techniqueso Network scaling and limitso Cross layer designo Network resilience, fault-tolerance, and

reliabilityo Trust, security and privacyo Distributed sensing, actuation, control, and

coordinationo Measurements and practical experience

from experimental systems and testbedso Modeling and performance evaluation

… y el programa final:o Tutorial 1: Wireless Mesh Networks:

Fundamentals, Basic Protocols and Research Issues

o Tutorial 3: Pervasive Environments: Challenges and Solutions

o Tutorial 5: Design Guidelines for Network Layer Protocols in Ad Hoc and Sensor Networks

o Tutorial 2: Wireless Mesh Networks: Applications, Testbeds, Products and Standards

o Tutorial 4: Delay/Disruption Tolerant Networking

o Tutorial 6: Multimedia Conferencing in Mobile Ad Hoc Networks: Challenges and Early Approaches

o Technical Session 1: Routing and Forwarding

o Technical Session 2: Mobility Modelso Technical Session 3: Analysis, Simulation

and Experimentationo Technical Session 4: Connectivity and

Coverageo Technical Session 5: Medium Access

Controlo Technical Session 6 : Location and

Membership Serviceso Technical Session 7: Theoryo Technical Session 8: Sensor Networks



Introducción al simulador NS-2

Jae Chung, Mark Claypoolo Worcester Polytechnic Institute

Ya Xu y Haobo Yu o USC/ISI

Polly Huango AT&T Labs Research

Hao-Li Wango Department of Electrical and Computer Engineering, Iowa State University

Sung Parko Network and Embedded Systems Lab (NESL) - Electrical Engineering, UCLA

K. Sridharan Iyer, o Texas A&M University

agradecimientos/acknowledgments

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

171

What is NS

Discrete event simulatoro The VINT project : Virtual InterNet Testbedo UC Berkeley, Lawrence Berkeley National Lab, USC/ISI, Xerox PARC,

AT&T Research o Packet-levelo Link layer and upo Wired and wireless

Object-oriented o Mixed C++ and Otcl

Most UNIX and UNIX-like systemso FreeBSDo Solariso Linux

Window 95/98/NT/2Ko Works, but with an effort

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

172

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, TORAMAC protocols - 802.3, 802.11 (Wireless MAC)Scheduling disciplines - DropTail, RED, WFQ, DRR, LQD etc.Different traffic characterizations - Poisson, Exponential, Pareto etc.Modify NS-2 to implement your own versions of the above protocols or even code totally new protocolsMeasurement of Statistics:

o Throughput, Delay, Jitter etc.o Queue Monitoring, Drops at Queues.o Literally all that you will need to know with your simulations.

Graphic visualization - using “nam” (Network Animator)Emulation - A less known fact about ns-2

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

173

NS input & output

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

174

Basic tcl

proc test {} {set a 43set b 27set c [expr $a + $b]set d [expr [expr $a - $b] * $c]for {set k 0} {$k < 10} {incr k} {

if {$k < 5} {puts "k < 5, pow = [expr pow($d, $k)]"

} else {puts "k >= 5, mod = [expr $d % $k]"

}}

}

test

proc test {} {set a 43set b 27set c [expr $a + $b]set d [expr [expr $a - $b] * $c]for {set k 0} {$k < 10} {incr k} {

if {$k < 5} {puts "k < 5, pow = [expr pow($d, $k)]"

} else {puts "k >= 5, mod = [expr $d % $k]"

}}

}

test

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

175

Basic OTcl

Class mommom instproc greet {} {

$self instvar age_puts "$age_ years old mom: How are you doing?"

}

Class kid -superclass momkid instproc greet {} {

$self instvar age_puts "$age_ years old kid: What's up, dude?"

}

set a [new mom]$a set age_ 45set b [new kid]$b set age_ 15

$a greet$b greet

Class mommom instproc greet {} {

$self instvar age_puts "$age_ years old mom: How are you doing?"

}

Class kid -superclass momkid instproc greet {} {

$self instvar age_puts "$age_ years old kid: What's up, dude?"

}

set a [new mom]$a set age_ 45set b [new kid]$b set age_ 15

$a greet$b greet

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

176

Hello World - Interactive Mode

swallow 71% ns% set ns [new Simulator]_o3% $ns at 1 “puts \“Hello World!\””1% $ns at 1.5 “exit”2% $ns runHello World!swallow 72%

swallow 71% ns% set ns [new Simulator]_o3% $ns at 1 “puts \“Hello World!\””1% $ns at 1.5 “exit”2% $ns runHello World!swallow 72%

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

177

simple.tcl

set ns [new Simulator]$ns at 1 “puts \“Hello World!\””$ns at 1.5 “exit”$ns run

swallow 74% ns simple.tclHello World!swallow 75%

simple.tcl

set ns [new Simulator]$ns at 1 “puts \“Hello World!\””$ns at 1.5 “exit”$ns run

swallow 74% ns simple.tclHello World!swallow 75%

Hello World - Batch Mode

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

178

Anatomy of NS Scripts

Create the event schedulerCreate networkCreate protocol agents (connections)Generate trafficTurn on tracingSetup routingInsert errorsStart event scheduler

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

179

Creating the Event Scheduler

Create event scheduleroset ns [new Simulator]

Schedule eventso$ns at <time> <event>

o <time>: any non-negative real numberso <event>: any legitimate ns/tcl commands

Start scheduler (the end of your script!)o$ns run

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

180

Creating the Network

Nodesoset n0 [$ns node]oset n1 [$ns node]

Links and queuingo$ns duplex-link $n0 $n1 <bandwidth> <delay> <queue_type>

o <queue_type>: DropTail, RED, CBQ, FQ …

Node

agent

Node

agent

Link

attach-agent attach-agent

application application

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

181

Creating Connections: TCP

TCPoset tcp [new Agent/TCP]oset tcpsink [new Agent/TCPSink]o$ns attach-agent $n0 $tcp

o$ns attach-agent $n1 $tcpsinko$ns connect $tcp $tcpsink

Node

agent

Node

agent

Link



Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

182

Creating Traffic: On Top of TCP

FTPoset ftp [new Application/FTP]o$ftp attach-agent $tcp

Node

agent

Node

agent

Link



Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

183

Inserting Errors

Creating Error Moduleoset loss_module [new ErrorModel]o$loss_module set rate_ 0.01o$loss_module unit pkt

o$loss_module ranvar [new RandomVariable/Uniform]o$loss_module drop-target [new Agent/Null]

Inserting Error Moduleo$ns lossmodel $loss_module $n0 $n1

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

184

Tracing

Trace packets on all linkso$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 0r 1.00234 0 2 cbr 210 ------- 0 0.0 3.1 0 0

Trace packets on all links in nam-1 formato$ns namtrace-all [open test.nam w]

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

185

Simple Simulation Example

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

186

TCL Script Step 1

#Create a simulator objectset ns [new Simulator]

#Open the NAM trace fileset nf [open out.nam w]$ns namtrace-all $nf

#Open the general trace fileSet f [open out.tr w]$ns trace-all $f

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

187

TCL Script Step 2

#Create four nodesset n0 [$ns node]set n1 [$ns node]set n2 [$ns node]set n3 [$ns node]

#Create links between the nodes$ns duplex-link $n0 $n2 2Mb 10ms DropTail$ns duplex-link $n1 $n2 2Mb 10ms DropTail$ns duplex-link $n2 $n3 1.7Mb 20ms DropTail

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

188

TCL Script Step 3

#Set Queue Size of link (n2-n3) to 10$ns queue-limit $n2 $n3 10

#Setup a TCP connectionset tcp [new Agent/TCP]$ns attach-agent $n0 $tcpset sink [new Agent/TCPSink]$ns attach-agent $n3 $sink$ns connect $tcp $sink

#Setup a FTP over TCP connectionset ftp [new Application/FTP]$ftp attach-agent $tcp

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

189

TCL Script Step 4

#Setup a UDP connectionset udp [new Agent/UDP]$ns attach-agent $n1 $udpset null [new Agent/Null]$ns attach-agent $n3 $null$ns connect $udp $null

#Setup a CBR over UDP connectionset cbr [new Application/Traffic/CBR]$cbr attach-agent $udp$cbr set packet_size_ 1000$cbr set rate_ 1mb

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

190

TCL Script Step 5

#Schedule events for the CBR and FTP agents$ns at 0.1 "$cbr start"$ns at 1.0 "$ftp start"$ns at 4.0 "$ftp stop"$ns at 4.5 "$cbr stop"

#Call the finish procedure after 5 seconds of simulation time$ns at 5.0 "finish"

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

191

TCL Script Step 6

#Define a 'finish' procedureproc finish {} {

global ns nf$ns flush-trace#Close the NAM trace fileclose $nf#Execute NAM on the trace fileexec nam out.nam &exit 0

}

#Run the simulation$ns run

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

192

Observing the behaviour using nam

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

193

Analyze trace file

Use some tools, like AWK or Perl, to analyze the trace fileUse 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 0r 0.0028 2 0 tcp 1000 ------- 0 2.0 1.0 0 0+ 0.0028 0 1 tcp 1000 ------- 0 2.0 1.0 0 0- 0.0028 0 1 tcp 1000 ------- 0 2.0 1.0 0 0r 0.009884 0 1 tcp 1000 ------- 0 2.0 1.0 0 0+ 0.009884 1 0 ack 40 ------- 0 1.0 2.0 0 1- 0.009884 1 2 ack 40 ------- 0 1.0 2.0 0 1r 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 1r 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



Introducción al simulador NS-2o NS to simulate wireless network

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

195

Wireless Simulation in ns-2

Contributed from CMU’s Monarch project (Wireless extension to ns-2)Various modules were added to ns-2 to simulate node mobility and wireless networking

o Mobile Nodeo Ad-hoc Routing(DSR, DSDV, TORA, AODV)o MAC802.11o Radio Propagation Modelo Channel

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

196

Mobile Node Modules

Agento Responsible for packet generations and receptionso Can think of it as an Application layero CBR(Constant Bit Rate), TCP, Sink, FTP, etc.

RTagent(DSDV, TORA, AODV) or DSRo Ad-hoc network routing protocolso Configure multi hop routes for packets

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

address conversions

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

197

Mobile Node Modules (Continued)

IFq (Interface Queue)o PriQueue is implemented to give priority to routing protocol packetso 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 pktsNetIF (Network Interfaces)

o Hardware interface used by mobilenode to access the channelo Simulates signal integrity, collision, tx erroro Mark each transmitted packet with transmission power, wavelength etc.

Radio Propagation Model o Uses Friss-space attenuation(1/r2) at near distance and Two ray ground

(1/r4) at far distanceo Decides whether the packet can be received by the mobile node with

given distance, transmit power and wavelengtho Implements Omni Directional Antenna module which has unity gain for

all direction

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

198

A first example

The file “simple-wireless.tcl” is under <NSRoot>/ns-allinone2.1b9/ns-tutorial/examples/simple-wireless.tclcd into the directory and type “ns simple-wireless.tcl” to run the simulationThe simulation will generate a trace file named “simple.tr”

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

199

Setting Up Variables

#============================================================ # Define options #============================================================ set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# Antenna type set val(ll) LL ;# Link layer type set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type set val(ifqlen) 50 ;# max packet in ifqset 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

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

200

Setting Up Variables

#Instantiate simulator objectset ns_ [new Simulator]

#Setup Trace Fileset tracefd [open simple.tr w] $ns_ trace-all $tracefd

#Create Topographyset topo [new Topography]$topo load_flatgrid 500 500

#Create Object Godcreate-god $val(nn)

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

201

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) \-agentTrace ON -routerTrace ON \-macTrace OFF -movementTrace OFF

for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node ] $node_($i) random-motion 0 ;# disable random motion

}

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

202

Configuring Movement

Configure Initial Position

# Node_(1) starts to move towards node_(0) $ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0" $ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0" # Node_(1) then starts to move away from node_(0) $ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0"

$node_(0) set X_ 5.0 $node_(0) set Y_ 2.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 390.0 $node_(1) set Y_ 385.0 $node_(1) set Z_ 0.0

Create Movement

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

203

Setup traffic flow

set tcp [new Agent/TCP] $tcp set class_ 2 set sink [new Agent/TCPSink] $ns_ attach-agent $node_(0) $tcp $ns_ attach-agent $node_(1) $sink $ns_ connect $tcp$sink set ftp [new Application/FTP] $ftp attach-agent $tcp $ns_ at 10.0 "$ftp start"

node_(0)

FTP

TCP

node_(1)

Sink

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

204

Set Stop Time and Start Simulation

Set Simulation Stop Time

puts "Starting Simulation..." $ns_ run

for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at 150.0 "$node_($i) reset";

} $ns_ at 150.0001 "stop" $ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt" proc stop {} { global ns_ tracefd close $tracefd }

Finally, Start The Simulation

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

205

Trace File

r 100.381997477 _1_ AGT --- 82 tcp 1060 [13a 1 0 800] ------- [0:0 1:0 32 1] [32 0] 1 0

r: receive event, 100.381997477:time stamps, _1_: node 1, AGT: trace generated by agent, 82: event(pkt) id, tcp: tcp packet, 1060: packet size, 13a(hex): expected duration of pkt transmission (not working), 1: sender mac id, 0: transmitter mac id, 800: pkt type IP (806 for ARP),0:0: sender address:port#1:0: receiver address:port#, 32: TTL1: next hop address,[32 0]: TCP sequence #, ack #

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

206

Another simple wireless simulation(1)

Scenarioo containing 3 mobile nodeso moving within 670mX670m flat topologyo using DSDV ad hoc routing protocolo Random Waypoint mobility modelo TCP and CBR traffico See:

ns-2/tcl/ex/wireless-demo-csci694.tcl

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

207

Another simple wireless simulation(2)

#Define Global Variablesset ns_ [new Simulator] ; create a ns simulator instanceset topo [new Topography] ; create a topology and$topo load_flatgrid 670 670 ; define it in 670x670 area

#Define standard ns/nam traceset tracefd [open 694demo.tr w] $ns_ trace-all $tracefdset namtrace [open 694demo.nam w] $ns_ namtrace-all-wireless $namtrace 670 670

#Create “God”set god_ [create-god 3]

God is used to store an array of the shortest number of hops required to reach from one node to an other. ¡¡CAN BE OMITTED!!

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

208

Another simple wireless simulation (3)

#Define how a mobile node should be created$ns_ node-config -adhocRouting DSDV\

-llType LL \-macType Mac/802_11\-ifqLen 50 \-ifqType Queue/DropTail/PriQueue \-antType Antenna/OmniAntenna \-propType Propagation/TwoRayGround \-phyType Phy/WirelessPhy \-channelType Channel/WirelessChannel \-topoInstance $topo-agentTrace ON \-routerTrace OFF \-macTrace OFF

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

209

Another simple wireless simulation (4)

#Create a mobile node and attach it to the channelset node [$ns_ node]$node random-motion 0 ;# disable random motion

Use “for loop” to create 3 nodes:

for {set i < 0} {$i<3} {incr i} {set node_($i) [$ns_ node]

}

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

210

Another simple wireless simulation: Movement file

$ns_ at 50.000000000000 "$node_(2) setdest 369.463244915743 170.519203111152 3.371785899154"$ns_ at 51.000000000000 "$node_(1) setdest 221.826585497093 80.855495003839 14.909259208114"$ns_ at 33.000000000000 "$node_(0) setdest 89.663708107313 283.494644426442 19.153832288917"$node_(2) set Z_ 0.000000000000$node_(2) set Y_ 199.373306816804$node_(2) set X_ 591.256560093833$node_(1) set Z_ 0.000000000000$node_(1) set Y_ 345.357731779204$node_(1) set X_ 257.046298323157$node_(0) set Z_ 0.000000000000$node_(0) set Y_ 239.438009831261$node_(0) set X_ 83.364418416244

#Define node movement model source movement-scenario-filese.g., scen-3-test

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

211

Another simple wireless simulation: Traffic Scenario

set udp_(0) [new Agent/UDP]$ns_ attach-agent $node_(0) $udp_(0)set null_(0) [new Agent/Null]$ns_ attach-agent $node_(2) $null_(0)set cbr_(0) [new Application/Traffic/CBR]$cbr_(0) set packetSize_ 512$cbr_(0) set interval_ 4.0$cbr_(0) set random_ 1$cbr_(0) set maxpkts_ 10000$cbr_(0) attach-agent $udp_(0)$ns_ connect $udp_(0) $null_(0)$ns_ at 127.93667922166023 "$cbr_(0) start"

set tcp [new Agent/TCP]$tcp set class_ 2set sink [new Agent/TCPSink]$ns_ attach-agent $node_(1) $tcp$ns_ attach-agent $node_(2) $sink$ns_ connect $tcp $sinkset ftp [new Application/FTP]$ftp attach-agent $tcp$ns_ at 150.00000000000000 "$ftp start"

#Define traffic model source traffic-scenario-filese.g., cbr-3-test

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

212

Another simple wireless example(5)

#Define node initial position in namfor {set i 0} {$i < 3 } { incr i} {

$ns_ initial_node_position $node_($i) 20}

#Tell ns/nam the simulation stop time $ns_ at 200.0 “$ns_ nam-end-wireless 200.00”$ns_ at 200.00 “$ns_ halt”

#Start your simulation $ns_ run

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

213

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-testand the output will be written in a file called scen-20-test.

Random movement$node start

See ns-2/indep-utils/cmu-scen-gen/setdest/

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

214

The traffic patterns generators

ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections] [-rate rate]

Generating CBR traffic patternso ns cbrgen.tcl -type cbr -nn 10 -seed 1 -mc 8 -rate 4.0

Generating TCP traffic patternso ns cbrgen.tcl -type tcp -nn 25 -seed 0 -mc 20

See ns-2/indep-utils/cmu-scen-gen/

Rede

s In

alám

bric

as y

Com

puta

ción

Ubi

cua/

2006

-200

7Re

des

Inal

ámbr

icas

y C

ompu

taci

ón U

bicu

a/20

06-2

007

215

Related software

TraceGraph: trace files analysero http://www.geocities.com/tracegraph/

BonnMotion: A mobility scenario generation and analysis toolo http://web.informatik.uni-bonn.de/IV/Mitarbeiter/dewaal/BonnMotion/

nscript: a graphical user interface to create ns-2 simulation scriptso http://www.people.virginia.edu/%7Eec3z/software.html

Blueware: Bluetooth Simulator for nso http://nms.lcs.mit.edu/projects/blueware/

BlueHoc: Bluetooth Performance Evaluation Toolo http://www-124.ibm.com/developerworks/opensource/bluehoc/

Technology

Unidad 2 Redes Manet