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