Last Modified: 2004-07-09
In the past, this WG has focused on exploring a broad range of MANET problems, performance issues, and related candidate protocols. Under this revised charter, the WG will operate under a reduced scope by targeting the promotion of a number of core routing protocol specifications to EXPERIMENTAL RFC status (i.e., AODV, DSR, OLSR and TBRPF). Some maturity of understanding and implementation exists with each of these protocols, yet more operational experimentation experience is seen as desirable. Overall, these protocols provide a basic set of MANET capabilities covering both reactive and proactive design spaces.
With this experimental protocol base established, the WG will move on to design and develop MANET common group engineered routing specification(s) and introduce these to the Internet Standards track. Lessons learned from existing proposals will provide useful design input, but the target for this effort is a common group engineering effort not a recompilation of an existing approaches.
As part of this effort, the WG will address the aspects of security and congestion control in the designed routing protocol(s).
This working group will work closely with the Internet Research Task Force (IRTF) groups on Mobile Ad Hoc Networks (RRG) for tracking and considering any mature developments from the related research community.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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) |
|
MANET WG Minutes
60th IETF Aug 2, 2004, San Diego, CA 0900-1130 Scribe: Ian Chakeres WG Agenda Agenda Bashing and Status 5 min Macker Review and Discussion of WG Next Stage 30 min Macker - WG Draft Charter - Standards Track Efforts - MANET Reactive Routing Protocol (MRRP) - MANET Proactive Routing Protocol (MPRP) - Generic Flooding Work (e.g., MPR-F) - Other Areas/Possible Informationals - OSPF-MANET Design Team Effort (being worked within OSPF WG) AODVbis Plans/Discussion 15 min Perkins draft-perkins-manet-aodvbis-01.txt Mobile Gateway Discussion 15 min Singh Mobile multi-gateway support for IPv6 mobile ad hoc network draft-singh-manet-mmg-00.txt Link Sensing and Buffering 15 min Mase (-00 ID forthcoming) DSR Update (ID under IESG review) 15 min Johnson ----------------------------------- Other Discussions (e.g., autoconf,etc) 10 min Post-IETF OLSR Workshop Overview 10 min Implementation or Related Work Announcements 15 min Next Steps : Open Floor 15 min IETF60 MANET Minutes: Scribe Ian Chakeres Joe Macker - Agenda bashing and intro - see attached agenda Joe Macker - Charter Update - see attached slides Joe Macker provided a short overview of previous WG efforts leading to present milestones of achieving a number of EXP RFC specifications. The Chair then reminded the WG that a draft charter update and problem statement had been posted and reviewed on the list in May. There was perceived positive feedback on the core items and there was also perceived consensus on moving forward. The contents of the draft charter update were updated in a set of slides (see presentation). It was reiterated that the next goal of the WG is a set of consensus-based designs intended for STD track submission. Other relevant items may include appropriate Informational or BCP documents to document particular MANET issues and multiple known in-use solutions. The broad purpose of the WG is to standardize IP routing protocols appropriate for wireless use that can be used in both static and mobile node scenarios or in combined hybrid applications. The fundamental design issues involve developing protocols that handle wireless link characteristics and the ability to adapt to increased temporal topological dynamics (this may be due to mobility or other factors). The WG focus will be on solutions that support extending IP routing areas at the edges of an infrastructure. The support for hybrid and meshed infrastructures is also important and this may include combinations of static meshed, mobile, and wired/wireless interfaces. The support for connected non-routing hosts to be directly supported by a manet routing node is also a goal. Charlie Perkins - By non-routing hosts do you mean nodes not running a routing protocol or just not routing for others? Joe Macker - Likely both. Planned core Standards Track efforts at present involve the development of two routing protocols one reactive and one proactive. MRRP - reactive MPRP - proactive In the longer term, there may be a design progression toward reactive/proactive combined design but the semantics are significantly different that the WG will proceed with a dual track initially. Another potential core work item is the development of a Generic MANET Flooding algorithm. This is envisioned as a simplified forwarding service that routes data to all MANET nodes efficiently. The design goal is not a transport layer mechanism but rather a pure best effort routing layer mechanism. The approach MAY be applied to simplified multicast forwarding within scoped and limited MANET areas. Finally, Joe gave an update on the latest OSPF-MANET efforts that are ongoing. In summary, an initial design team has been formed and is meeting at this IETF. For those who might wonder, this is not intended to be replace MANET proactive protocl developments, but the OSPF design will likely borrow suitable MANET-developed mechanisms. The OSPF design is likely limited to OSPFv3 and it may also be targeting more backbone environments that are less mobile. The ADs and WG chairs have decided to work this effort within OSPF with cooperative review from the MANET side. An OSPF and MANET WG chair serve on the design team. Those interested should track the OSPF list for specific related threads. Charlie - When will the charter be done? Joe - It is ready for Alex, so it shouldn't be too long. Alex Zinin - Most discussion will finish this week, then the formal process begins. Hopefully by the DC meeting the new charter will be approved. Question - Will the principal authors of the exp. RFCs be active in the new protocols? Joe - Most likely, but participation is not limited to those people. We will try to gauge various interests and commitment before making further decisions. Bora - Security is unique for MANET, I think this should be specifically addressed? ??? - I think its time to start looking at operations and management in MANET. Alex - If we don't have the requirements for ops and management, people still address them. Joe - This is part of the goal of possible BCP documents. Comment - Its time to include these aspects in the new protocols. Alex - If things aren't obvious, they should be spelled out. Comment - Discovery, routing area, is there something general that we could take away to use? Joe - Neighbor discovery is so fundamental. Potentially this would be a great building block. We should try to better document our issues and findings. Charlie - Charter feedback. I think is basically a good charter update. Can we check for consensus? Joe - Please hum if you DO NOT agree with the proposed charter modifications. No hums were heard. Question - OSPF-MANET, will this info be presented in MANET? Joe - No. it will occur in the OSPF group. Question - shouldn't there be more interactions between MANET and OSPF-MANET? Joe - There is some interaction between WGs represented by those on the design team already. If you want to participate, please do. Qusetion - Is there a mechanism to share the OSPF-MANET happenings with the MANET group? Alex - It isn't reasonable to have the same people share the same info in both groups. Attend if you're interested Comment - Many groups present the same drafts in multiple groups. (Ramblings about the value or misvalue of that) -------------------------------------------- Charlie Perkins - AODVbis Update - contact author for slides A set of revised ID changes were outlined. Some simulation results were discussed that issuing RERR immediately upon break detection can increase performance, when using hello messages. Introduced a new term "available" paths. These paths are subject to verification before use. Some discussion of more advanced simulation testbed with ns-2 enhancements. SNS-2 (Cornell) 1,000 and 10,000 node runs. Mosix parallel operation (Johns Hopkins). Future revisions were then covered. Other features, simplifications and improvements were presented. -Unicast route validation -"available" routes - changed ACTIVE ROUTE TIMEOUT to ROUTE TIMEOUT - efforts to harmonize link-state and distance vector - specify use of MPRF as broadcast mechanism David Johnson - Why do we need "available routes" why not just cache the route and attempt to send data. Then wait for a RERR if the route is bad? Charlie - We'll look at this. ------------------------------------------------- Singh - Samsung - mobile multi-gateway for IPv6 - contact author for slides Q: Should this become a working group document? More discussion is needed. There has also been other past work done. Suggest multi-authors with diverse experience possibly present a common issues draft. Thomas Clausen - INRIA - agreement on MANET support there. Please check with previous attempts and come up with a more complete proposal. David - Lockheed Martin - Is there anything similar between this and NEMO WG? Singh - Some. Ryuji - Is this proposal IPv4 or only IPv6 specific. Singh This proposal is IPv6 only. Ryuji - What is MANET specific issue addressed by this draft? Maybe helpful to look at IPv6. Singh - MANET discovery or IPv6 control packets. ------------------------------------------- Mase - Link Buffering in MANET - contact author for slides The goal of the discussed approach is to provide a common mechanism for MANET to employ when local link disconnection is disconnected at the MAC layer. Break in slides at "Data Packet Forwarding" Question - What is the difference between "route invalid" and "no route"? Thomas - The packet restoration handling part differs. Comment - The displayed state machine ignores this. Thomas - I'll send you copies of the draft. Alex - Fundamental question. How many IP datagrams are you going to have to buffer? few, x pps, etc? Mase - Please see the simulation results. Alex - If there is flopping, it just doesn't scale to buffer packets. What is the scenario you are addressing? Mase - Expecting less than 1 second delay. Alex - Do you expect the routing to converge faster than this? It will take more than 1 second to reconfigure. Alex was skeptical of buffering IP datagrams during re convergence. WG Comment - At extremely high data rate, no buffering can help. This is only realistic for slow link speeds and few packets. Thomas - Alex, "you don't believe that buffering in the IP during convergence"? This is opposite to reactive. The same problem exists in AODV or DSR. You will buffer any way. This isn't outside that. Perhaps buffering during control plane convergence is good or bad. Joe - I'm nervous about potentially significant buffering of IP packets at the network layer, especially hop-by-hop. Its been tried before and we'’ve seen systems that are overly complex. I'm not sure its needed for proactive. I'm also worried about TCP. We might create a second order problem here which the analysis has not looked at. The congestion case is also a problem. Generic use might be dangerous. There is an idea of making delay insensitive protocols work better. Need more motivation and example of use. Even for reactive we don't NEED to buffer excessively. You can improve and also harm using buffering. Mase - Buffering is quite useful. Alex - There is difference between buffering after topology change as a general technique and buffering at the source as in the special case, holding packets during route discovery is ok. Generally heavy buffering does not scale. Alex is worried about transport protocol effects. Perhaps we should take this offline. This only works if you can gain improvement from a small number of packets buffered. In the grand scheme it might not give you much improvement. Charlie - For certain apps you can gain significant improvements. Don't totally block out the idea of buffering. Alex - In present production networks this just won't work. Back to the slides - Data Packet Forwarding Joe - Can I get more specifics about this diagram. Is this per hop buffering or source buffering? Mase - This happens at every node. Chair comments on simulations showing excessive speeds that may not be a typical case example. Charlie - We should be able to handle freeway speeds. Alex - Let’s try to close this discussion and move on. Interoperability issues. Applicability. ---------------------------------------------- Dave Johnson - DSR draft update - contact author for slides There is a new version of the DSR ID with minor changes. -Changed option codes -Specified how dsr uses ARP, DSR may update arp cache to avoid arp -Integrated multiple interfaces into other sections -Removed unidirectional link optimizations -how IP fragmentation works -IANA considerations - DSR Options header + DSR Flow state header -More cleanup Dave next talked about some perceived particular problems with how ARP operates. Claimed these are not DSR specific problems and recommended a possible ARP over MANET ID. Charlie - Are you talking about a new draft for DSR? David - No, this is not in the DSR draft. It should go in another document. Alex - How many packets do you want to buffer to do ARP right? David - You aren't required to do any, though buffering showed an improvement in our tests. Alex - I'm very worried about this proposal, buffering. David - Do you object to ARP retransmits? Alex - The specification shouldn't buffer. A MAY would be ok. David - MAY retransmit ok. Alex - OK. Question - Why do you need this buffering? David - Reliability and time scale that conditions change. Such as congestion or less reliable communication. Also medium sharing issues and topology changes. Comment - ARP RFC, it may already say retransmitting a packets is allowed. David - The BSD implementation buffered only 1. Many other implementations only buffer 1. Comment - MANET is too dynamic. You shouldn't buffer at intermediate nodes. Comment - From the ARP RFC, you may buffer a few packets. Joe - Agenda - Other discussions open time Thomas - OSLR Interop & Workshop Announcement - Friday and Saturday this week. Joe - Will you publish the results? Thomas - Yes, we will provide info to the MANET list. Related information, implementations, announcements etc. ------------------------------------------ David - DSR-derived implementation now available from Microsoft source and binary available. The implementation is not DSR compliant. We also now have a new implemention of DSR and AODV. Taking source from NS unmodified and turning it into running implementations. FreeBSD and linux versions are available. All the protocol code is identical across OS and NS. Not available yet. Demo at MobiCom. Joe - http://pf.itd.nrl.navy.mil/ lots of stuff available. OLSR implementation (with additional research options) + lots of other implementation and test tools for MANET. Lots of field trials, emulations, and simulations have been performed. Joe - OPNET has several MANET protocols implemented. Source should be released soon. More MANET support seems likely. Some autoconfiguration scripts and info being added relating to dhcp relay use,etc. WG Comment - We have OLSR working in sensor networks. Wenji Wu - University of Arizona - OSPF + MANET + wired networks OPNET models. Unik OLSR - real tests were done - OLSR at Berlin conference. Hybrid mesh network infrastructure using MANET. Basically they use nat on a second interface to form a backbone. Interesting demo supported non-MANET roaming nodes throughout extended infrastructure. Some information at freeair.org. ----------------------------------- MANET Address Autoconf - contact author for slides Speaker - Should autoconf be a MANET WG item? Joe - Not yet. There probably shouldn't be one "standard" way to do this. IMHO not all solutions are good for all scenarios. The requirements are not always there for a great deal of complexity. An example is trying to do an IPv6-like DAD in wireless network. There are a lot of approaches that are just not mature and are scenario specific. I suggest, as at the last meeting, we gather a more diverse group of MANET people to discuss and document. Or have a consensus-based informational RFC to iron out the key issues. Joe - last item - open discussion. Q You mentioned possible interim meetings? Joe - Charter is laid out. Specifics need to be discussed. I'd like to talk with people who are very receptive in participating in the re/pro-active designs to go forward. At that point we'll create a more specific plan. First I need to determine the people and commitments. Then we can see if a design team is appropriate. Due to the time frame, I'd like to quickly start moving to a draft stage at an early date. Everyone agrees on the basic charter update, but we still need to get a better handle on a few specifics. Please contact me and let me know what you can contribute. Contact me and I will be willing to setup side meetings this week. |