Last Modified: 2004-09-16
|Done||Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues.|
|Done||Agenda bashing, discussion of charter and of mobile ad hoc networking draft.|
|Done||Discuss proposed protocols and issues. Redefine charter.|
|Done||Publish Informational RFC on manet design considerations|
|Done||Review the WG Charter and update|
|Done||Submit AODV specification to IESG for publication as Experimental RFC|
|Done||Develop I-D for potential common manet encapsulation protocol approach|
|Done||Submit initial I-D(s) of candidate proposed routing protocols and design frameworks|
|Done||Promote implementation, revision, and testing of initial proposed I-D(s)|
|Done||Explore basic performance and implementation issues of initial approaches|
|Done||Explore proposed proactive protocol design commonalities|
|Done||Submit DSR specification to IESG for publication as Experimental RFC|
|Done||Submit OLSR specification to IESG for publication as Experimental RFC|
|Done||Submit TBRPF specification to IESG for publication as Experimental RFC|
|Done||Develop a further focused problem statement and address an approach for a common engineering work effort|
|Done||Reevaluate the WG's potential based on the problem statement consensus|
|RFC2501||I||Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations|
|RFC3561||E||Ad Hoc On Demand Distance Vector (AODV) Routing|
|RFC3626||E||Optimized Link State Routing Protocol|
|RFC3684||E||Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)|
MANET Minutes 11/10/04
Note Taker: Krishna Ramachandran
MANET draft agenda: See slides
Joe Macker (JM)
* Charter Revision update: See slides
Samita Chakrabarti - Does it make sense to define the application target in the charter?
Joe Macker - The goal is to design a light-weight but not necessarily an optimal routing solution. Constraints such as power saving need to be considered design. Mechanisms will be built in to support various policies such as energy saving, etc. Will post charter text on ML.
* DyMO: See slides
Ian Chakeres (IC)
Charlie Perkins (CP) - I Like path accumulation. We have to think about how to capture path info in smaller MTUs.
Justin Dean - Aggregate path accumulation information may be able to enable no reverse routes on RREQ processing. Will post more information to the list.
IC - I like path accumulation. The question is whether it should be required or not.
* Manet Proactive Routing Protocol (see slides)
Thomas Clausen (TC)
JM - Doing full-state flooding might be sensible for some n/w configurations.
TC - Yes. I am not precluding it from the spec, but I mentioned optimized partial topology dissemination because of all the work and the community consensus on this thus far.
CP - It is important that some nodes that implement only the base spec don't bog down the remaining nodes that support an extension that achieves some optimization. Don't ignore important optimizations because they are extensions.
JM - Document the design rationale when writing the spec.
TC - Is there a process for documenting the design rationale?
Brian Adamson - Specify 3 things in the doc: core baseline spec, extensions to typically include in an implementation, and finally some extensions that could be implemented in the future.
JM - The process of a design rationale should be open to the WG.
Alex Zinin (AZ) - Bring the design choices to the ML. Maybe write an information document on the design choices.
TC - Do we have to include all MAYs in the standard track document?
AZ - Typically MAYs are included for interoperability purposes. But there are no hard and fast rules.
Phillip Chimento - How about features that need to be used but are not present because the base spec doesn't support?
JM - Prioritize the known features to be deployed.
IC - Solutions for the interaction of unknown options are a common problem. If you know a solution please post it to the list. Otherwise we will do our best.
CP - Base protocol should not require to be designed for the majority of the cases. Things like expanding ring search, etc are known to be help optimize network operation. Should they be included?
JM - Base spec should satisfy many cases but cannot necessarily say that they satisfy the majority of cases.
CP - We plan to get the base doc out first. Then soon after, publish another doc with extensions, and then do this iteratively.
Pedro - Internet gatewaying results. (Please query for more information.)
JM - There are definitely some trade offs and different approaches for proactive vs reactive. More information would be helpful.
AZ - Focus on core functionality. Consider the implementation requirement before putting a feature into the core spec. If some feature is not going to be implemented, don't put it into the spec.
Rob Frye - Agreement with whats already been said about the core-extension design rationale.
* Simplified Multicast Forwarding for MANET (see slides)
Tom Henderson - Will there be a specific MANET multicast address for delivery of packet to all manet nodes?
JM - CP will address this. There might be some IANA assigned IPs.
Tom Anderson - Will multicast scoping be required?
JM - There are other ways to do scoping. So not necessarily in
the base spec.
Phil Chimento - Is the phy layer assumed to be 802.11? Does it matter?
JM - It matters but we chose 802.11 mac for availability of hardware.
Herbert Dens - Broadcast is done at the lower rate. This could eliminate higher throughput routes that the connected dominating set doesn't consider because it is formed using broadcast.
JM - This is a problem in MANET.
Unknown - Their implementation experience with MAODV might be relevant.
JM - Post the publication to the ML.
Justin Dean - Implementation specific issue about IP to Mac address mapping.
Li Li - Is the forwarding mechanism per packet or precomputed?
JM - Precomputed.
* Simplified Manet Multicast Routing Protocol (SMURF) (Slides)
Tom Henderson - Can we do things like cross-layer optimization in the multicast forwarding algorithm?
CP - Might be ambitious to include initially but definitely worthwhile considering.
JM - Is there consensus that multicast work is useful? Does anyone have any negative feedback about this charter item?
Luke Klein-Berndt - Yes. It will be very useful for work we are doing at NIST.
Unknown - Yes. Even for sensors.
Li Li - Very useful for our work.
* First OLSR Interop Report (Slides)
Unknown - Immediately following MANET is a BOF on IPv6 over IEEE 802.15.4.
CP - Pulsing power conserving solution: Consider such solutions as part of the design process. Will post reference to the list.
* MANET AutoConf (see slides)
JM - Too many solutions in the basket. Need to explore more. Possibly also explore collaboration with other groups. Not necessarily a routing area issue.
AZ - Start discussion on ML. Request for a BOF after some consensus is reached.
Paal Engelstad - If autoconf is going to be a BOF, include service discovery also.
JM - Time is up, please thrash it out on the ML.