Subject: [manet] Re: manet Digest, Vol 17, Issue 23

From: "rv72" <[email-masked]>
Date: Sun, 02 Oct 2005 08:22:53 +0530

dear sir.

 kindly help me for how to download glomosim simulation tool.

rv

[email-masked] wrote:
Send manet mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/manet
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of manet digest..."

Today's Topics:

   1. Re: Hello messages in AODV (Carles G?mez)
   2. CFP: IEEE Workshop on Dependability and Security in Sensor
      Networks and Systems (Moustafa Youssef)
   3. RE: Hello messages in AODV (Gabi Kliot)
   4. DYMO packet format (???)
   5. RE: Hello messages in AODV (Mullen, John)

----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Sep 2005 20:48:02 +0200
From: Carles G?mez <[email-masked]>
Subject: Re: [manet] Hello messages in AODV
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Hola Alicia, 

The lack of a number of Hello messages from a neighbor in an active route may 
be used as a way to detect a link failure. 

A study on the impact of the hello message mechanism on a lab AODV ad-hoc 
network has recently been published in PIMRC'05. The paper is 
entitled "Evaluating performance of real ad-hoc networks using AODV with hello 
message mechanism for maintaining local connectivity". Some tradeoffs 
(reactivity to topology changes Vs. bandwidth and power consumption) are 
evaluated as a function of HELLO_INTERVAL. If you are interested in 
it, please e-mail me.

Best regards, 

Carles Gomez i Montenegro 
Technical University of Catalonia 

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

------------------------------

Message: 2
Date: Thu, 29 Sep 2005 22:48:30 -0400
From: "Moustafa Youssef" <[email-masked]>
Subject: [manet] CFP: IEEE Workshop on Dependability and Security in
	Sensor	Networks and Systems
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="iso-8859-1"

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                   Call for Papers
       Second IEEE Workshop on Dependability and Security in
                    Sensor Networks and Systems
                            (DSSNS'2006)
                        http://www.dssns.org
                        In conjunction with
              2nd NASA/IEEE Systems and Software Week
        30th NASA/IEEE Software Engineering Workshop (SEW'2006)
            Columbia, Maryland, USA ~ April 24-28, 2006

Recently, there has been a growing interest in the potential use
of networked sensors in applications such as smart environments, 
disaster management, combat field reconnaissance, and security 
surveillance. While the initial view of the community was that 
networked sensors will play a complementary role that enhances 
the quality of these applications, recent research results have 
encouraged practitioners to envision an increased reliance on sensor 
networks and systems (SN&S) in such critical and sensitive 
applications. Therefore to realize their potential, necessary 
dependability and security (D&S) measures have to be 
incorporated in the design and during the operation of SN&S. 
Dependability is usually specified using attributes like reliability, 
survivability, safety, maintainability, and availability in presence 
of failure, while security is specified by attributes like integrity, 
authenticity, confidentiality, and availability in presence of 
attacks. D&S services accomplish tasks for attack and
failure prevention, detection and response. The scope of D&S 
services may span the deployed sensors to command nodes 
and likely beyond. It also involves D&S support at, and 
cross-cutting, the protocol stack layers from physical to 
application.

Achieving dependability and security in SN&S will require 
non-conventional mechanisms due to many factors including: 
(1) sensors are significantly constrained in the amount of 
available resources such as energy, storage and computation; 
(2) sensors are expected to be deployed in very large numbers 
in normal as well as harsh/hostile environments; (3) sensor 
networks suffer from structural weakness and limited physical
protection, and (4) localization of impact is complicated due 
to the un-tethered nature of SN&S and of the potential 
attackers. In addition, D&S requirements may vary according
to mission defined over a multi-dimensional context, such 
as field of deployment (e.g., hostile versus friendly), type of 
application (e.g., monitoring, tracking, data collection), mode 
of operation (e.g., normal, exception, post-event recovery), 
and time.

This workshop will foster a forum for discussing and presenting 
recent research results on dependability and security in SN&S. 
Topics of interest include, although not limited to, the following:

- Fault and intrusion-tolerant architectures, middleware and operational
models 
- Robust routing, storage, and processing of sensed data
- D&S architectures, protocols and tools
- Vulnerabilities, attacks and countermeasures
- Monitoring and evaluation techniques
- Robust clustering techniques
- Self-awareness and context-awareness 
- Resilient virtual infrastructures
- Autonomic and adaptive D&S support.
- Formal representation and verification of D&S properties
- Network inference support for D&S
- Quality of service provisioning
- Models, metrics, and measurements for D&S
- Privacy-aware D&S services
- Testbeds, simulation and visualization 
- Agent-based D&S management 
- SN&S support for D&S in larger information grids
- SN&S application development environments

Submission Guidelines
---------------------
For guidelines regarding paper submission, please refer to the
workshop’s 
website (http://www.dssns.org). Papers should contain original material 
and not be previously published, or currently submitted for
consideration 
elsewhere. The manuscript should not exceed 20 single-column
double-space 
pages in PDF format, font size 11 or larger. The first page should
include 
title, authors' contact information, abstract and five keywords. 

Important Dates
----------------
Submission deadline:	November 7, 2005
Decision notification:	December 20, 2005
Final manuscript due:	January 20, 2006

The accepted papers will appear in a proceedings published by IEEE.
The best paper will be recognized and selected papers will be invited to

a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks. 

Workshop Co-Chairs
-------------------
Mohamed Eltoweissy
Virginia Tech, USA
E-mail: [email-masked] 

Mohamed Younis
University of Maryland Baltimore County, USA
E-mail: [email-masked] 

Publicity Co-Chairs
--------------------
Denis Gracanin
Virginia Tech, USA
E-mail: [email-masked]

Moustafa Youssef
University of Maryland at College Park, USA
E-mail: [email-masked] 

Program Committee
------------------
Farooq Anjum, Telcordia & U. of Penn, USA
David Carman, Johns Hopkins U.– Applied Physics Lab, USA
Ing-Ray Chen, Virginia Tech, USA
M. Nazih Elderini, Alexandria U., Egypt
Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA
Ahmed Helmy, University of Southern California, USA
Sushil Jajodia, George Mason U., USA
Shivakant Mishra, U. of Colorado, USA
Peng Ning, North Carolina State U., USA
Cristina Nita-Rotaru, Purdue U., USA
Stephan Olariu, Old Dominion U., USA
David Simplot-Ryl, U. Lille, INRIA Futurs, France
Mani B. Srivastava, U. of California – Los Angeles, USA
John A. Stankovic, U. of Virginia, USA
Ivan Stojmenovic, U. of Ottawa, Canada
Gene Tsudik, U. of California-Irvine, USA
Cliff Wang, Army Research Office, USA
Stephen D. Wolthusen, Fraunhofer-IGD, Germany
Albert Zomaya, U. of Sydney, Australia

------------------------------

Message: 3
Date: Fri, 30 Sep 2005 10:09:58 +0200
From: "Gabi Kliot" <[email-masked]>
Subject: RE: [manet] Hello messages in AODV
To: " 'Carles G?mez' " <[email-masked]>,	<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="windows-1255"

Hi

The lack of a number of Hello messages from a neighbor is sure one of
the ways to detect link failures.
I would say that it is a proactive way to detect link failures.

The reactive way is for routing protocol to receive MAC layer
notifications after MAC fails in all its retransmission for a single
message.
Here the number of MAC layer retransmissions would play an important
role on the performance of routing algorithm and on the bandwidth and
power consumption. The smaller the number of MAC retransmissions - the
faster we will detect the link failure, the less power is wasted and
etc.. But on the bad side: the smaller the number of MAC retransmissions
- the higher is the chance for "false alarms", false detection of link
failure, which could actually be caused by temporal contention. Such
false alarm will destroy perfectly good route, can cause useless RERR
messages, etc...
As far as I know, the usually common number of MAC retransmissions is
6-7.

MAC layer failure notifications are also simulated in NS-2 and in
Glomosim.

One of the interesting ideas here could be to evaluate the tradeoffs
(the ones Carles mentioned) as a function of both HELLO_INTERVAL and MAC
layer retransmissions.

Best regards,

Gabi Kliot
Technion - Israel Institute of Technology

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Carles Gómez
> Sent: Thursday, September 29, 2005 8:48 PM
> To: [email-masked]
> Subject: Re: [manet] Hello messages in AODV
> 
> 
> Hola Alicia, 
> 
> The lack of a number of Hello messages from a neighbor in an 
> active route may 
> be used as a way to detect a link failure. 
> 
> A study on the impact of the hello message mechanism on a lab 
> AODV ad-hoc 
> network has recently been published in PIMRC'05. The paper is 
> entitled "Evaluating performance of real ad-hoc networks 
> using AODV with hello 
> message mechanism for maintaining local connectivity". Some tradeoffs 
> (reactivity to topology changes Vs. bandwidth and power 
> consumption) are 
> evaluated as a function of HELLO_INTERVAL. If you are interested in 
> it, please e-mail me.
> 
> Best regards, 
> 
> Carles Gomez i Montenegro 
> Technical University of Catalonia 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 

------------------------------

Message: 4
Date: Fri, 30 Sep 2005 18:20:49 +0900
From: ??? <[email-masked]>
Subject: [manet] DYMO packet format
To: <[email-masked]>
Message-ID: <002501c5c5a0$3f2118a0$6e0246dc@dcnmuxxc1>
Content-Type: text/plain; charset="ks_c_5601-1987"

Hi all. 
. 

In DYMO Spec., LEN field of the fixed packet format makes me difficult to implement. 
Any body knows why the length of Len field is 12 bits ?
. 
It is too difficult to transform from LITTLE ENDIAN to BIG ENDIAN and vice versa. 
. 
Please give me any advice or comments. 

Thanks in advance,
Kwak. 
-------------- next part --------------
An HTML attachment was scrubbed... 
URL: http://www1.ietf.org/pipermail/manet/attachments/20050930/881d7898/attachment.htm

------------------------------

Message: 5
Date: Fri, 30 Sep 2005 08:50:33 -0600
From: "Mullen, John" <[email-masked]>
Subject: RE: [manet] Hello messages in AODV
To: <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="windows-1255"

Hi,

The number of MAC retransmissions has other significant effects.  In a MANET, transmission range is a function of the usual propagation conditions, plus the nature of link failure detection and the routing protocol itself.  If the number of retransmissions is too high, the protocol tends to retain a poor link too long, rather than search for a better one.  Since the mean number of transmissions is highest at the limit of transmission range, the network's performance is very sensitive to this setting.  Using Rayleigh fading as a first-order approximation to the variation in received signal strength, we have simulation results that indicate that the maximum number of MAC retries should be limited to two or three, unless the net is locally sparse.  Using a retry limit of six or seven can halve throughput and sharply increase mean delay.  Here is a paper which discusses this topic, among others.  The discussion of this particular point begins at the bottom of page 7.

http://web.nmsu.edu/~jomullen/MyPapers/Mullen-MWCN_2004.pdf

I will be presenting a paper that focuses more on this subject, as well as more on the impact of Hello messages, in two weeks at MSWIM in Montreal. If you want to check back I should have that paper on my web site by the end of October.

http://web.nmsu.edu/~jomullen/MANET.html

John P. Mullen
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabi Kliot
Sent: Friday, September 30, 2005 2:10 AM
To: 'Carles Gómez'; [email-masked]
Subject: RE: [manet] Hello messages in AODV

Hi

The lack of a number of Hello messages from a neighbor is sure one of the ways to detect link failures.
I would say that it is a proactive way to detect link failures.

The reactive way is for routing protocol to receive MAC layer notifications after MAC fails in all its retransmission for a single message.
Here the number of MAC layer retransmissions would play an important role on the performance of routing algorithm and on the bandwidth and power consumption. The smaller the number of MAC retransmissions - the faster we will detect the link failure, the less power is wasted and etc.. But on the bad side: the smaller the number of MAC retransmissions
- the higher is the chance for "false alarms", false detection of link failure, which could actually be caused by temporal contention. Such false alarm will destroy perfectly good route, can cause useless RERR messages, etc...
As far as I know, the usually common number of MAC retransmissions is 6-7.

MAC layer failure notifications are also simulated in NS-2 and in Glomosim.

One of the interesting ideas here could be to evaluate the tradeoffs (the ones Carles mentioned) as a function of both HELLO_INTERVAL and MAC layer retransmissions.

Best regards,

Gabi Kliot
Technion - Israel Institute of Technology

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Carles Gómez
> Sent: Thursday, September 29, 2005 8:48 PM
> To: [email-masked]
> Subject: Re: [manet] Hello messages in AODV
> 
> 
> Hola Alicia,
> 
> The lack of a number of Hello messages from a neighbor in an active 
> route may be used as a way to detect a link failure.
> 
> A study on the impact of the hello message mechanism on a lab AODV 
> ad-hoc network has recently been published in PIMRC'05. The paper is 
> entitled "Evaluating performance of real ad-hoc networks using AODV 
> with hello message mechanism for maintaining local connectivity". Some 
> tradeoffs (reactivity to topology changes Vs. bandwidth and power
> consumption) are
> evaluated as a function of HELLO_INTERVAL. If you are interested in 
> it, please e-mail me.
> 
> Best regards,
> 
> Carles Gomez i Montenegro
> Technical University of Catalonia
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

------------------------------

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

End of manet Digest, Vol 17, Issue 23
*************************************
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com

Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now!

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet