DTN Interface Architecture

1. DTN Interface Architecture Jeffrey D. Bush jbush@mitre.org Robert C. Durst durst@mitre.org IETF DTNRG Meeting March 24, 2006

2. Basic Interface Components Application B Application C Application A Application Interface Storage DTNForwarder Routing DOD-SpecificPolicy/ RoutingProtocol PersistentStorage Convergence Layers TCP UDP LTP Non-IP

3. Application Interface Storage DTNForwarder Routing Convergence Layers Basic Interfaces • Commonality among Interfaces • Forwarder periodically announces its presence and how each element should attach to it • Elements rendezvous with forwarder using communication information provided in announcement • All interfaces have control and data ports in each direction (but not all have to be used by every element) • Interface Mechanics • All defined in a single class that each forwarder-side interface inherits and overrides • Forwarder listens on all TCP ports mentioned in announcement

4. Bundle Forwarder Announcement (nominally formatted with XML) • Bundle Forwarder’s Singleton EID • Permits more than one forwarder on a machine – components can be configured to associate with any forwarder or a specific one, based on Singleton EID • Specific Interface Parameters for each interface • Control/Data TCP ports TO forwarder • Control/Data TCP ports FROM forwarder • Interfaces: • Routing/policy module(s) • Storage • Convergence Layer Adapters • Applications • Authentication material (Optional)

5. “Boot Up” Sequence • BF announces via UDP broadcast to loopback network • All of its interfaces (or those permitted by policy to be advertised) • External modules listen for broadcasts, filter on EID, find their interfaces, and initiate a TCP connection

6. Storage is a bit different – would like everyone to talk to it directly Application B Application C Application A Application Interface Storage DTNForwarder Routing DOD-SpecificPolicy/ RoutingProtocol Storage (Persistent/Ephemeral) Convergence Layers TCP UDP LTP Non-IP

7. Revised “Boot Up” Sequence • BF announces via UDP broadcast to loopback • Either only its storage interface (or storage and knowledge) or • All of its “open” interfaces • Storage responds with its own server information • Storage may support one BF or many – if many, must segregate and differentiate within the storage itself • Must announce back to BF that it has existing records for the BF’s EID and some descriptive info (# of records, time of first/last record) • Choice of internal or external storage could be part of a configuration file • BF adds Storage announcement to its own server information announcements • BF adds Routing, Application, and Convergence Layer Adapter information to the announcement • External modules listen for broadcasts, filter on EID, find their interface, and initiate a TCP connection

8. Additional Tasks • Formalize meta-data exchange between DTN modules • XDR • Limited availability of XDR compilers • Used in early external router interface • XML • Broad language support • Easier to maintain, troubleshoot • Rules and mechanisms for component authentication • (Optional) External modules must authenticate to the BF before sending actions • Add Netfilter and TUN/TAP style interfaces to the BF • Define router/policy module actions to maintain BF rules • Example rule targets: ACCEPT, DROP, LOG, REDIRECT • Specification of a bundle forwarder MIB • Additional interface to query/control BF

9. OUTPUT INPUT PREROUTING FORWARD Netfilter Capability Application Interface Storage Routing Routing Decision DTNForwarder Convergence Layers Bundle Filter Chains Bundle Meta-data Logging Facility Bundle Path Through Forwarder

10. Early Routing Module Interface Implementation DTN2Forwarder Routing Prototype External Routing Module • New ExternalRouter class – a stateless interface for third-party bundle routing protocol implementations. • All IPC is between UDP ports on the loopback interface. • BundleEvents delivered to ExternalRouter are packed into UDP datagrams (with XDR). BundleEvents are characterized as either "Control Events" or "Bundle Events". No queueing of events is implemented at this time (i.e. fifo operation). • Bundle payloads are not sent across this interface, only Bundle meta-information.

11. Early Routing Module Interface Implementation “Boot Up” Sequence Ver Len Res Control Events Port Bundle Events Port Actions Port Local EID (variable) 0 31 • ExternalRouter begins broadcasting the UDP ports it plans to use for IPC on the loopback network along with other information (see above graphic). • Router modules listen for this broadcast on a well known UDP port. • ExternalRouter sends “bundle-related” events to the Bundle Events Port and “control-related” events to the Control Events Port. • ExternalRouter listens for the asynchronous arrival of bundle actions and dispatches them to the BundleDaemon.

12. Early Routing Module Interface Implementation DTN2 Modifications • ExternalRouter Class “is-a” BundleRouter • BundleEvent Class modified to include virtual method pack_event() • Each concrete BundleEvent Class knows best how to package itself for shipping to another process • Additional copyto() methods were added to foundational classes to further assist with event packing (e.g. Bundle::copyto(), Link::copyto(), etc.) • New servlib/routing/dtn_rt_types.x (and other resulting files) • An additional “internal event” was added to ExternalRouter to handle “route dump” from console • New dtn.conf settings • Indicate we want to use an external router • Identify UDP ports to use for broadcasts, control events, bundle events • Listener port to advertise for actions • Broadcast interval

13. Other Proposed Enhancements • Additional “link-type” BundleEvents are needed for BF router interface. • All link state changes should trigger events. • Would like two BF event queues: Control Events, Bundle Events • BF interfaces should be able to send all available Control Events before any Bundle Events

14. DTN Interface Architecture Milestones • April 28, 2006 • Alpha DTN2 router/policy interface implementation • May 12, 2006 • Internet Draft (version 00) submitted to IETF specifying bundle forwarding interface to routing/policy module • Further enhancements, bug fixes to DTN2 router/policy interface implementation • Begin work on DTN2 storage interface implementation • Convergence Layer Adapters Interface • Applications Interface • Netfilter Capability • Bundle Forwarder MIB

15. Backup

16. Why have so many different ports? • Couldn’t I just have 4 ports? How about just 1? • Control and data, irrespective of interface type • Or just a single port • An external entity could “personalize” on connection • “I’m a router” “I’m a storage module” “I’m an application” • Could happen transparently to the user of the interface • In the single port case, could say, e.g., “This is CONTROL IN” • A logger, for instance, could say that it was everything • You COULD do it this way, but… • A 4-port solution requires a centralized “dispatcher” • Makes something dynamic out of something essentially static • Having each interface listen on its own ports seems easier • Avoids a “handoff” from a centralized listener-manager to the individual interface • First level “grouping” already accomplished