When a forwarder is configured for external routing, it periodically multicasts hello messages to announce its presence to external routers. Each hello message includes the EID of the sender and the interval in seconds between each message. For example, the message

<dtn eid="dtn://nodeX" hello_interval="30"/>

notifies external routers that the DTN forwarder with EID dtn://nodeX is running and will send another hello message in 30 seconds. Router implementations may filter incoming messages by EID if it becomes necessary to run more than one forwarder on a single platform.

After routers receive one or more hello messages from any (or a specific) DTN node, they must synchronize their state with the forwarder. Several routing interface messages are designed to facilitate state synchronization and have a common format. If x represents meta-information of interest, the message x_query prompts the forwarder to send an x_report message. For example, a bundle_query message asks the forwarder to generate and send a bundle_report message.

Routers may query the forwarder for four types of meta-information. contact_report includes meta-information on all open connections between the local forwarder and remote forwarders. Low-level convergence layer meta-information is also included for each contact. link_report contains meta information on all forwarder links regardless of the current state. route_report is composed of meta-information on all static routes configured on the DTN console (if any). bundle_report lists meta-information on each bundle stored by the local forwarder.

After synchronizing their state with a forwarder, external routers process incoming events as they arrive and send requests when necessary.

DTN links represent a one way communication channel to next hop DTN nodes. Links are either explicitly created in the forwarder configuration file (dtn.conf) or spring into existence as a result of the neighbor discovery mechanism. Four types of links exist: always on, on demand, scheduled, and opportunistic. link_created_event messages announce the existence of new links and include such attributes as name, type, and destination EID along with other meta-information. link_deleted_event notifies external routers that a named link has been destroyed. link_available_event and link_unavailable_event messages are automatically generated by the forwarder when links are open or closed respectively.

The forwarder attempts to keep always on and opportunistic links open always. Scheduled links are automatically opened and closed according to configured start and duration settings. On demand links, however, must be explicitly opened by the router using an open_link_request. After on demand links are idle for a set period of time (currently 30 seconds), they are closed by the forwarder.

When the state of any link is either open or busy, a contact element is also available which tracks connection and convergence layer statistics that may be useful to routing algorithms. contact_up_event and contact_down_event messages notify routers when contacts are available or unavailable.

Most link and contact messages carry a coarse "reason" attribute to explain what prompted each link state change.

The primary function of DTN external routers is to maintain a forwarding information base of optimal next hop DTN nodes for remote EID prefixes. Routes to remote EID prefixes are either statically configured, learned from the DTN neighbor discovery mechanism, or learned from peer router communications. Specific DTN routing algorithms and implementations are beyond the scope of this document.

Static routes may be configured in the forwarder configuration file or directly on the DTN console. When static routes are specified, a route_add_event is multicast to external routers. Router implementations may choose to add static routes to internal routing tables (possibly with an identifying marker indicating the source or administrative distance) or simply ignore their existence. The route_delete_event message is issued when a static route has been deleted at the DTN console.

The external router interface does not include messages to support the display of external routing tables on the DTN console. All but the most simplistic external routers should have their own "console" for configuration and routing table displays.

Bundles arriving at a forwarder, either from a remote DTN node or from a local application, are announced with a bundle_received_event message. Bundle payload is not forwarded over the interface, only meta-information.

When an opportunity exists to forward a bundle, the external router issues a send_bundle_request which includes the local bundle id, name of the outgoing link, and the desired forwarding behavior. Meta-information about the bundle should not be erased until a positive acknowledgement is received from the forwarder.

bundle_transmitted_event states that a bundle has been successfully transmitted using the identified contact. On reliable links, this means acknowledgements were received, on unreliable links, a best effort attempt was made to send the bundle. A failed transmission is indicated by the bundle_transmit_failed_event message and may warrant a retransmission by the router if possible.

For successfully transmitted bundles, routers can release all resources dedicated to tracking the bundle unless the sender had requested custody transfer. If custody was requested, the router must continue to track the bundle until it receives a corresponding custody message. If custody was accepted by a downstream DTN node, a custody_signal_event is generated. Bundle meta-information can now be released by the router. If custody failed, indicated by the succeeded attribute in the custody_signal_event, or the router receives a custody_timeout_event (i.e. no response from a downstream DTN node), the router may attempt to retransmit the bundle if possible.

bundle_expired_event notifies the router that a bundle has expired and is being deleted from the store. External routers should remove all records of the bundle.

cancel_bundle_request asks the forwarder to abort a previous send_bundle request if possible. (As of this writing, cancel_bundle_request is not implemented in the DTN2 RI.)

Many routing algorithms require information exchange between peer routers. Communication between peer DTN external routers boils down to identifying methods for sending and receiving router message bundles. Two methods are currently available; the first utilizes the DTN2 application interface and the second is offered by the external router interface itself.

External router developers may elect to build their external routers with two personalities, to behave as an external router and as a DTN application. The external router interface handles all bundle forwarding tasks while the application interface is used to send and receive peer router messages. In order for this method to work, external routers must register with the forwarder as a DTN application and supply a well-known service tag for bundle deliveries. It seems intuitive that the service tag would signify the routing algorithm. For example, an external router implementing a flooding algorithm may register with the forwarder using the service tag "flood_rtr".

This approach offers several benefits: the DTN application interface is reliable, there is no limit on bundle size, and router-originated bundles follow the same path as "normal" application bundles and are subject to the same policies. Cons include increased development complexity and the fact that external routers can't specify an outgoing link using the application API. The forwarder defers to the external router the decision of where to forward router-originated bundles.

The second alternative is to send locally generated bundle payloads to the forwarder on inject_bundle_request messages. Destination EID, outgoing link, and other attributes required for bundle forwarding are supplied as well as the payload to inject. Router-originated bundle payloads are assumed to be binary blobs and are Base64 encoded. No attempt is made to decode or process router-originated bundle payloads except by the destination remote router process. Forwarders notify external routers of successful or failed transmissions in the same manner as "normal" bundles (I need to check this...). Unlike DTN application bundles, router injected bundles are not cached. If transmission fails, bundles are dropped.

At boot-up, the external router interface registers with the forwarder to receive all bundles destined to “ext.rtr/*”. As in the previous example, a service tag is chosen by the external router developer to uniquely identify the router. Arriving bundles matching the registration "ext_rtr/*" are announced with the bundle_delivery_event message. Upon receipt of this message, routers must examine the bundle's destination EID to determine the intended recipient of the bundle. Bundle payloads are read in or otherwise accessed using the filename attribute associated with bundle payload meta-information.

Since IPC between forwarders and external routers is connectionless, one process can fail without the other's immediate knowledge. Consider the case where there is one forwarder process and one external router process. Five states are possible 1) both process are up, 2) forwarder is up, external router is down, 3) forwarder is down, external router is up, 4) forwarder crashes and comes back up within a hello interval, and 5) both processes are down. Obviously, Case 1 does not belong in a Failure Recovery Section.

A discussion of Case 2 yields an interesting point. The forwarder does not monitor whether zero, one, or more external routers are running and/or are members of the all-routers multicast group. Event messages are multicast to the all-routers group, by the forwarder, regardless of external router state. When an external router is restarted, it should immediately synchronize its state with the forwarder in much the same manner as the initial bootup sequence discussed in the previous section.

There are two instances in the life of a forwarder where the hello message includes an additional attribute. The "alert" attribute provides additional information about the overall state of the forwarder and facilitates failure recovery in the remaining cases. Two values are currently valid: "justBooted" and "shuttingDown". At bootup, the forwarder always sends the "justBooted" alert with the first hello message. When the forwarder is shut down in an orderly fashion (by issuing "quit" at the console for example), a hello message is immediately sent that includes the "shuttingDown" alert. However, if the forwarder should crash or is otherwise shutdown in an unorderly manner, there is no guarantee that a "shuttingDown" alert will be sent.

For Case 3, the external router determines the forwarder is down either by receiving a hello message with a "shuttingDown" alert or after hello interval seconds have passed without receiving a message. At this point, the router must stop sending messages, wait until another hello message is received, synchronize its state with the forwarder, and resume normal operations.

The external router knows it is dealing with Case 4 if it receives a "justBooted" alert in less than or equal to one hello interval. The router must stop sending messages, synchronize its state with the forwarder, and resume normal operations.

Towards the goal of making DTN a turnkey solution, additional "helper" processes are being developed whose sole purpose is to watch and restart forwarders and external routers if and when they fail. Helper processes will play a critical role in addressing Cases 2 - 5.