2.5.7 Mobile Ad-hoc Networks (manet)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MANET Page

Last Modified: 2005-07-27

Chair(s):

Joseph Macker <macker@itd.nrl.navy.mil>
Ian Chakeres <idc@cs.ucsb.edu>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: manet@ietf.org
To Subscribe: manet-request@ietf.org
In Body: subscribe manet
Archive: http://www.ietf.org/mail-archive/web/manet/index.html

Description of Working Group:

The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application within
both static and dynamic topologies with increased dynamics due to node
motion or other factors.

Approaches are intended to be relatively lightweight in nature, suitable
for multiple hardware and wireless environments, and address scenarios
where MANETs are deployed at the edges of an IP infrastructure. Hybrid
mesh infrastructures (e.g., a mixture of fixed and mobile routers)
should also be supported by MANET specifications and management features.

Using mature components from previous work on experimental reactive and
proactive protocols, the WG will develop two Standards track routing
protocol specifications:

- Reactive MANET Protocol (RMP)
- Proactive MANET Protocol (PMP)

If significant commonality between RMRP and PMRP protocol modules is
observed, the WG may decide to go with a converged approach. Both IPv4
and IPv6 will be supported. Routing security requirements and issues
will also be addressed.

The MANET WG will also develop a scoped forwarding protocol that can
efficiently flood data packets to all participating MANET nodes. The
primary purpose of this mechanism is a simplified best effort multicast
forwarding function. The use of this protocol is intended to be applied
ONLY within MANET routing areas and the WG effort will be limited to
routing layer design issues.

The MANET WG will pay attention to the OSPF-MANET protocol work within
the OSPF WG and IRTF work that is addressing research topics related to
MANET environments.

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.
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
Done  Submit initial ID of RMP for WG review
Mar 05  Submit initial ID of PMP for WG review
Done  Submit inital ID of generalized MANET flooding approach
Jun 05  Revise WG documents and review
Nov 05  Document initial implementation progress and experience Revise documents based upon implementation experience
Feb 06  Submit RMP specification and supporting documentation to IESG for publications as Proposed Standard
Feb 06  Submit PMP specification and supporting documentation to IESG for publications as Proposed Standard
Feb 06  Submit MANET flooding specification to IESG for publication as Experimental Standard
Mar 06  Review and update milestones

Internet-Drafts:

  • draft-ietf-manet-dsr-10.txt
  • draft-ietf-manet-dymo-02.txt
  • draft-ietf-manet-smf-00.txt

    Request For Comments:

    RFCStatusTitle
    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)

    Current Meeting Report

    MANET Minutes
    An overview of the agenda was provided by Ian Chakeres.  WG co-chair Joe Macker was absent from this meeting but was monitoring remotely.
    
    After the opening agenda review and bashing, the WG's progress was reviewed by Ian (see slides). The status of present documents and the charter items was reviewed. Regarding the reactive protocol charter item, DYMO has seen good progress and is on its third revision.
    There has also been significant progress in the proactive routing area based upon work being done and started as OLSR version 2.
    
    An early Simplified Multicast Forwarding (SMF) ID was also posted and is intended to get work and discussion started. The -00 draft is available.
    
    DSR is progressing to EXP RFC status
    
    WG goals were summarized by Ian Chakeres:
    
    There should be more mailing list discussion regarding documents.  We want to collect implementation experience. We want to roll this experience into revised IDs. RFC-Diff helps show changes to the drafts and is also recommended.
    
    Next a DYMO Update and Plans were discussed by Ian Chakeres
    
    Changes from DYMO 01->02
    Changing order of Document, routing before handling generic packets. This version resolved some naming ambiguities.  There are changes to the way seq numbers are incremented. There are also changes to route timeouts and delete timeouts that are more flexible.
    DYMO 03
    Avoids uni-directional links, RREP-ACK.  This revision also defines behavior for seq num 0 comparisons.  12-bit length field, correct way to handle byte order was discussed.
    There was discussion of when a RERR should be issued, when a link is broken or when a packet is for a route the is not there.. how should it propagate?  Creates a small flood, for every topology change.  RERR floods through neighbors with route.
    
    Thomas- no aiming to flood to all nodes?
    
    Ian- correct, only a subset of the nodes, only those with that route.
    
    Better handling of data structures and packet handling, lots of similarities between pro-active and re-active, looking into reuse of a similar format.  Implementation has found a number of tradeoffs of how things are handled. Path accumulation, currently is a SHOULD but might not be good for all types of networks.
    
    There was a discussion of Simple Internet Gateway issues and a multicast address assignment for DYMO.
    
    There are plans to look more into Neighbor connectivity monitoring.  Possibly look into creating a draft or looking at other draftÕs methods.
    
    Charlie Perkins: LowPan is interested in neighbor monitoring.
    Ian Ð There could be some crossover with 6LowPan
    Low energy, small packet size. Changes to DYMO to make it better fit this environment
    
    DYMO Implementations were next discussed.
    
    NIST Dymo Implementation - Klein-Berndt
    Currently available, implements the latest draft.
    Runs in Linux Kernel
    Supports internet gatewaying and subnets
    Available at: https://sourceforge.net/projects/nist-dymo/
    
    
    Dymo Implementation in OPNET - Kuladinithi
    Opnet 11, 01 draft, 50 nodes
    It has been tested against DSR, AODV
    Scenario 1
    9 nodes, two sessions
    AODV expanding ring search, leads to higher initial discovery latency
    Total load BPS link-layer, DSR has higher because of source routing
    Scenario 2
    50 nodes, start time equally distributed
    AODV latency still highest
    DSR route cache last longer than AODV and DYMO allowing it to have less RREQ.
    AODV has highest Routing Traffic, DYMO has higher routing byte because of path accumulation.  Path accumulation, improves performance by reducing RREQ, but only if the route is needed before route expires
    
    Q: Any analysis of scalability?
    Kulad - Not yet
    
    Ian Ð DYMO written with a lot of flexibility allowing for trade offs to be made and we are interested in examining those tradeoffs analytically.
    
    Pedro Ruiz next presented an implementation DYMOUM
    Same code for NS2 and Linux 2.4 and 2.6 supported
    Currently this code is stable but has only been run on static scenarios. Next we want to try on mobile scenarios
    NS2 2.27 and 2.28
    ToDo: currently using link layer feedback, not hellos, looking at adding this.
    Simulation results, running under NS2, 50 nodes, not everything has been verified yetÉ
    AODV, DYMO and DYM-PA
    Path Accumulation reduces the number of RREQ
    CP Ð does the lesser amount of RREQ have to do with intermediate nodes issuing RREP?
    Ruiz Ð It may have to do with thatÉ
    Ian Ð it could also have to do with expanding ring search.
    Ruiz Ð it is possible to enable expanding ring search in our implementation.
    With Path Accumulation there are lot more RERRs because there are more nodes with more routes. When a link breaks, more nodes will propagate because more nodes have that route in the Route Table. One of the trade-offs with PA
    Not a large performance difference from AODV
    \
    CP Ð two factors, 3 sec may not be long enough for route cache timeout. All that effort to then purge. 20m/s is pretty fast, may be good to have an adaptive route timeout.
    
    Thomas Clausen Ð PA option was not present in AODV? PA in DYMO does not give a substantial benefit?
    
    Ruiz- in the simulation you are not getting a benefit, but not enough scenarios, might get more benefit in other scenariosÉ
    
    Ian Ð As CP mentions, this may be useful under certain conditions. It is important to identify these conditions.
    
    TC Ð A different set of scenarios would likely benefit from it? Would some past experience help clarify where it would be beneficial?
    
    CP Ð Yes, there was a paper from UCSB, that showed PA gave a 10% increase or soÉ the way DSR runs Source Route is a PA. It was added to help smooth a convergence between AODV and DSR.
    
    
    Next an OLSR v2 Discussion took place to update efforts in the proactive routing area.
    
    TC: This is largely the work of a design team that has been working on this and I am going to give a quick overview of the general design spirit/goals. We are aiming this to be in the MANET proactive protocol design space as an evolution of OLSR (v1). See slides for details.
    
    Summary: fixing minor nits, improve expandability, we have inherited some algorithms and message handling
    Changes from OLSRv1:
    Uniform treatment of HNA and TC
    Uniform treatment of IPv4 and IPv6
    Internal extensibility of messages
    Reduced complexity
    
    After some significant recent design meetings and editing we have produced a draft document that will be made available. We also generated a rationale document to accompany the specification.
    
    Targeting document submittal 8th of Aug when deadline lifted. Also an end of sept/ early oct, draft incorporating changes. Pre-Vancouver
    
    Next Brian Adamson provided an overview of SMF Plans/Discussion
    (see slides for details)
    
    Duplicate Packet Detection approaches and issues were discussed.
    Seq num approach probably the most robust.  IPSec already has a seq number in packet
    Hash based schemes also possible but false alarm issue and complexity require consideration.
    
    Methods for determining and using efficient relay sets were discussed. An implementation of SMF has been tested in the linux and within ns2.  Comparable performance was observed with both ECDS and MPR flooding, ECDS is a bit easier to implement. Not conclusive though, more analysis is needed with more dynamic scenarios, different MAC layers, one-to-one and one-to-many traffic scenarios.
    
    Jasques: pretty old algorithm, problem with mobility?
    
    Justin Dean Ð robustness with mobility, if you have a MAC layer way of getting information about link status, you can react faster and select better links.  We are looking at different relay set algorithms in terms of both performance and implementation issues.
    
    Brian: Possibly interested in maintaining modularity for customization
    Jasques: we have recently released a report on this that looks at the advertisements, I will post it to the list
    TC: when you want to do relaying, MAC can make a big difference if it can help when you are selecting relays. We should probably not be putting requirements on the MAC layer, and not make assumptions about it.
    Brian: I agree, I am hoping we can make a sufficiently modular that would allow it to take advantage if it is available.
    Chris Delar: you were comparing number of forwards needed to flood a network
    Justin: Yes we were
    Brian: There is no correctness restriction that you have to follow a tree with the ecds, you can forward a packet if you hear a packet early
    Chris Ð number of packet forwards
    Sue Harris Ð On IPv6 header option, Hop-by hop vs destination header
    Brain Ð HavenÕt looked into this enough, with destination, it needs to be kept
    Brain Ð Looking to have option stick to packet for the lifetime of the packet, for sequencing we would like for it to stay in case it leaves network and comes back. Lets packet safely exit and enter and be discarded
    Sue: When you talk about baseline neighborhood discovery, can you describe what you want?
    Brian: The reason it is brief is the each neighbor selection is different for each algorithm.
    Sue: So you are trying to look at commonality of neighbor discussion?
    Brain: Correct.
    
    Some discussion of gateway issues and unresolved tradeoffs.
    
    CP Ð Discussion on not depending on MAC layer, possible to do some very good things at layer 3, with only adding a few extra bits.
    
    SMF Implementation Issues
    
    Nodes not running can still recv multicast packets
    William Ð always had problems with dense mode to sparse.
    Brain Ð deferred to gateway, what should be forwarded from dense.
    Alex Ð have you done any analysis on the amount of data you need to maintain vs, amount of bandwidth. How to calculate the window?
    Brain Ð Somewhat dependant on the MAC layer, which have queues that result in 1 sec delays, total of 10 or 15 sec delaysÉ. Need to looking into dynamically setting. Mostly observation study É
    Alex Ð Would be interesting to look at this, scalability issues with this.
    Justin Ð not store entire seq number, just a window and 1 bit for each seq number, this is why each number needs to be in order.
    Brain could be timeout and depth limited, there are strategies that could be used.
    
    SMURF Discussion
    
    CP ÐID may not just be an IP, ID can show willingness to be leader, can also include degree of connectedness into ID.
    
    Packet format based upon MPRF, can build connect dominating set without using MPRs
    
    2nd OLSR workshop Discussion
    An OLSR workshop and Interop took place in Paris prior to the IETF.
    TC Ð the slides presented during the inter-op will be made public pending the authors agreeing to it.
    
    Autoconf BOF update was provided.
    
    OSPF MANET update was provided.
    
    Open discussion, related work & announcement
    CP Ð It has been brought up a number of times that hop count is not a good metric, should we look at finding a better metric?
    
    TK -  I think this is a good thing and current protocols should allow for using any metric you choose to use. Not sure we can find one metric for all wireless media.
    
    QOS Ð Hakim Badis

    Slides

    WG Progress
    DYMO
    NIST-DYMO Implementation
    DYMO Impl in OPNET
    DYMOUM Impl
    OLSRv2
    SMF Update
    SMF Impl
    SMURF
    Second OLSR Workshop
    MANET AUTOCONF BOF Summary
    OSPF-MANET Update
    QoS in MANET Offsite Discussion