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. - Prototype implementation in C by Aalborg University - INRIA has a C implementation _and_ a Perl-5 implementation. 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.