[manet] RE: manet digest, Vol 1 #268 - 6 msgs

"Norton, Mark, , OSD-C3I" <Mark.Norton@osd.mil> Wed, 27 November 2002 18:04 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22016 for <manet-archive@odin.ietf.org>; Wed, 27 Nov 2002 13:04:31 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARI6oT13512 for manet-archive@odin.ietf.org; Wed, 27 Nov 2002 13:06:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARI6nv13509 for <manet-web-archive@optimus.ietf.org>; Wed, 27 Nov 2002 13:06:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22010 for <manet-web-archive@ietf.org>; Wed, 27 Nov 2002 13:03:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHXFv10807; Wed, 27 Nov 2002 12:33:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHPLv10558 for <manet@optimus.ietf.org>; Wed, 27 Nov 2002 12:25:21 -0500
Received: from ddsmttayz003.sam.pentagon.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20285 for <manet@ietf.org>; Wed, 27 Nov 2002 12:22:31 -0500 (EST)
Received: by ddsmttayz003.osd.mil with Internet Mail Service (5.5.2653.19) id <XVYVH7P7>; Wed, 27 Nov 2002 12:25:12 -0500
Message-ID: <E6C9FD1649B9D54BB280C4787AF20E376F49CA@osdn5.osd.mil>
From: "Norton, Mark, , OSD-C3I" <Mark.Norton@osd.mil>
To: "'manet@ietf.org'" <manet@ietf.org>
Date: Wed, 27 Nov 2002 12:27:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] RE: manet digest, Vol 1 #268 - 6 msgs
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>


-----Original Message-----
From: manet-request@ietf.org [mailto:manet-request@ietf.org]
Sent: Wednesday, November 27, 2002 12:00 PM
To: manet@ietf.org
Subject: manet digest, Vol 1 #268 - 6 msgs


Send manet mailing list submissions to
	manet@ietf.org

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
	manet-request@ietf.org

You can reach the person managing the list at
	manet-admin@ietf.org

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


Today's Topics:

   1. Research news (=?iso-8859-1?Q?F=E1bio_Buiati?=)
   2. MAC & PHY interaction question (Yougu Yuan)
   3. Re: MAC & PHY interaction question (Don Montgomery)
   4. Re: Open this befo=?ISO-8859-1?B?cmUg0+/J+be9sc/Fvg==?=
(jomullen@nmsu.edu)
   5. FW: [mobile-ip] Dynamic Interfaces (was: 50 ms RA timer?) (Scott
Corson)
   6. MANET minutes (Joe Macker)

--__--__--

Message: 1
From: =?iso-8859-1?Q?F=E1bio_Buiati?= <fabio@redes.unb.br>
To: <manet@ietf.org>
Date: Tue, 26 Nov 2002 16:35:26 -0200
Subject: [manet] Research news

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C29569.D2F03EE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all.
I would like which are new research areas? IDS for Manets, Personal =
Firewall, ...

Thanks a lot.
---------------------------------------------------
F=E1bio Mesquita Buiati
email - fabio@redes.unb.br
Bras=EDlia - Brazil
---------------------------------------------------

------=_NextPart_000_007B_01C29569.D2F03EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I would like which are new research =
areas? IDS for=20
Manets, Personal Firewall, ...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>---------------------------------------------------<BR>F=E1bio =
Mesquita=20
Buiati<BR>email - <A=20
href=3D"mailto:fabio@redes.unb.br">fabio@redes.unb.br</A><BR>Bras=EDlia =
-=20
Brazil</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>---------------------------------------------------</FONT></DIV>=
</BODY></HTML>

------=_NextPart_000_007B_01C29569.D2F03EE0--


--__--__--

Message: 2
From: Yougu Yuan <yuanyg@cs.dartmouth.edu>
Reply-To: yuanyg@cs.dartmouth.edu
Organization: Dept. of Computer Science, Dartmouth College
To: manet@ietf.org
Date: Tue, 26 Nov 2002 14:13:23 -0500
Subject: [manet] MAC & PHY interaction question

Hi, all,

Here is a question about the interaction between the wireless MAC layer and 
the physical layer, but I think a "hardware" person is more likely to answer

it without a pause.

If the phy is receiving a packet, during which a "new" stronger ( >old
signal 
strength + capture threshold)  signal shows up, is the physical layer able
to 
tell that this is a "new signal", and start to notify the MAC layer to 
receive this new packet? Or will it go on blindly, only find out that there 
is a collision after receiving the old packet by checking the CRC, and
unable 
to recieve either packet in a whole piece?

Thank you.
-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College


--__--__--

Message: 3
Date: Tue, 26 Nov 2002 13:24:03 -0600 (CST)
From: Don Montgomery <montgo@utdallas.edu>
To: Yougu Yuan <yuanyg@cs.dartmouth.edu>
Cc: manet@ietf.org
Subject: Re: [manet] MAC & PHY interaction question


Hi Yougu,

In the case you pose, I believe there will be a collision
no matter what the rxg node does.  The PHY/MAC models I
have seen studied here assume a single channel.

Don

On Tue, 26 Nov 2002, Yougu Yuan wrote:

Hi, all,

Here is a question about the interaction between the wireless MAC layer and 
the physical layer, but I think a "hardware" person is more likely to answer

it without a pause.

If the phy is receiving a packet, during which a "new" stronger ( >old
signal 
strength + capture threshold)  signal shows up, is the physical layer able
to 
tell that this is a "new signal", and start to notify the MAC layer to 
receive this new packet? Or will it go on blindly, only find out that there 
is a collision after receiving the old packet by checking the CRC, and
unable 
to recieve either packet in a whole piece?

Thank you.
-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--__--__--

Message: 4
From: jomullen@nmsu.edu
Date: Tue, 26 Nov 2002 13:16:00 -0700
To: manet@ietf.org
Subject: Re: [manet] Open this befo=?ISO-8859-1?B?cmUg0+/J+be9sc/Fvg==?=

The referenced email appears to be a virus.

John Mullen

> ------------------  Virus Warning Message (on ietf-mx)
> 
> 024.bat is of type executable and is removed.
> 
> Please contact your network administrator for further information.
> 
> ---------------------------------------------------------
> 



--__--__--

Message: 5
From: Scott Corson <Corson@flarion.com>
To: "'Manet (manet@ietf.org)'" <manet@ietf.org>
Date: Tue, 26 Nov 2002 15:58:54 -0500
Subject: [manet] FW: [mobile-ip] Dynamic Interfaces (was: 50 ms RA timer?)

Oops...  meant to send this here.

-Scott

-----Original Message-----
From: Scott Corson [mailto:Corson@flarion.com] 
Sent: Tuesday, November 26, 2002 3:53 PM
To: 'Charles E. Perkins'; 'James Kempf'
Cc: 'mobile-ip@sunroof.eng.sun.com'; 'Manet (manet@itd.nrl.navy.mil)'
Subject: [mobile-ip] Dynamic Interfaces (was: 50 ms RA timer?)


> for Internet connectivity.  Mobile IP seemed to be quite well-regarded
> as a beneficial technology there.  I mentioned a couple of my
> pet peeves about current 802.11 device drivers and delays, and
> I got the impression that many (not all!) IEEE engineers in the
> meeting wanted to ensure that future products would work well
> with Mobile IP.

Increasingly, as the understanding permeates the industry that link layers
come and go, yet IP remains, link layer folks will begin to explicitly
design (or minimally to optimize) their technologies to plug into the
underbelly of an IP network.

The best thing the IETF could do IMHO would be to begin to *help* these
folks out.  

There is an increasingly broad class of link layer technologies under
development that, collectively, exhibit very 'dynamic' behavior.
Intermittent and varying connectivity is the norm, not the exception, for
this class of technologies.  And they need not be mobile technologies,
although this is the common case.

I think the IETF should define (or put into common practice) what is
essentially a new interface type--a "dynamic" interface--to be chosen for
use by these technologies if desired.  It should likely retain the
addressing semantics of a 'broadcast' interface--link layer unicast,
broadcast and multicast--yet ensure that the efficient, dynamic discovery of
'point-to-point' relationships between neighboring interfaces (generally
thru link layer mechanisms) can be communicated to the IP stack in a
standard way.  This mechanism would enable an IP stack to interact with this
new interface type in new ways.  This essentially requires standardizing
IP's "underbelly"--a term that Phil N. recently introduced on the PILC
list--to understand and work with dynamic interfaces.  

A 50ms RA timer is a pretty blunt instrument for assessing next-hop
reachability, and is inapplicable in many deployment scenarios.  If that is
the best you can do, then perhaps that is an answer, but it's certainly not
THE answer.  

A dynamic interface construct would be extremely general, and would likely
solve the problems that the recent interest in work on L2 triggers has hoped
to address.  It would apply to many technologies, and be useful in many
contexts where Mobile IP, MANET, Nemo and other such network layer protocols
must deal with link layer dynamics in a timely fashion.  It should also be
understood that the prerogative to act, to delay or to suppress these events
is still under the control of the IP layer.

-Scott

--__--__--

Message: 6
Date: Tue, 26 Nov 2002 17:48:31 -0500
To: minutes@ietf.org
From: Joe Macker <macker@itd.nrl.navy.mil>
Cc: manet@ietf.org
Subject: [manet] MANET minutes

Minutes of the Mobile Ad-hoc Networks WG (manet)
55th IETF Proceedings
Thursday, Nov 21 at 1300-1500

Minutes taken by Justin Dean
==============================

CHAIRS: M. Scott Corson <corson@Glue.umd.edu> 
              Joseph Macker <macker@itd.nrl.navy.mil> 

AGENDA:

(10 min) Agenda Bashing and Announcements
(20 min) Proposed Manet Way Forward
(10 min) Strawman Proposal for Charter and Milestone Update
(10 min) Related IRTF Activity Announcement
(10 min) Open Discussion of Proposal and Issues
(15 min) TBRPF Update
(15 min) DSR Update
(15 min) OLSR Update
(15 min) AODV Update
Closing

Joe Macker presented the agenda and opened it up for bashing.
The agenda was accepted as is with no bashing.

Joe Macker had some issues regarding the manet mailing list that he wished
to remind members about.

- There are 1969 members currently on the manet mailing list.
- Only members are allowed to post to the mailing list. Somewhat standard
practice, but not a perfect way to reduce spam, etc.
- Manet members should be aware when switching account names so that they
may still post effectively without moderator intervention.
- The newer ietf.org mailing list is reasonably automated; please use the
automated features to manage your own accounts whenever possible.
- NS2, GLOMOSIM, QUALNET, OPNET simulation software questions have recently
increased in volume.  Often simulation environment specific questions are
not appropriate for the mass manet mailing list, members are urged to
contact the authors of the code or appropriate simulation mailing list for
instruction questions, FAQs, etc.
 
MANET Way Forward (for details see presentation in proceedings)

Joe Macker presented an overview of a proposed way forward for the manet WG
that was being worked on in conjunction with the ADs. Recent perceived WG
status is that manet prototype implementation, designs, and experimentation
are very active. However, the WG has experienced significant "research
creep" into the ongoing work by continuing to consider broad work issues in
the manet problem space.  It is the intention of the chairs and the ADs to
update the charter of the WG to scope down to a focused engineering mode of
work.  The core approach is:

·       reduce the near term scope of the present WG
·       formulate an IRTF venue for manet research items, split off related
longer term research work from IETF
·       complete several mature unicast protocol ID work as EXPERIMENTAL
RFCs
·       formulate a focused problem statement(s)
·       convert core work items to an engineering mode and target common
Proposed Standard effort(s)

Alex Zinin: Routing co-AD (for details see presentation in proceedings)

Alex Zinin next discussed the proposed rechartering effort.  Alex mentioned
that he had posted a note to the list summarizing some of the issues as they
have emerged a few weeks back.  The summary is that very useful work is
being done in manet, but the WG is operating under a wide problem statement.
The perception is there are many competing protocols, a lack of WG-wide
consensus, and no signs of convergence. All of the above == research mode.

The goals of the proposed charter update would be to convert the WG to the
IETF mode:
                Clear and focused problem statement
                Focused WG charter, clear milestones
                WG members working closely towards consensus
                Design IETF MANET protocol STD

Work that needs more research (yes, it is somewhat subjective) will move to
the IRTF.

Proposed Steps:
        First, we create an IRTF sub-group for MANET and move LANMAR, FSR,
ZRP, TORA and similar work into this forum.  We would scope the charter to
push DSR, AODV, OLSR, and TBRPF to EXP and when done the WG will better
define the engineering problems statement. IF rough agreement is reached on
the problem statement we will update the charter with the development of
IETF protocol(s) that will go STD tracks.

Plan of actions 

We will discuss this more here and on the mailing list (nothing so far). We
will announce the decision within a month after this meeting.

Questions:
Q:      Will the rechartering approach cause delay in pushing forward EXP
RFCs for certain protocols already under consideration?
A:      No, that is not intended.

Q:      Will multicast work in manets be carried out in ietf or irtf?
A:      Lots of papers on this subject already, yet it remains to be decided
what is appropriate for engineering. Stay Tuned.
-------------------------------------------------------------

At this point, the Joe Macker polled the room for consensus on re-chartering
direction. Room consensus was attained to re-charter based upon the approach
presented..  Further mailing list input will be taken before reaching any
decisions.

Strawman Recharter Presentation - Joe Macker (for details see presentation
in proceedings)

Joe Macker presented some text and line items for consideration in an
updated charter/milestone effort. More discussion of this will take place on
the mailing list.

Strawman Near Term Milestones

Present: Restructure WG to be more narrowly focused, split off important
related IRTF work
Jan 2003 SUBMIT core reactive protocols for EXPERIMENTAL RFC (if not already
done)
Jan 2003 Revisit WG goals and problem statements
Mar 2003 SUBMIT core proactive protocols for EXPERIMENTAL RFC
Jun 2003 Develop and approve focused MANET WG problem statements and scoped
engineering goals.

Scott Corson: IRTF MANET research subgroup

Scott presented an overview of the manet-related IRTF plan.  Scalability is
the main research theme and some of the goals will be to foster discussion
and better understand the limitations of existing approaches (e.g., simple
flat reactive and proactive).  The group will look at proposing/developing
approaches that demonstrate superior performance (e.g., Hybrid/hierarchical
forms and radically new concepts).  More details will be formulated.  It has
been a concern that meetings may not be long enough and it is likely that
meetings may take place in concert with ongoing events to ease travel as
much as possible.

A new mailing list will be set up and announced on mailing list

Q:      Will multicast be in IRTF or IETF?
A:      Depends on the problem statement that the IETF works out and it may
be a mixed case given appropriate rationale of problems statements.

Q:      What is small/medium networks? Maybe 10-100 nodes but what about
movement models?  What type of movement scale are we using?
A:      We are aware that dynamic link/motion models, traffic flow models,
network surge conditions, and other factors affect any scalability
assessment besides number of router nodes.  We need some discussion of this
in problem and applicability statements.

Q: Other IETF groups have scalability in the charters so why are we getting
rid of it in this charter?
A:      It is not the intention to artificially limit the potential for
large area scalability, however we are not making it a requirement for
engineering maturity and applicability reasons.

Comment:        IRTF should be looking at the limits of current protocols
work as well.  This may be fed back to justify changing things in IETF.

Q: Would like to see IRTF and IETF groups work together closely; meetings at
same conference? 
A: Yes but the IRTF participants need freedom to do their research as well.

Q:  Need to keep problem statement simple.  Where does security belong?
What about IETF issuing standard without security in it?
A:  Need to discuss closer with the routing security working group.

Comment:  I see a need for simplicity of the protocol.  
Comment:  I think it would be extremely useful to get RFCs out that can be
used for 50-100 node scenarios.
Comment: HIP ipsec can help to bring improved security to manet.
Other comment: Systems are being develop that should work with wireless
networks.

Chair: Great comments, but we need to move one please bring further
discussions to the list.

TBRPF Update: Richard Ogier *see online presentation

TBRPF is now at Draft revision 6.  It has been rewritten to improve
readability. Hello message has been modified to include relay priority
similar to OLSR MPR preference.  It was clarified that tbrpf computes the
equivalent of MPRs.  There is now a relay priority in each hello.. OLSR MPR
willingness is same type of thing and this presents the possibility of
merging with OSLR. Other details (see presentation).  There is a new SRI IPR
statement registered at ietf.org.

DSR Update: Dave Johnson

(see on-line for details).  The final DSR ID for EXPERIMENTAL consideration
is not finished yet.  We are trying to add a few things to back into draft.
Stuff that was in version 3 of the ID.

OLSR Update: Thomas Clausen

(see on-line for details).  A new version of OLSR was update (now version
8).  Posting to ID editor was munged and the draft was posted to the list in
the interim.     There are no major changes.  The feedback was that most
people intending to use OLSR didn't want all the features.  They wanted
something like version 3 or 4.

AODV Update: Elizabeth Belding-Royer

AODV is now at ID version 12.  There we no major changes in this revision.
There was some clarification of local proactive repair.
        
http://sourceforge.net/projects/aodvimpl/ for aodv questions.
http://moment.cs.ucsb.edu/AODV/aodv.html





--__--__--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


End of manet Digest
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet