NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Joseph Macker <firstname.lastname@example.org>
Scott Corson <email@example.com>
Rob Coltun <firstname.lastname@example.org>
Abha Ahuja <email@example.com>
Abha Ahuja <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe manet
A "mobile ad hoc network" (MANET) is an autonomous system of mobile routers (and associated hosts) connected by wireless links--the union of which form an arbitrary graph. The routers are free to move randomly and organize themselves arbitrarily; thus, the network's wireless topology may change rapidly and unpredictably. Such a network may operate in a standalone fashion, or may be connected to the larger Internet.
The primary focus of the working group is to develop and evolve MANET routing specification(s) and introduce them to the Internet Standards track. The goal is to support networks scaling up to hundreds of routers. If this proves successful, future work may include development of other protocols to support additional routing functionality. The working group will also serve as a meeting place and forum for those developing and experimenting with MANET approaches.
The working group will examine related security issues around MANET. It will consider the intended usage environments, and the threats that are (or are not) meaningful within that environment.
Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues.
Agenda bashing, discussion of charter and of mobile ad hoc networking draft.
Post Internet-Drafts for candidate protocols.
Discuss proposed protocols and issues. Redefine charter.
Submit Internet-Draft of MANET Routing Protocol Performanc Issues and Evaluation Considerations to IESG for publication as an informational RFC.
Submit Internet-Draft of MANET Terminology Document to IESG for publication as an informational RFC.
Revise candidate I-Ds as appropriate
Target demonstration of working software prototypes
Target interoperable implementations, and review any required protocol modifications. Publish as I-D
Document and submit protocol specification(s) to IESG as proposed standards
Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations
Minutes of the Mobile Ad-hoc Networks WG (manet)
51th IETF Proceedings
MONDAY, 6 August 2001 at 0900-1130
Minutes taken by R. Brian Adamson
CHAIRS: Joseph Macker firstname.lastname@example.org
M. Scott Corson email@example.com
-- Updates to Core OLSR, T. Clausen (U. of Aalberg)
-- Updates to TBRPF, R. Ogier (SRI)
-- DSR Performance results with Flow State, Y. Hu (Rice)
-- ZeroConf and Manet Issues, E. Guttman (Sun)
-- Stateless address autoconfiguration in Mobile Ad Hoc Networks using site-local address(draft-park-zeroconf-manet-ipv6-00.txt), J. Park (ETRI)
-- General WG discussion of manet addressing
-- Unidirectional link support draft -- T. Clausen (U. of Aalberg)
-- General WG discussion of manet unidirectional link support
-- MANET TCP Performance via ns2 simulation -- T. Clausen (U. of Aalberg)
-- OLSR Multicast draft -- T. Clausen (U. of Aalberg)
-- ADMR Multicast draft -- D. Johnson (Rice)
-- General WG discussion of multicast status
Agenda Bashing (5 min)
OLSR CORE UPDATE - T. CLAUSEN
A "soon-to-be" updated version of the Optimized Link State Routing (OLSR) specification was discussed. The authors missed the ID cutoff date for London but will submit a revised ID shortly after the IETF. An initial document was provided to the mailing list for comment and perusal prior to the London meeting. Some of the significant changes include the following:
(1) The revised OLSR specification provides support for multiple interfaces:
This capability is provided by a routing node using one of its addresses as its "main address" or "router ID"- and having control messages transmitted on all interfaces.
(2) The revised OLSR specification adds the ability to support routing advertisement of associated hosts and networks
A new message type is added that allows for host/network route injection for non-participating OLSR nodes within an OLSR cloud.
(3) The revised OLSR specification discussed mechanisms for improved neighbor sensing and control packet jitter
The random jitter helps prevent transmission syncing among clusters of nodes and improves performance in 802.11 MAC layers with multi-hop channel contention. Recent OLSR implementors have been experimenting with Jitter and improved neighbor sensing algorithms.
Q: Regarding control packet jitter - why is this optional when several experimenters have noticed this is an important feature, especially in 802.11-like environments?
A: Jitter hasn't been tried for "all" MAC layers ... some may not need this. we are still learning about its benefits and did not wish to make it mandatory at this time.
Q: We are you using exclusive subtraction of the jitter interval? Should this not be a random amount around an average interval.
A: Our rationale relates to the maximum holding timeout of the control-oriented database, using subtraction always ensures that x message events occur +AF8-before+AF8- the timeout.
Finally, the authors announced that the next ID will use the appropriate header statement that is fully RFC 2026 compliance
TBRPF UPDATE - RICHARD OGIER
A "soon-to-be" updated version of the TBRPF specification was next discussed. As in the case of OLSR, the authors missed the ID cutoff date for London but will submit a revised ID shortly after the IETF. An initial document was provided to the mailing list for comment and perusal prior to the London meeting. Some of the discussion included the following:
The authors have done further work on a partial topology (PT) version of TBRPF that is intended for improved performance in for dense topologies (vs. full-topology)
There are changes planned in the upcoming specification to reduce overhead and to modularize the neighbor discovery method. The use of differential HELLOs introduced along with periodic HELLOs, and the use of NACKs for reliable control delivery was dropped.
The following question was concerning comparison between OLSR +ACY- TBRPF ... in the example shown.
Q: For how long does a node have to keep entries?
A: 3 Hellos
Q: Reporting neighbors when there is a change, but doesn't report when there is no change? How does it work robustly?
Q: Why was it stated that full topology is required for QoS routing?
A: full topology "helps" ... multiple path information helps
The WG seemed to agree that required was too strong a term to use in this context.
Q: On slide 7, correction: provides min hop path to all destinations, not all neighbors
A+ADs- Yes, that is incorrectly stated
Q: Status of a potential OLSR/TBRPF merger as a proactive routing team product?
Ogier: still alot of differences.
Q: How are the groups working together?
Clausen: It's not clear they will merge, still many differences
Ogier: AODV/DSR have had nice simulation studies, the same should be done for OLSR/TBRPF ...
Clausen: the protocols are not necessarily competing, we're investigating the components of the protocols ... what works, what works best, etc.
Macker: The proactive design teams initial goal was to study potential component building blocks ... HELLO mechanisms, etc and report on any potential consensus of reuse or technical commonality.
Macker: What is the basic result of looking at the HELLO mechanisms for example?
Thomas: From previous TBRPF draft, they didn't appear so common because of TBRPF/OLSR differences but this may be changing.
Thomas: Merging HELLO mechanisms puts burdens on both protocols. Making something generic would add a lot of complexity.
Richard: Changes to TBRPF reflect "taking in the best of OLSR"
Thomas: OLSR more is perhaps more in common with Mobile Mesh than TBRPF
Anon: We should consider the "new" drafts before further detailed discussion.
Anon: There is a potential for loss of optimization if a generic HELLO approach is used.
Perkins: AODV can use HELLO messages but doesn't with link layer knowledge. Also, I believe an AODV/DSR combination is "not" impossible as some have stated in the past.
There was discussion that the proactive routing team had some early goals to explore commonalities of approaches. There appeared to be some recent convergence but still numerous differences were cited. There was agreement that since the updated IDs were due out soon that further technical discussion and debate could be taken to the list at the appropriate time.
What is the status of the WG documents that were put forward for EXPERIMENTAL RFC Consideration?
Macker: The area directors had provided initial feedback that the documents looked good. Recently, the DSR document was kicked back because of an improper header statement for RFC consideration. Unfortunately, the WG chairs learned that the AODV ID was held up because of the DSR header issues, and it was recently clarifed to ADs that docs should be treated and reviewed on an independent schedule. The DSR authors have been queried several times regarding their intentions to submit a header statement revision. They have indicated they will do so shortly.
Johnson: DSR doesn't anticipate changes.
Perkins: What does a "stable snapshot" of an "Experimental" RFC mean?
Perkins: We would like to go forward with what we have.
There was rough consensus that the WG would proceed forward with the documents as they were after the prvious WG Last Call.
Macker: We will re-request to the ADs that these documents should be progressed for consideration and IESG reviewed as soon as possible and that they be handled on an independent review schedule.
EVALUATION OF FLOW STATE IN DSR - Yih-Chun Hu
An overview of the DSR flow state extensions and studies was provided. The flow state in DSR used a IP source, dest, flowID concatenation, FlowID can be handled implicitly or explicitly.
A route error is sent if a flow is not recognized.
There were numerous simulations performed and these will be discussed at the upcoming Mobihoc 2001.
Question: With implicit flowId, isn't intermediate re-routing lost?
Answer: No ... ???
ZEROCONF CONSIDERATIONS - ERIK GUTTMAN
Erik provided a discussion of zeroconf issues and emerging questions and how they potentially relate to the manet WG. Some related peripheral issues had recently been raised on the manet mailing list regarding generic multihop flooding and multicast services. E.g., consideration of ALL-MANET-ROUTER addressing and forwarding schemes,etc.
In summary, claim and defend approaches are typically used to autoconf,... The possibility to apply autoconf to MANET exists but some more complex issues need to addressed than are typically considered within autoconf. There is a need to consider and address scoping issues given the ad hoc and multihop wireless nature of a manet. There is a tradeoff of periodic messaging vs. de-conflict through normal usage. The latter implies some aspect of multicast in normal usage.
zeroconf vs. configured modes of operation were discussed.
ALL-NODES-MULTICAST address, scoping, reasonable flood mechanism needed. mini-DHCP server interaction
Question: Claim and Defend ... how is rapidly changing topology dealt with. Can MANET protocol mechanisms (e.g., efficient flooding) be leveraged? Are all host routes available? duplicate address detection ...
Perkins: If network fragments ... have you looked at a previous expired WG draft on autoconf issues that was discussed within manet.
A: No, I did not realize that existed, but I have comments for the upcoming autoconf presentation.
STATELESS ADDRESS AUTOCONFIG
A short proposal was presented relating to stateless address autoconfiguration for manet.
macker: Why its relatively unrelated to your presentation issues, Why was it defined in your slides that a MANET node has to be an end system host? Manet algorithms can run in end systems or in intermediate routers so this distinction doesn't seem important.
guttman: We're really just configuring an interface so the point of whether the node is a host or router is moot.
Question: Why is a subnet id generated? site-local vs. link-local, site-local can be multihop.
The presentation was cut short due to time constraints and the consensus seemed to be that there were some basic issues to be worked out with the approach.
BUILDING TOPOLOGY GRAPH IN OLSR (bi-directional +ACY- unidirectional) - T. Clausen
Thomas Clausen provided some brief description of work done with OLSR to further explore unidirectional routing links within the topology.
Challenge: How to transmit data over a unidirectional link. How to make ARP work, 802.11 issues, etc
Perkins: Have you checked against work being done in UDLR....refer to another working group on unidirectional routing...
There was some brief discussion and debate on the merit of trying to use unidirectional routes in the topology.
TCP PERFORMANCE IN MANET - T. Clausen
Thomas Clausen provided some brief description of work done to further explore TCP interaction with some example manet routing protocols. Some brief comparisons showed that by simulating OLSR and AODV (w/o link layer detection) there was a trend for OLSR to demonstrate significantly improved TCP throughput in some scenarios, while the CBR test results demonstrated similar perfomrance. The main point was that under different traffic scenarios and topologies routing end-to-end results can vary greatly.
Johnson: It has been previously shown that TCP performance has issues under various scenarios.
Johnson: ....the question should have been Why does TCP work better via OLSR in this scenario?
Clausen reiterated that the results were intended to demonstrate that under various scenarios results can be quite different, especially considering TCP performance. There were no grand claims being made here and there was a reiteration that more work needed to be performed. It was generally agreed that these results are preliminary and that more in-depth tools and further analysis are needed to answer deeper questions as appropriate.
MULTICAST IN OLSR - Anis Laouiti
Anis briefly presented findings and thoughts on working with a multicast version of OLSR. There was an issue by Anis that he feels that IGMP and wireless multi-hop operation is broken since the link has a semi-broadcast nature. In an approach he has been evaluating each node chooses its multicast router. (routers periodically announce themselves).
Macker: Are these recommendations for IGMP extensions for wireless and if so should they go under MANET? or a different working group.
Ogier: Question about extensions ...???
Thomas: limited broadcast, etc, what should be used? some considerations concerning multicast should be discussed. e.g. all nodes, neighbor cast, etc
ADMR - Jorjeta Jetcheva (CMU)
A brief presentation of new multicast routing protocol for ad hoc networks was provided. The chairs pointed out the the ADMR ID woud be downgraded to personal until the WG had come to consensus on future multicast work and direction.
The meeting was concluded.
Proposed Changes to TBRPF
Adaptive Demand-Driven Multicast Routing (ADMR) in Wireless Ad Hoc Networks
Evaluation of Flow State in DSR