#
# $XORP: xorp/contrib/olsr/TODO,v 1.2 2008/05/09 16:09:38 bms Exp $
#

TODO
~~~~

* Separate regression tests are needed to deal with the "MPR computation
  disabled" and "WILL_ALWAYS" scenarios, as these blow a lot of the
  assumptions in the current tests out of the water.

* Teach XrlIO about socket IDs. Currently it relies on if_name and vif_name
  being set to sane values by the FEA, which is not guaranteed.

* Teach XrlPort about link-scope multicast sockets. Production deployments
  of OLSR are potentially using 255.255.255.255 instead of a 224.0.0.0/24
  MANET prefix. There are platform issues with undirected broadcasts; some
  implementations of the BSD socket API, which are strictly conformant to it,
  may not support IP broadcasts correctly.

* Rewrite the code in XrlIO which tracks service startup to be more
  coherent; in particular we should track service dependencies in
  a more structured way, rather than relying on a simple integer count.

* Fix issue whereby FEA will not pass if_name/vif_name correctly for
  interfaces added on-the-fly to the interfaces { } router manager
  configuration (this is a showstopper for hot swappable network interfaces).

* Fix policy route filtering. Basic redistribution of everything OLSR
  learns into RIP is known to work, but finer tuning of policy redist
  needs wider exposure and testing.

* ETX metric support.
* Add jitter to message transmission.
* Add support for segmenting, enqueuing and transmitting
  packets according to interface MTU.

  * Currently 1500 (Ethernet) is assumed in regression tests.
    Packets sent will be truncated to 1..N messages which will fit
    in an OLSR datagram which fits inside the interface's MTU, as
    discovered from the IfMgr tree.

* Bring profiling back when it's needed.

* IPv6 support (requires templatization).

 * Figure out what to do about the situation with link-local IPv4 and IPv6
   where more than one interface may in fact have the same numeric address-
   even though the addresses are link scoped. This screws up the concept
   of an OLSR "main address" as a separate unique node ID is then needed.

* Introduce jitter into outgoing messages/packets.

 * Fully document class Message and class Packet in doxygen.

* Add a means of configuring the OLSR admin distance dynamically.

* Add support for writing the database(s) out in tools/print_databases
  in Tlv format.

* Whilst the RIB does not support equal cost paths:
   Tie break multiple routes before they get pushed to the RIB.
   Prefer the nearest routes ie the ones learned using the most
   cohesive topology mechanisms.


MOVE TO GENERAL XORP TODO
~~~~~~~~~~~~~~~~~~~~~~~~~

* Fix valgrind memcheck hits in libxorp TaskList and TimerList.

* Fix valgrind hit in Neighborhood::Neighborhood():
  it is believed that the unschedule_node() call is potentially
  causing a minor leak. The only reason this call is there is to stop
  the MPR recount task being triggered prematurely.

* The runtime buffers allocated by BufferedAsyncReader are relatively
  high (256KB). Look to reduce the memory footprint for embedded systems.

FUTURE
~~~~~~

* Add a means of allowing external entities to register interest in
  OLSR protocol events using XRLs. With this you can build dynamic
  topology visualization tools.

* Implement fisheye in TC.

* Add sugar to source to enable OLSR to be compiled without regression
  testing support in production/embedded builds.

* Add individual commands to:
  * clear links
  * clear neighbours
  * clear topology entries

* Consider moving MPR selection to its own class.
 * Support multiple MPR selection algorithms.

* Teach code to find unused link and neighbor IDs, and to cleanly
  recycle old ones, if we see cycling.

  * Note: The IDs which recycle most rapidly are the Topology Control
    entry IDs, however, they aren't likely to wrap unless you have a
    *very* dynamically varying topology.

* Randomize packet and message sequence numbers on startup.

* Add support for Secured OLSR messages,
  as documented in "Secure Extension to the OLSR Protocol",
  Hafslund et al, 2004.
  * Support MD5 and SHA-1 hashes using system's openssl library.
  * This changes the encoding slightly; handlers are needed for
    message types 11/12/13 for its per-hop challenge response.
  * Signatures are per hop only and per-packet -- see how OSPF's MD5 auth
    works - the hash is over adjusted packet header fields which is tricky
    for us, because it means the entire packet EXCEPT for the sig has to
    be copied out before hashing.
  * The signature is appended as the last message (type 10) in a Packet;
    as such, the size of the sig has to be taken into account in the packet
    if signing is active.

* Support more than one protocol address per physical interface.
