2.4.5 Mobile Ad-hoc Networks (manet)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

Joseph Macker <macker@itd.nrl.navy.mil>
Scott Corson <corson@isr.umd.edu>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>

Routing Area Advisor:

Rob Coltun <rcoltun@redback.com>

Mailing Lists:

General Discussion:manet@itd.nrl.navy.mil
To Subscribe: majordomo@itd.nrl.navy.mil
In Body: subscribe manet
Archive: ftp://manet.itd.nrl.navy.mil/pub/manet/manet.archive

Description of Working Group:

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.

Goals and Milestones:

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.

Oct 97

  

Post Internet-Drafts for candidate protocols.

Done

  

Discuss proposed protocols and issues. Redefine charter.

Feb 98

  

Submit Internet-Draft of MANET Routing Protocol Performanc Issues and Evaluation Considerations to IESG for publication as an informational RFC.

Feb 98

  

Submit Internet-Draft of MANET Terminology Document to IESG for publication as an informational RFC.

Mar 98

  

Revise candidate I-Ds as appropriate

Aug 98

  

Target demonstration of working software prototypes

Mar 99

  

Target interoperable implementations, and review any required protocol modifications. Publish as I-D

Dec 99

  

Document and submit protocol specification(s) to IESG as proposed standards

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2501

  

Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations

Current Meeting Report

Minutes of the Manet Working Group
3 August 2000 (1300-1500)

Scribe: R. Brian Adamson

There was one meeting of the manet WG held at the Pittsburgh IETF.
A number of revised IDs and a new proactive link state manet ID were presented.
Additional issues were raised and and open discussion was held towards the end of the meeting.

Agenda Bashing and Introduction - WG Chairs

A brief status update was provided to remind ID authors that there were a number of expired IDs of which future status and intention is unknown.

AODV Update - Charlie Perkins

A brief update of AODV was presented.
It was indicated that there has been major surgery performed on the AODV Internet Draft. The basic result of this has been a separation of functional specification for separate evolution and consideration. The previous draft was reworked and separated into a core unicast specification, a multicast specification, QoS extensions ID, broadcast specification ID, address autoconfiguration ID.

AODV additions as follows were described:

1) Gratuitous RREP
Have intermediate node send gratuitous RREP to destination for the source because the destination may not have a route to the source.

2) Local Repair
Let the node discovering a broken link try to find a short patch around it. This could save a network-wide RREQ ... If no luck send RERR as usual.

There was an intellectual property rights question from Dave Johnson. There was an IBM patent on DSDV. How does this affect present AODV? It was requested that Charlie look more into the specifics here and provide the WG some input on that issue.

3) RREP-ACK
Route discovery problem with asymmetric links ... minimize problem by _not_ sending RREP over asymmetric links

Next, an overview of the present Broadcast ID was provided:

This ID is not AODV and the technique may be more generalizable. The approach is used for sending data to 255.255.255.255 ... It uses IP fragment ID field & source IP address ... it causes each node to only transmit broadcast traffic once.

Joe Macker reminded the WG that autoconf and broadcast were _currently_ "individual submission" drafts, not yet MANET working group drafts. The WGneeds to provide more input on these specific issues to formulate further scoped work in this area.

Comment: Fragment ID field ... also needs offset for fragmented packets.

Something different may need to be done for IPv6 ... Note: if a broadcast "backbone" is available, it will be used ... no backbone formation algorithms are described. Charlie recommends that MANET may want to consider a backbone-forming algorithm.

Question: How long is a "short while" for keeping track of broadcasts?
Answer: Configurable parameter which should be no less than network transversal time.

Question: How do you know what this value is for congested networks.
Answer/Discussion deferred to later time by working group chair.

Address Autoconfiguration Draft:

Uses 169.254/16 as is done with AUTONET.
Assumes some sort of broadcast discovery mechanism.
How often to "do DADs" ... uses some reserved addresses for DAD process.

Comment by Charlie: This is a starter, more work needs to be done.

Multicast Draft:

Not very many changes. Multicast has some dependencies upon AODV draft.

QoS for AODV:
New ICMP message ... QOS_LOST

Questions deferred until later.

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

OLSR UPDATE - INRIA, Amir & Thomas

DRAFT CHANGES

1) Reaction to link specifc failures,
Triggered TC packets ... send on "specific" link failures
More event driven rather than doing faster periodic TC updates

2) New packet format,
To provide for backwards compatibility during development, etc, a "unified" packet format was created.
Many OLSR messages contain common properties. Messages can be concatenated in generic format allowing "piggybacking"
Extensions can be added so that nodes can ignore extensions they don't understand.

3) Provisions for protocol extensions.
Possible extensions: Multicast routing, power conservation, config/network operation, QoS

IMPLEMENTATION STATUS of OLSR

Thomas provided an overview of present implementation status of OLSR.

Implementations all run in user space without OS/kernel modification ... modify routing table and use organic OS packet routing & forwarding

These implementations are based on 01 version of draft and are_not_currently cross-compatible.

Preliminary Testing: mobility, link failure tests ... seems to be working as expected.

New implementations in progress at Aalborg & INRIA to be available "soon" (source code) "within a month or so".

More testing, interoperablity between versions, experiments with different extensions.

Question: What MAC layer is presently used?
Answer: 802.11 is presently used but independent of MAC layer

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

TBRPF - SRI International - new ID protocol presentation

Proactive, full-topology link state protocol, Updates are sent along a single path rather than flooded thus has greater efficiency than flooding.

INFOCOM 99 paper to prove correctness.

See view graphs for protocol overview/description.

Questions:
OLSR vs. TBRF link state messaging reduction

OLSR vs. TBRF HELLO packets -

OLSR does not yet consider cost of the link

Use of Unicast vs. Multicast messaging ... TBRF presentation mentions possiblity of unicast channels differentiate from multicast channels

Update Reliability:

Link State
Loop freedom? requires consistent data bases ... answer: temporary loops are possible but not permanent loops ... providing you reach convergence

802.11 ... bandwidth requirements ... scalability depends on HELLO interval ... more reactive requires shorter HELLO interval, but more control traffic.

Link cost in a dynamic network? answer: How is outside scope

Charlie: Merging MANETS? Changing to a common channel - answer - if you have host routes for everything _within_ the MANET you can get to them ... but issue is with visibilty of routes to networks exterior to the MANET.

Amir: ? receiver directed channels are not _required_ ... HELLO packets are sent on broadcast channel ... bi-directionality is required

Scott Corson: Comment hard state OSPF approach ... how do you achieve data base consisitency ... infrequent periodic updates can be provided.

Sean Dorian- comment on similarity of ISP OSPF network merges ... Map Exchange protocols ... research group some cross group applicablility

Joe Macker- How abstracted were the presented simulation results? Was all overhead considered ... MAC level reliablity, etc ... Answer: Simulation was very abstracted.

Amir: How are unidirectional links used? Not used - bi-directional but can be asymmetrically costed.

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

Monarch QoS DSR Demo - Dave Johnson

A quick overview of a DSR demonstration that was performed for DARPA was presented. The application was largely audio/video using Windows NetMeeting.

The testbed consisted of stationary and moving cars with 802.11 and it took place at the DARPA GloMo meeting July 11-13, Eatontown, NJ.

Dave Johnson summarized that the audio & video results were very good ... little/no glitches, but moving video source produced some higher rate video bursts ...

Question: How fast were you driving? 15-20 mph

What about TCP applications? Did TCP over 3 mobile hops ... ran NTP How did TCP perform? Tcp gets sluggish from time to time, given its operation ... DSR takes advantage of hop by hop ACKs (e.g. 802.11 acks) ... 99% packet delivery.

Is collected data available? Focus was demo ... so not much data was collected. there was not a real focus on data collection.

What is meant by QoS? best effort 802.11? standard off-the-shelf WaveLAN ... feedback to application, balanced route selection. bandwidth reservation? protocol measures what is available, and when that becomes insufficient applications are given feedback so they can throttle down if possible.

How dense can this be?

Question: Can an analysis be made of limits/applicability of each type of MANET?

Joe Macker: Applicability statements should be provided for protocols with differing characteristics... MANET WG scope is also an issue. Drafts should include applicability statements to partially answer these questions as best understood by the authors.

Dave Johnson: It is hard to completely answer these questions either by demo, analyses, or simulation.

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

Differential Destination Multicast - University of Maryland

A presentation of a new multicast ID was provided. This is a simpler multicast routing approach that is source-based and MAY be useful for small group use within manets.

Question on scalability: Implementation/platform vs. MANET bandwidth?

Uses destination address list, and unicast routing to delivery messages ... packet replication at intermediate nodes.

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

Working Group Status and Open Dicussion

Many drafts have expired, status? Please update the group and the chairs.

Would like to promote a design team approach for more generalized protocol components (e.g. address auto-configuration, broadcast, etc)

--

Over the past few meetings the WG chairs have been concerned about "feature-creep" within specification. They would like to see the scope of core unicast routing protocols simplified for early consideration.

AODV Status:

More general and complex components have been broken out: multicast, broadcast, auto-config, etc. This leaves a relatively clean document describing the core unicast functionality.

The AODV unicast draft MAY be ready to be considered for a WG LAST CALL leading to EXPERIMENTAL RFC status. What does the WG think?

Comment: Are we going to go through each of the protocols? DSR, etc ...
what is the purpose of this decision point? Are the chairs commenting on the AODV protocol separately without looking at other drafts ...

Chairs: AODV is an active ID while some others have expired and need updating. The mentioning of AODV here is not to imply the exclusion of others, but work has been done to clean-up and scope the document. Other documents should be considered by the WG, if offered, and when the authors feel they are in a mature state. At the last few meetings (DC and Australia), we discussed that core documents need cleaning up and that there was a need to remove feature creep from early proposal consideration (e.g., multicast, QoS, etc). We hope other author(s) will follow suit. We are also recommending EXPERIMENTAL status be considered when things are deemed ready because we want to encourage more implementation and experimentation of approaches.

Other group comment: I would like to see the documents simplified and better scoped and have some core unicast proposals progress forward for consideration.

Chairs: Agreed.

Chair comments on Proactive Routing Work: We would like to suggest scoping the WG to develop at most one IETF proactive link-state standard for manet... joint work between OLSR/TBRPF/STAR/IMEP draft authors to define common protocol is suggested. Comments?

This suggestion of a design team seemed to be well received and an early potential design team members began discussion on this issue.

David Oran suggested the WG go off and review what is meant and implied by EXPERIMENTAL status in RFC-2026 before beginning more detailed discussion of document progression. This gives the WG members a common base understanding for dicussion.

What does experimental RFC status mean? ... We believe it well-enough cooked that we encourage people to implement it and experiment with it and_may_ go on standards track if it fits ...

What simulation tool would be used for common link state work?

Amir: OLSR/TBRPF protocol work ... has idea to fold the two together ... SRI collaboration.

All: There needs to be a "fair process" for advancing status of drafts ...

Dave Oran suggested anyone who has a protocol they think is sufficiently mature submit for experimental status .. . "Last Call" mechanism could be used to make a group decision ...

Final Comments of Chairs: Clean up drafts ... limit scope? ... if they're not active, resubmit. We are also encouraging the formation of design teams in the more generalizable protocol areas and we would like to encourage more discussion of this soon on the mailing list.

Slides

A New Perspective on Hybrid Routing: Proactive Services for Reactive Protocols
Topology Broadcast Based on Reverse-Path Forwarding (TBRPF)