$Id$

HSLS/ETX Portability
-------- -----------

For portability across UNIX-like systems, our HSLS / ETX implementation
will abstract the Forwarding Information Base (FIB), the Routing
Information Base (RIB), the packet send/receive interfaces, the
file-descriptor event interface, and wireless interfaces.

Zebra will provide our RIB and FIB abstractions.

Niels Provos' portable event(3) framework will provide a portable
event abstraction for our socket-server library.

For cross-platform portability, we will write our code according
to the ANSI C specification (whichever version is implemented by
GCC 2.95).

HSLS Daemon Capabilities & Extensibility
---- ------ ------------ - -------------

The HSLS daemon must provide an API for a module that assigns link
weights. The API must be callback-oriented so that it is possible
for the daemon to communicate with a link-sensing module "at a
distance" without a blocking, RPC-style interface.

The HSLS daemon must provide an API for a link-sensing module. The
API must be callback-oriented so that it is possible for the daemon
to communicate with a link-sensing module "at a distance" without
a blocking, RPC-style interface.

The HSLS daemon must provide an API for downloading its link-state
graph.

The HSLS daemon need only be capable of routing IPv4 and IPv6.
The HSLS daemon is capable of advertising *both* IPv4 and IPv6
hosts and subnets, simultaneously.

The HSLS daemon supports network-wide renumbering, such as is
necessary when a non-Internet connected network connects to the
Internet for the first time. The daemon is capable of changing any
network node's IP number (including its own) without dropping routes
to that node.  It provides an API for this purpose.

So that the HSLS daemon can effectively redistribute routes to OSPF
& BGP networks through Quagga, it is capable of aggregating
sub-networks and damping "flaps".

The HSLS packet format must be extensible so that it can carry new
HSLS fields and possibly fields for ETX, etc.

The HSLS daemon will be programmed with a best effort made toward
portability. For example, system APIs that may not be portable,
such as for creating certain sockets, will be wrapped by a suitable
portability layer.

Dynamic & static configuration variables (the MIB) must be exposed
with an API that we can operate "at a distance," e.g., a message-passing
API. An SNMP interface is not required, but we do want to support
one in the future.

In general, we will require our implementation to be optimized for
space over time (we may target systems with just 4MB RAM in the
future), but we will document the space/time trade-offs we make.

CUWiN does not require multicast routing, security, or aggregation
(except at the borders) from its HSLS daemon.

Internationalization
--------------------

The Open Society Institute requires that we support non-English
languages. This translates to a requirement for localization and
extended character-set support in the HSLS / ETX daemons.

$Id$