This blog summarizes the efforts going in the IETF DTN working group to specify a DTN Management architecture. This work is primarily driven by the Applied Physics Laboratory of Johns Hopkins University in conjunction with NASA and the JPL.
Delay and Disruption Tolerant Networking (DTN) was created to enable the Interplanetary (Solar System) Internet: A network that efficiently forwards application data, in the form of bundles, through its nodes located in planets, satellites, and other bodies, connecting an origin and a destination at interplanetary distances. The network will be capable of dealing with the long delays and frequent disruptions experienced in deep space, as well as the asymmetrical bandwidth typical of many space links.
Under these conditions, how is it possible to manage these networks, with nodes that are so far away, with signal round trip times that expand from seconds to minutes to hours?
The Applied Physics Laboratory of John Hopkins University together with NASA and JPL have been working on the definition of a DTN Management Architecture. The architecture, known as DTNMA is being discussed for adoption as an RFC at the IETF.
The DTNMA aims to provide network management services that can operate in a challenged network environment, such as ones envisioned by the DTN architecture. Under this scenario, DTNMA provides a framework for asynchronous and autonomous communication between the device being managed and the manager.
There are two key properties for DTNMA: Asynchronous communications and Autonomy.
Asynchronous communication between the device being managed and the manager is necessary, with knowledge that commands and queries may be delivered much later than the initial request. Because of link asymmetry (for example unidirectional links), there may never be a reply. Because of this, pull mechanisms must be avoided in favor of push mechanisms.
Autonomy is required for the management of a DTN. The constraints imposed by delay and disruption requires that managed devices detect and respond to events without intervention from an in-the-loop managing device, since the managing device might not be reachable within operational time frames.
Similar to other network management architectures, the DTNMA draws a logical distinction between a managed device and a managing device. Managed devices use a DTNMA Agent (DA) to manage resident applications, and managing devices use a DTNMA Manager (DM). A device may support either or both of these logical characteristics.
Figure. DTNMA Reference Model, from the IETF Draft specification
The DTNMA Agent (DA) resides on a managed device, and it is responsible for the monitoring and control of the applications local to that device. In DTNMA, the DA accomplishes this task without a regular connection to a DTN Manager (DM). Its major functions are Monitoring and Control (through its rules database, the autonomy engine and the application control interfaces), Data fusion which generates new data elements as a function of the current state of the managed device and its applications, and Administration which includes manager mapping (many-to-many relationships allowed), access control and data validation.
The DTNMA Manager (DM) resides on a managing device, providing an interface between various managing applications and services, and the DA that enforces their policies. The DM performs three major functions on a managing device: Policy encoding which translates policy directives coming from the managing applications into standardized policy expressions recognizable by DAs, Reporting collection, analysis, and its distribution to managing applications and Administration, including agent mappings, access control and data validation.
There are key aspects that are specific to the DTNMA reference model, such as the use of Pre-shared Definitions whenever possible to avoid/save time in negotiations, Agent Self-Management (autonomy) as a managed device may spend the majority of its time without a connection to a managing device, and Command-based Management where the managed device databases are managed both remotely and locally (by the local autonomy engine).
DTNMA Autonomy Model, from the IETF Draft specification
The DTNMA architecture looks at supporting several use cases, including:
- Serialized and Cascading management, in which a manager can manage multiple agents, while a node can simultaneously be an agent to a “higher-hierarchy” manager and a manager to another agent.
- Management under intermittent connectivity with Open loop reporting, in which agents can report, for example, periodically (without explicit periodic commands) and queue reports during periods of disruption.
- Multi-administrative domains, in which managed applications over the same Agent can be managed by different Managers. The agent, in any case, enforces access control.
What's next? The work to further specify DTNMA will continue in the IETF, further detailing use cases, integration with non-DTN management frameworks, among other areas. From an implementation perspective, we will soon see the first interoperable applications, followed by experiments in space prior to the envisioned operational infusion in the ISS, other commercial stations and LunaNet.
