Download presentation
Presentation is loading. Please wait.
Published byEmery Hamilton Modified over 9 years ago
1
© 2005 The MITRE Corporation. All rights reserved UNCLASSIFIED DTN Interface Architecture Jeffrey D. Bush jbush@mitre.org Robert C. Durst durst@mitre.org IETF DTNRG Meeting March 24, 2006
2
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 2 TCP Basic Interface Components Convergence Layers Storage DTN Forwarder Routing Application Interface DOD- Specific Policy/ Routing Protocol Persistent Storage UDPLTP Non- IP Application A Application BApplication C
3
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 3 Basic Interfaces n 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) n 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 Convergence Layers Storage DTN Forwarder Routing Application Interface
4
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 4 Bundle Forwarder Announcement (nominally formatted with XML) n 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 n Specific Interface Parameters for each interface –Control/Data TCP ports TO forwarder –Control/Data TCP ports FROM forwarder –Interfaces: n Routing/policy module(s) n Storage n Convergence Layer Adapters n Applications n Authentication material (Optional)
5
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 5 “Boot Up” Sequence n BF announces via UDP broadcast to loopback network –All of its interfaces (or those permitted by policy to be advertised) n External modules listen for broadcasts, filter on EID, find their interfaces, and initiate a TCP connection
6
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 6 TCP Storage is a bit different – would like everyone to talk to it directly Convergence Layers Storage DTN Forwarder Routing Application Interface DOD- Specific Policy/ Routing Protocol Storage (Persistent/ Ephemeral) UDPLTP Non- IP Application A Application BApplication C
7
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 7 Revised “Boot Up” Sequence n BF announces via UDP broadcast to loopback –Either only its storage interface (or storage and knowledge) or –All of its “open” interfaces n Storage responds with its own server information –Storage may support one BF or many – if many, must segregate and differentiate within the storage itself n 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 n BF adds Storage announcement to its own server information announcements n BF adds Routing, Application, and Convergence Layer Adapter information to the announcement n External modules listen for broadcasts, filter on EID, find their interface, and initiate a TCP connection
8
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 8 Additional Tasks n Formalize meta-data exchange between DTN modules –XDR n Limited availability of XDR compilers n Used in early external router interface –XML n Broad language support n Easier to maintain, troubleshoot n Rules and mechanisms for component authentication –(Optional) External modules must authenticate to the BF before sending actions n 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 n Specification of a bundle forwarder MIB –Additional interface to query/control BF
9
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 9 Netfilter Capability Convergence Layers Storage Routing Application Interface INPUT Bundle Filter Chains Bundle Path Through Forwarder OUTPUT DTN Forwarder Routing Decision FORWARD PREROUTING Logging Facility Bundle Meta-data
10
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 10 Early Routing Module Interface Implementation DTN2 Forwarder Routing Prototype External Routing Module nNew ExternalRouter class – a stateless interface for third-party bundle routing protocol implementations. nAll IPC is between UDP ports on the loopback interface. nBundleEvents 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). nBundle payloads are not sent across this interface, only Bundle meta-information.
11
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 11 nExternalRouter begins broadcasting the UDP ports it plans to use for IPC on the loopback network along with other information (see above graphic). nRouter modules listen for this broadcast on a well known UDP port. nExternalRouter sends “bundle-related” events to the Bundle Events Port and “control-related” events to the Control Events Port. nExternalRouter listens for the asynchronous arrival of bundle actions and dispatches them to the BundleDaemon. Early Routing Module Interface Implementation “Boot Up” Sequence Local EID (variable) Actions PortBundle Events Port Control Events PortVerRes 031 Len
12
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 12 Early Routing Module Interface Implementation DTN2 Modifications n ExternalRouter Class “is-a” BundleRouter n 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) n An additional “internal event” was added to ExternalRouter to handle “route dump” from console n 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
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 13 Other Proposed Enhancements n Additional “link-type” BundleEvents are needed for BF router interface. –All link state changes should trigger events. nWould 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
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 14 DTN Interface Architecture Milestones n April 28, 2006 –Alpha DTN2 router/policy interface implementation n 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 n Convergence Layer Adapters Interface n Applications Interface n Netfilter Capability n Bundle Forwarder MIB
15
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 15 Backup
16
© 2006 The MITRE Corporation. All rights reserved UNCLASSIFIED 16 Why have so many different ports? n 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 n “I’m a router” “I’m a storage module” “I’m an application” n Could happen transparently to the user of the interface n 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… n A 4-port solution requires a centralized “dispatcher” –Makes something dynamic out of something essentially static n 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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.