Minutes of the Adelaide MANET WG Meeting Reported by Roger Kermode edited by Scott Corson and Joe Macker. ZRP Marc Pearlman (Cornell) gave an update to ZRP. The overall ZRP architecture was revised. It is based on the notion that when a route is needed, its uses flood searching to determine route. This is improved by aiming requests towards the border of a zone that is defined to be no greater than a limited number of hops away. The bordercasting method was upgraded from unicast to multicast, and now includes bordercast trees, extended routing zones and revised query control. Several concerns with this approach were addressed: (1) relaying querys to peripheral nodes may be more efficient but overlapping routing zones lead to redundancy (this can be resolved by query control mechanisms that identify and discard redundant queries) (2) it is more efficient than flooding but multiple copies traverse the same virtual link more than once. A proposed solution is to use multicast to reduce duplicates, but this requires the construction of a bordercast tree. Options to do this require appending a bordercast tree to link state message of surrounding RHO j hops (routing zone), and having each node constructs all the bordercast trees for which it is forwarding. This requires link state of surrounding (RHO -1) + (RHO) = 2RHO -1 hops (extended routing zones). The new architecture requires exposure of BRP at every node. Simulation models will be made available in OpNET and ns-2 in about 4-5 weeks. The IARP and BRP are as described in draft. Different versions of IERP will be offered: AODV, DSR, TORA. (Q): Do you have any results on stability? (A): some. (DJ): Which version of ns extensions do you presently use (VINT-provided) or CMU's? (A) MP: CMU's not the present VINT snapshot. (DJ): Good, the VINT one at present doesn't quite match what we've done. AODV Charlie Perkins (Nokia) gave an update on AODV. It was recently discovered by folks at UPenn that AODV has a problem with forgetting sequence numbers. This problem allowed routing loops to form when a node reboots and loses state. The solution adopted was the same as that provided by the UPenn contingent. A DELETE_PERIOD was introduced during which time AODV will not respond to route requests. Also AODV keeps track of sequence numbers of broken routes. A similar fixed is needed for multicast. After reboot, a node loses all of its multicast tree information. The suggested fix is to broadcast a MACT with 'R' bit set so that upstream neighbors delete the node from any relevant lists of next hops. Scott Corson (SC) suggested these were probabilistic fixes to the protocol to reduce (although not eliminate) the probability of bad behavior. CP seemed to agree, and had no answer as to what would occur if, for example, the MACT message with 'R' bit set were lost in transmission as reliable delivery is not guaranteed in the protocol. An AODV option for IP Address Autoconfiguration was suggested that borrows from work underway within the ZeroConf WG. It is based on the reasoning that we can't use ARP, so we will use a route request instead to query for address usage. If no one replies, then assume that you can use an address. This still suffers from the merged partitions problem as does the ZeroConf approach. Other details in the update concerned assigned type numbers for extensions, a modified appendix, fixes to typos, and corrected handling of sequence numbers in RERR message. An IPv6 version of messages should be ready by the next IETF. Charlie Perkins (CP) asked the audience: Should RREQ/RREP contain source routes? If so, how long should route information persist? We don't know how long to keep this information? He also said they are re-thinking service discovery extensions. A discussion followed regarding potential convergence of AODV and DSR. CP said that adding source route information to AODV isn't copying DSR. DJ replied that removing source routes from DSR via recent modifications to DSR isn't copying AODV, making the point that we are not converging. DSR can be viewed as a loosely-consistent link state algorithm. It was mentioned that JJ et al. at UCSC had developed STAR, another on-demand link state algorithm. CP suggested that we can use a continuum of methods with varying state requirements. CP also said that people didn't like the original service discovery extensions because it violated the separation of layers. However, Bluetooth is asking that we take this approach. So is this a good way or not? Joe Macker (JM) then replied that as far as multi-hop service location goes, there's an evolving spectrum of ways to accomplish this goal, e.g. anycast support at the routing layer. CP says that this is dangerous and JM replied that we have a paper on general methods that are simple and seem to work reasonable well as an alternative design choice. (DJ) What do you want source routes in AODV for? (CP) This allows us to make our routing tables to look like DV in structure. (DJ) Is this discussed in the draft? (CP) no. (DJ) Is there more information on how the DELETE_PERIOD is calculated. (CP) If we have to rely on HELO msgs then one has to wait for n+1 HELOs to be lost. (DJ) Then it's based on how long it takes to do link breakage detection? (CP) yes. (DJ) Do rebooted nodes start at seq_num = 0? (CP) yes. (DJ) Does seq_num = zero override previous seq_num? (CP) Yes, you want to make sure that you get rid of all the bad routes before you start updating the remaining ones. DJ then suggested that nodes on the other side of the partition won't see seq_num = 0. OLSR Amir Qayyum (INRIA) gave an update of OLSR. A summary of the changes from version 00 to 01 of the draft include: neighbor sensing mechanism added, multipoint relay forwarding added, content and generation of Topology Control (TC) packet modified and power conservation mode added for one-time or intermittent sleep periods which negotiates with MPRs which ones will buffer packets for sleeping nodes. Work underway on OLSR includes an implementation by HIPERCOM at the MAC level. The MAC Level implementation for INRIA Rocquencourt is working over 802.11 with 20 nodes using Linux 2.2.12, FreeBSD 3.3 and Win NT/98. Tunneling is used to access nodes of the same network via cable. A gateway was implemented for access to Internet. An IP level implementation is underway at Aalborg University, Denmark for 802.11. also, the PRIMA project is concerned with long range and slow speed networks. It is using network cards by SATEL modified by COMATIS. and is implementing OLSR at IP level on Linux, and is doing simulations in Opnet and NS. Also, the COMPAS project is studying multicast, QoS, efficient bandwidth utilization and is adding multicast to OLSR. Q: Will Aalborg and PRIMA be independent implementations? A: yes. Q: Will they be public releases? A: don't know yet. Edge Mobility Architecture (EMA) A. O'Neill (BT) gave a presentation on an Edge Mobility Architecture. The draft for this presentation is in the Internet Drafts directory as an independent submission. His presentation gave a GPRS tutorial, and talked of UMTS convergence: must allow for 3G, Bluetooth, etc. to co-exist. He then described the EMA Handover Architecture that, at the IP level, makes use of messages that are abstractions of those carried in cellular networks today. Also, the EMA uses temporary tunnels to reduce or eliminate packet loss during handover. Within the EMA, Inter-Domain mobility is handled via interdomain handover. A mobile node (MN) crosses administrative boundaries and mobility is handled by Mobile IP and/or SIP. Current research is exploring whether MANET algorithms can be used to help with mobility management and routing in cellular networks. In particular, to be used for the injection of host-specific routes into an IP domain. (Q): Will the routing poison mechanisms work for host-specific routes? (A): I don't know yet, I'm asking the WG. (Q): Why doesn't mobile IP work to solve your requirements? (A): it uses tunnels and we don't want to use them in a fully-converged fixed/mobile routing domain if we can avoid them. Mobile Enhanced Routing (EMA-TORA) Scott Corson (UMD) then presented work on Fixed/Mobile-Converged Routing that is related to the EMA presentation. The work concerns extensions to the MANET algorithm TORA, for use as a fixed network routing algorithm in large-scale domains with hierarchical mesh topologies, and for permitting localized injection of host-specific route information. It makes use of EMA mechanisms for handover including temporary tunnels to suppress undesirable routing behavior. A comment from the audience was that soft hand-off is used in 3G. AO'N replied that in the EMA, hand-off happens quickly without duplicast, and that, looking forward, the costs of supporting soft handover may not be compatible with the desire to support a full-IP infrastructure. AO'N was asked what EMA is used for? He suggested that EMA intends to address micro-mobility, and that Mobile/SIP appear better suited for macro-mobility, but was not ruling out the usage of Mobile IP near-term for handover support. Open Discussion The discussion then moved back to MANET WG items. JM suggested that we need to move to the next stage of MANET. Some document cores were looking pretty mature, but now we're now seeing some feature creep in certain areas. We should talk about locking some things down and generating some RFCs. Eric Guttman (EG) suggested that OSPF has separate documents, and we could use this model for handling multicast and other protocol extensions. CP then added that we're dropping service discovery from AODV, but what about interoperability requirements? JM said this is fairly loose at present. We need something that can at the very minimum act as a stub network. We need applicability statements to better describe what the protocols are designed to do (and not to do). This is similar to the concept of applicability statements being applied in other working groups (e.g., the RMT WG).