Current Meeting Report
Slides


2.5.3 Mobile Ad-hoc Networks (manet)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://protean.itd.nrl.navy.mil/manet/manet_home.html -- Additional MANET Page
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 04/23/2002

Chair(s):
Joseph Macker <macker@itd.nrl.navy.mil>
Scott Corson <corson@flarion.com>
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: www.ietf.org/mail-archive/working-groups/manet/current/maillist.html
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:
  • - draft-ietf-manet-zone-zrp-02.txt
  • - draft-ietf-manet-aodv-11.txt
  • - draft-ietf-manet-dsr-07.txt
  • - draft-ietf-manet-olsr-06.txt
  • - draft-ietf-manet-tbrpf-05.txt
  • - draft-ietf-manet-lanmar-04.txt
  • - draft-ietf-manet-fsr-03.txt
  • - draft-ietf-manet-zone-brp-02.txt
  • - draft-ietf-manet-zone-ierp-02.txt
  • - draft-ietf-manet-zone-iarp-02.txt
    • Request For Comments:
    RFCStatusTitle
    RFC2501 I Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations

    Current Meeting Report

     IETF 54 MANET Working Group Minutes
    17 July 2002
    Yokohama, Japan


    The meeting as chaired by Scott Corson (Co-chair Joe Macker was absent).


    1) Agenda Bashing
    Agenda stands.


    2) Updates of Current Drafts

    * OLSR Update - draft-ietf-manet-olsr-07.txt, T. Clausen, U. Aalborg

    There were no changes to the core protocol. Two features--"relay willingness"
    and TC redundancy--were added to the base specification.

    Relay willingness: a node may affect the likelihood (via a WILLINGNESS value) of
    it being selected as MPR (change due to Fred Baker, Cisco). A "WILLINGNESS" is a
    value from 0-7 where 0 = "never", 7 = "always", 3 = default.

    TC Redundancy:

    before: only MPR links advertised were advertised

    after: option to advertise full topology (Joe Macker)

    Comment by Richard Ogier - TBRPF did this previously and should "get some
    credit".

    Draft clarifications: Link management modified - separate packet seq. number,
    others small things.

    Summary - draft updates consist of minor clarifications and updates.

    COMMENTS:
    Q: Richard O.: How do you know the performance of OLSR vs. other protocols? I.e.
    given all of the updates since version 3 of the spec "multiple interface change
    since version 3, link hysteresis, etc.". "partial hello" option reporting
    neighbor's loss as well...there have been changes. Richard wants to know if OLSR
    works better, and he can't do that without new code, and he wants new code from
    INRIA to test it.

    A: Thomas suggested that existing released code can be modified as others have,
    yet INRIA is resource constrained. INRIA hesitant to release incomplete code
    sets.


    3) Related Drafts


    * "Global Connectivity for IPv6 Mobile Ad Hoc Network", R. Wakikawa,

    KEIO University

    He proposed "Internet Gateway Discovery" by sending a RREQ for global prefix
    info. The RREQ uses "all internet gateway" destination address (multicast). A
    RREP must have a global prefix flag, and global prefix then comes from field in
    RREP.

    Example given:

    Modifying NDP (neighbor discovery protocol) was discussed with support all
    address scopes instead of only link-local. The question is then "how to setup
    reverse path for replies?" Either L2 forwarding or reverse route setup (like
    AODV). A node uses an arbitrary address for discovery of a site-local address by
    address autoconfig.

    Differences between use of routing header and next hop routing were highlighted.
    Pros of Next hop approach: smaller header size, minimal protocol changes than
    routing header; Cons: intermediate nodes must have a default route. A next hop
    routing example was then given. The example shows where an incorrect route can
    go unknown by the source node. With use of routing header approach, this is
    overcome.

    How are ICMP message handled"
    E.g. "destination unreachable" - a router can delete host route and rediscover
    new route by RREQ -- if MANET uses "default route" it will discover the new
    route

    Route Examination by Internet Gateway: GW has reverse routes of all ad-hoc nodes
    in its MANET.

    Mobile Ipv6 Operation:
    This current draft based on outdated mobile IP draft - needs updating.

    Routing header Pros: detects use of incorrect route, no default route needed.

    Multiple GW support and what happens if 2 MANET's merge? It may become 2 GWs in
    one MANET? No final solution yet.

    Gateway discovery should be optimized. I.e. flooding to GW may be heavy.

    Status: Ns-2 & Glomosim implementations and working on AODV6 Linux & BSD
    implementations.

    COMMENTS:

    Dave Johnson: Although details are different, this has been previously
    implemented in DSR, and the draft here is very AODV specific, e.g. reverse
    routes. Draft advertises itself as supporting "on-demand" protocols, but Dave
    thinks the title should state it is AODV-specific, since it has AODV-specific
    assumptions. Thinks it should be renamed. The term "global connectivity" is
    confusing as well.

    Charlie Perkins: The intention of draft is for a large class of protocols,
    comments to revise the draft to meet this intention would be welcome.

    Dave Johnson: Details required to connect MANETs to an IP infrastructure will be
    different for each protocol, so a general document is unrealistic.

    Charlie Perkins: This draft will eventually cover proactive protocols too.


    * "Fast OLSR", Khaldoun Al Agha, INRIA

    This presentation describes an extension to OLSR for fast mobility (there is not
    yet a I-D, though they are working on it). There is a paper to appear in the
    next NWCN on Fast OLSR.

    The problem is a fast moving router -- 15 km/h -- for 802.11 it is limited to
    perhaps nominally 40 meter average range given OLSR needs 6 seconds to
    "discover" neighbors. Reducing the "hello" interval can help reduce this 6
    second value, but useless overhead if nodes not moving. There is no link layer
    notification so IP-layer neighbor discovery is the only way to detect mobility.

    Key idea of Fast OLSR: mobile nodes operate with 2 modes: 1) default and 2) fast
    moving.

    MPR selection is used to maintain connectivity. How to know to switch modes? If
    links are breaking frequently then switch is the answer that is realized by a
    heuristic policy.

    A comparison was made to GSM/GPRS which has overhead of 950 b/s
    (114 bit SACCH every 120ms).

    INRIA performed simulation with no overlapping coverage, so no soft handover can
    be done (make before break), so no buffering when there is no link. Packet loss
    is reduced with short "fast hello" interval.

    Table of summary of overhead.

    Future work: OPNET simulation can go up to 100,000 nodes and can connect OLSR
    and Fast OLST to Mobile IP to make a network comparable to GSM, etc.

    COMMENTS:
    Richard O.: Is this an extension or addition to OLSR? TBRPF already support fast
    hellos with "differential hellos" that allow hellos to go as fast you like
    without increasing overhead. Can this fast OLSR simulation code be released?

    Anonymous: speed of vehicle isn't pertinent, but rate of topology changes is...


    4) Related Activities:


    * AODVng Workshop Results, C. Perkins, Nokia

    Workshop in June 2002: 20-25 attendees.
    Issues addressed: what's hard to implement, determined performance improvements
    needed, avoidance of duplication of effort, etc.

    Noted issue with 802.11: Bad hello messages: 802.11 broadcasts hellos at lower
    data rate (more reliability) than control messages which are unicast.

    Some security topics covered were uncovered, which stressed the need that RREPLY
    must come from destination for security.

    Diffserv QoS approach provides "no free lunch", and trading off lower delay or
    higher bandwidth is required


    * Broadcast in AODV/OLSR, C. Perkins, Nokia

    Using MPR flooding for broadcast in AODV MANET networks. Premature work at this
    point. The work considers "manet-local" flooding vs. TTL = 1, e.g. no subnet
    broadcast in MANET.

    Issues:

    MPR dependence on last hop?

    ICMP vs. UDP vs IP? (how encapsulation occurs).
    Redundant coverage? To help reliability of coverage. What's the answer here?

    All these should be investigated.

    Richard O.: Which way is better? TBRPF will probably respond more quickly to
    link failures. Would like to contribute to this work.

    Charlie: comments that he wants draft to be free of intellectual property.

    Phil Karn: Security and Denial of Service concerns for allowing flooding. Rate
    limiting -- is this the answer?

    Dave J.: Performance tradeoff questions? Routing vs. flooding? Is the overhead
    of periodic advertisements for flooding less than (or perform as well) as what
    the MANET protocol would need to do to provide equivalent service?

    Charlie: Results on dominating sets look good. Performance tradeoff will be
    different for different specific protocols. We need to measure this for
    different protocols with different traffic scenarios and movement patterns. A
    key is to be able to this for a portion of the network.

    Dave J.: AODV works better with link layer feedback but MAODV needs periodic
    hellos.

    Charlie: If you get the info without advertisements.

    Dave: How does this compare to recent MobiHoc paper comparing flooding?
    Flooding seems it should be an "IP mechanism", not UDP vs. ICMP

    Richard O.: There is not an IPR issue with TBRPF. TBRPF will be freely usable.

    Charlie: Wants a "warm fuzzy" for readers of the spec. that they can use it
    freely (with no possible IPR concerns).

    Richard O.: Charlie's IPR concern is nebulous.

    Dave J.: What about AODV IPR given DSDV patent issue?

    Charlie: No answer has been forthcoming from anyone.

    Dave J.: I'm not a lawyer.


    * Securing Ad Hoc Routing Protocols, Yih-Chun Ju, Rice University

    SEAD - Secure Efficient Ad hoc Distance Vector., based on DSDV,
    Uses efficient symmetric cryptography. Because it's easy to create bogus
    signatures and hard to determine if there are bogus, leading to easy denial of
    service attack. This requires neighbor authentication.

    SEAD is robust against non-collaborating attackers.
    (note that collaborators can tunnel authenticator across network).

    ARIADNE - based on DSR. Security based on TESLA.

    Question for working group: Is this in scope of the MANET working group?

    Phil Karn: votes Yes!


    5) Open Discussion

    Scott Corson: Working group long overdue for charter update.

    Can anyone suggest working group topics?

    Dave Johnson: Multicast.

    Charlie Perkins: Flooding, Attaching to other networks, Security, Multicast.


    The mtg concluded (with 30 minutes remaining free!!!)


    Scribe: Brian Adamson

    Editor: Scott Corson

    Slides

    None received.