2.5.4 Mobile Ad-hoc Networks (manet)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Joseph Macker <macker@itd.nrl.navy.mil>
Scott Corson <corson@flarion.com>

Routing Area Director(s):

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

Routing Area Advisor:

David Oran <oran@cisco.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 Mobile Ad-hoc Networks WG (manet)
50th IETF Proceedings
MONDAY, March 19 2001 at 1930-2200

Minutes taken by Roger Kermode
==============================

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

AGENDA:

Agenda Bashing (5 min)

General Announcements (5 min)

AODV/DSR Experimental Status Progress (5 min)

Updates of Current Drafts
* DSR update, D. Johnson (Rice) (15 min)
* AODV update, C. Perkins (Nokia) (15 min)
* TBRPF update, R. Ogier (SRI) (15 min)
* OLSR update, T. Clausen (U. Aalborg) (15 min)
* ZRP drafts, P. Samar (Cornell) (15 min)
* Proactive Routing Team Update, T. Clausen (U. Aalborg) (25 min)

New Drafts
* PARO: Power-aware Routing Optimization, A. Campbell (Columbia) (15 min)
* DSR Flow Draft, D. Johnson (Rice) (15 min)

Closing Discussion (5 min)

Minutes
-------

There was a general announcements regarding the direction of progressing AODV and DSR for Experimental RFC consideration.

The results of recent WG Final Calls for Comment were summarized.

- AODV had a few comments integrated and provided a better discussion of handling unidirectional link conditions. The document was forwarded to the ADs prior to the meeting with a request to consider this for Experimental RFC.

- DSR had a few comments, and some basic packet formatting were changed in the specification. In light of the packet formatting changes made by the authors, the WG chairs decided to provide additional time for WG feedback and a second WG final call was issued last week and will end the week following the IETF.

* DSR update, D. Johnson (Rice) (15 min)
========================================

Dave Johnson provided an update of the DSR version 05 Internet Draft (ID). Dave indicated that the changes were mostly editorial and there were no behavioral modifications. There was a decision by the authors to modify the packet formats for future use. It was indicated that they contained the same info and there was some change in the ordering.

Dave emphasized that since the functionality has not changed the specification supports the extensive simulation and implementation work done in DSR.

Packet Format Changes are as follows:
-------------------------------------
- based on IPv6 packet format structure for flexible encoding: piggyback ctrl on data etc.
- problem was IPv6 isn't there yet, and Ipv4 doesn't support the necessary features. To make this work would have had to coordinate with lots of WGs and kernel implementers...
- So needed to
a) reduce number of places kernel had to be hooked into
b) reduce wasted space in packet header
- So new headers are built on top of IP
* standardization is *much* easier
* IANA assignments DSR Header and No Next header
- Now treat intermediary hops as a single virtual hop

DSR Pad1 and PadN options
-------------------------
- can use to help align multi-byte fields
- Assumption that CPU processing power is less than radio power

TBRPF update, R. Ogier and F. Templin (SRI) (15 min)
=====================================

An update and overview of the TBRPF ID was provided by R. Ogier and F. Templin. First, an overview of the protocol was reviewed. TBRPF is a proactive link-state protocol (like OLSR) and it uses differential triggered link state updates. In addition, message aggregation is used to reduce the number of messages. TBRPF requires the reliable transmission of control messages to neighbors and provides mechanisms for accomplishing this. There are two modes OLSR is specified to operate in. First, a full topology mode that is useful in sparse topologies and a partial topology mode that maintains minimum hop path information only.

Next a number of general changes introduced in the latest revision of the ID were discussed as follows:

- Partial Topology mode added
- neighbor or discovery protocol was improved
- unicast xmit eliminated for some packets
- checksum and NACK mode added
- Reliable sequence delivery via NACKs

Full Mode Update
-------------------
- Neighbor discovery using 3 hello msgs
1) Hello
2) Hello with RTI
3) Update request
4) Update Reply/Update Request
5) Update Reply
Update reply confirms that link is two way, and also exchanges topology information.

- Nackable updates used when one direction of a bidirectional link is thought to be down

Partial Mode Operation
----------------------
- report diffrential updates
- use Restricted Approximate Dijkstra

Simulation Results
------------------
Simulations were reported as underway and SRI is comparing the results with other manet protocols (Work in progress).

Skimmed topics
--------------
- periodic vs differential updates
- error control
- comparison with OLSR
- Extensions: mcast, unidir links, sleep mode (similar to OLSR) hierarchical routing (landmark routing)

Future Work
-----------
- sims in OPNET and ns-2 in 3 months
- incorporate new enhancements to futher improve the efficiency of TBRPF (PR and FT), including the use MPRs.
- extensions to sleep mode, unidiriectional links, and hierarchical routing
- improvements to TBRPF multicast
- Interaction with non-MANET IP networks

(SRI)
-----------
- Number of improvementws (incl IMEP)
- MSG aggregation in the TLV style
- 8 bit sequence number
Q: What happens if mobility causes the sequence number to wrap?
A: That is addressed in the ID, please read.

Joe Macker (comment): I would encourage focusing on getting the signalling right first, leave the more esoteric features/extensions for later.

AODV update, C. Perkins (Nokia) (15 min)
========================================
Charlie Perkins provided a discussion of AODV Last Call response and update. Charlie indicated that the AODV authors had incorporated some feedback over the past couple of months.

One modification involved the handling of a missing route reply.
* route replies have to be acked
* unacked route replies will cause a route to be black-listed

Q: That was a protocol change, right? Does this means that we need to another WG last call?
A: Not really a significant change just a clarification of the black listing text that was already there in the previous ID.

Joe: The WG chairs perceived that the modifications were minor and that received WG comments had been adequately addressed. We decided to move the document forward.

OLSR update, Philippe Jacquet (INRIA) (15 min)
=============================================
Philippe provided an overview of OLSR ID changes from 03 to 04.

There was a modification to make a more generic packet format.
Most activity has focused on the extension drafts (in progress) that focus in a number of areas including the following:

* power conversation
* unidir links
* fast mobility: use FAST-HELLOs
* mcast
* gateway and subnet

Q: If mcast source msgs are sent every 15 secs to all nodes in the network.
Does this mean that a node could wait up to 15 seconds for the claim msg to arrive?

A: Yes.

Joe: Let us wait until a draft is posted for the WG's benefit before discussing the details. We should stop further discussion of the topic until that is the situation.

To conclude the discussion, Philippe discussed work on OLSR that was done to provide border gateway support to a larger internetwork.

ZRP drafts, P. Samar (Cornell) (15 min)
=======================================

Prince Samar provided and update of ZRP drafts and ongoing work.

Current Approach Overview
----------------
- Bordercasting node identifies peripheral nodes
- Builds tree outwards like an onion

Problem with Current Approach
-----------------------------
- class system in effect
- difficult to analyze
- nodes must maintain info on extended zone
- current ZRP is as least as efficient as flood search but hard to show

Modifications to Approach
-------------------------
- NEIGHBOUR goes back to first step
- looks like flood abnd prune

CP: isn't building a tree on each iteration an expensive step?
A: we're still working on these issues.

Summary
-------
- modified ZRP performs better than ZRP

Proactive Routing Team Update, T. Clausen (U. Aalborg) (25 min)
===============================================================

Thomas Clausen reviewed the manet proactive routing team work that was formulated at the last IETF meeting. The design goal is to push towards a pro-active routing solution in conjunction to the reactive ones currently being worked on in the WG.

A number of proactive routing protocol within the WG include:

Topology based Reverse Path Forwarding
- Richard Ogier, Fred Templin,arargav Bekkur (SRI)

Fisheye State Routing
- Mario Gerla et.al. UCLA

Optimized Link State Routing
- Philippe Jacquet et.al. (INRIA)

Others (IARP/ZRP)

Thomas indicated that the team is looking presently at all approaches and trying to determine if there can be a common core functional document or if differences will not easily allow that to occur. There has been a reasonable amount of interaction among designers but the work continues to progress and has not gelled at this time. The team plans on establishing some goals for London to help progress towards some decision points.

Core issues that create design conflicts:
----------------------------------------
- Neighbor sensing can be done in different ways: differential, full
- Diffusion of topology information may be quite different: flooding, multipoint relay (MPR), tree

Optional issues that may need to be considered:
----------------------------------------------
- IP integration
- Multicasting
- Power saving
- Experimentation/Simulation

Joe Macker (comment): I would encourage people to consider link local multicast and IANA issues in their IDs. I have observed that many people continue to use broadcast for link local control messages and I would like to hear more discussion of why we should/should not to use multicast paradigms for link local functions (e.g., Hello mechanisms,etc).

Dave Johnson: 2 drafts exist on this issue.

General group input: There may be some remaining issues that remain unresolved for application to manet networks. There appeared to be group consensus that this was an issue and should be pursued further.

Joe Macker (comment): Let's focus on smallish 4 to 5 hop networks with up to 100 nodes. People will use this for home networks, etc, something near term useful. Don't over-engineer for 1000s to 1000000s of nodes yet, leave other extensions alone as well.

Some Current Activities within the Team
--------------------------------------
- OLSR Authors
* draft in version 4
There have been experiments using the FSR-option for OLSR and discussions with TBRPF-authors continue on including a TBRPF option for OLSR.

- TBRPF
* draft in version 1
new version with partial topology diffusion was added and there have been discussions wiht OLSR-authors on including OLSR-optimizations (MPR's) in TBRPF.

Joe Macker (comment): Let's shoot for naming documents produced by this team more generically .. not as extensions existing protocol(s) .. if and when they concern more general applicable solutions.

New Material Presentations:

PARO: Power-aware Routing Optimization, A. Campbell (Columbia) (15 min)
=======================================================================
- PARO tries to minimise transmission power involved in node to node communication
- PARO takes advantage of overhead transmission
- operates in single-hop topologies
* sensor networks
* home networks
- assumes that nodes operate in promiscuous mode
- determines if a single hop should be broken up into multiple shorter ones that require less power
- a node needs to hear both the sender and receiver to determine if it can break it into two hops
- http://www.comet.columbia.edu/~javierg/paro

Q What model are using for power reduction?
Q What about power in the support electronics etc?
A We're just focused on transmission power at this stage

DSR Flow Draft, Yih-Chun (CMU) (15 min)
==========================================

When the core DSR ID was simplified a result was the splitting out of the DSR-related flow path extensions. A new draft discussing this extension was recently produced and its contents were reviewed here. (See slides)

The DSR flow extension aims at minimizing flow state needed to be maintained in the network.

The process of establishing a flow path was reviewed.
This process includes support for the following:
1) standard request response mechanism for signalling
2) the establishment of flowid state in intermediary nodes
3) the removal of explicit source routes from subsequent packets

There are number of optimizations that were also reviewed.

* implicit flow ids
- low order bit is a flag that indicates default/non-default flow
* new data structures
- flow table
- default flow table; indexed by Src, Dst
- automatic route shortening table

Slides

Topology Broadcast Based on Reverse-Path Forwarding (TBRPF)