This enables AAP 2.0 clients to receive status reports with a new ADU
flag (as we already deliver BIBE bundles). Moreover, it allows clients
to set a report-to EID and sets all of the status report flags on newly
created bundles in case a report-to EID is provided.
Closes: #241
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The FIB fulfils two purposes: 1) map node IDs to next-hop CLA addresses
and 2) store the current status of a link associated with a given CLA
address.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We should be able to honor the fragmentation threshold again. This
passes the maximum bundle size variable to the AAPv2 agent. The value is
determined as the minimum of all maximum bundle sizes reported by the
CLAs and the one specified on the command line, with the special case
of the value 0, which means a maximum bundle size of 2^64 ("unlimited").
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
With the addition of the storage agent and the compat. BDM we have the
issue that two new agents accept configuration through bundles, which
cannot check that those bundles come from trustworthy sources. In the
past we restricted contact configuration messages to local clients and
performed an "EID spoofing detection" so that we could check the source
EID - if it is the same as the local node ID, we allowed the
configuration bundle to be processed. With AAPv2 and potentially more
security-relevant components (such as BDMs) appearing in the future, we
need a new mechanism.
The idea behind the implemented mechanism is to reuse the existing AAP
2.0 shared-secret authentication that is applied for BDMs themselves
also for sending configuration messages: We add the possibility to
register an AAP 2.0 RPC agent (one that sends commands *toward* uD3TN)
with the "dispatch" authorization flag. This client can then request a
special flag to be added when sending bundles. The new flag is only
added internally by uD3TN to its in-memory data structure and is
delivered to all internal agents as well as AAP 2.0 clients receiving
the marked bundles. Those agents and clients (such as the sqlite/storage
agent) can then easily check for the flag to be present and thus
determine whether the bundle comes from an authenticated and authorized
source.
Note: The `adu_flags` field for the BundleADU AAP 2.0 message is now a
`repeated` field to represent the option of multiple flags being present
(Protobuf does not support bit fields for this purpose).
Fixes: #187
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
When transmission had been attempted and generated a "TX
success/failure" result, the BDM will need the information which
transmission is affected by the generated dispatch. Additionally, the
term "DispatchRequest" is imprecise, as uD3TN does not require the BDM
to dispatch the bundle in any case (it can do so, but especially after
TX success/failure, oftentimes, it is intended to just proceed with
normal bundle processing).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a "flags" field to the FIB link, allowing for configuring a
link for "direct dispatch", i.e., to make it usable without first
contacting a BDM. It is important to make this optional as otherwise
contact-based routing and QoS could not be implemented properly via a
BDM.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds functionality to dispatch bundles and control the FIB to AAP
2.0 and the bundle processor, replacing the old "router" completely.
AAP 2.0 is extended slightly to enable fragmentation.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the data structures necessary for controlling the set of CLA
links and dispatching bundles from AAP 2.0 Clients.
See also the new documentation in doc/aap20.md.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- Introduces a CompoundBundleId to filter exactly one bundle
- Filter bundles either by their ID or selected metadata
- Transfer the entire StorageCall object to the CLA via the agent queue
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
The SQLiteAgent enables SQLiteCLA to read packages from the database and
return them to μD3TN. For this purpose, the SQLiteAgent writes commands
to the queue that SQLiteCLA is waiting for.
The SQLiteAgent itself can be controlled by protobuf messages that
describe which action is to be applied to which set of bundles.
Currently the operations "Push" and "Delete" are implemented and a
filter based on a destination EID pattern.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
There might be incompatible changes in those messages before their
public release. As we only support basic send/receive functionality over
AAPv2, we do not need to include the definitions of other messages.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
If there is already an agent registered for the other direction of
communication, registration will fail as long as the provided secrets do
not match.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a DispatchRequest message containing a DispatchReason in
extension to the bundle headers. By that we can pass more information to
the BDM about why the dispatch request was triggered and have it
extensible in the future.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This is a "meta-agent" based on the current AAPv1 implementation
(`application_agent.c`), which runs the new AAP2 protocol that is
implemented via Protobuf (using NanoPB). Please refer to the
corresponding design documents for further information on the protocol
itself.
Beside the on-wire encoding and future extension capabilities, the primary
difference from AAPv1 to AAP2 is that a connection is now a
unidirectional RPC-like channel. This ensures that acknowledgments
cannot be easily get out of order and makes client implementations
simpler. However, it also means that now a shared secret needs to be
passed by clients to enable registering for the same agent ID.
The following limitations of this first implementation are present:
- Only sending and receiving ADUs is supported.
- The shared secret is not checked - any app can register for the same
agent ID as long as no other app has yet registered for the requested
direction (subscribe or non-subscribe).
- Only one client per direction is supported at the moment. (It is at
least planned to support multiplke subscribers for an agent ID.)
- The server does not expect acknowledgments from clients when they
receive ADUs.
- The keepalive mechanism is not implemented.
In general, this reflects the feature set of AAPv1, but with massive
extension opportunities.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We do not need the `components/` subdirectory and it makes the call to
the Protobuf compiler more complicated.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the Nanopb library as submodule under `external/` and adds
corresponding build configuration to the Makefiles. Additionally, a
Protobuf stub for AAP 2.0 is included along with a `make` target to
build the corresponding C language files (`aap2-proto-headers`).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
