DTN Network Management

1. DTN Network Management Ed Birrane Edward.Birrane@jhuapl.edu 443-778-7423

2. Topics • Status • DTN NM Informational Report • DTN NM Draft Protocol Specification • Informational Report • Key Points • Document Review • Draft Protocol Specification • Key Points • Document Review • Reference implementation status • Next Steps / Discussion 2

3. Status – NM Informational Report Draft informational report consolidating multiple engineering/research efforts. • Reviewed novel aspects of this capability. • Several publications over past two years related to network management concepts for DTN and for space systems. • E. Birrane, R. Cole, “Network Management of Disruption-Tolerant Networks: A Systems Engineering Approach”, Proceedings of the SpaceOps 2010 Conference, April 2010, Huntsville, Alabama, USA, 2010. AIAA. • Birrane, E, & Cole, R. (2011). Management of Disruption-Tolerant Networks: A Systems Engineering Approach. In C. A. Cruzen, J. M. Gunn, & P. J. Amadieu (Eds.), Space Operations: Exploration, Scientific Utilization, and Technology Development (pp. 501-519). Reston, VA:American Institute of Aeronautics and Astronautics, Inc. • E. Birrane, S. Burleigh, V. Cerf, “Defining Tolerance: Impacts of Delay and Disruption when Managing Challenged Networks,” Proceedings of AIAA Infotech@Aerospace Conference, March 2011, St. Louis, Missouri, USA. AIAA. • E. Birrane, H. Kruse, “Delay-Tolerant Network Management: The Definition and Exchange of Infrastructure Information in High Delay Environments,” Proceedings of AIAA Infotech@Aerospace Conference, March 2011, St. Louis, Missouri, USA. AIAA. • Reviewed heritage architectures at JHU/APL • Review of missions operations applications and procedures for commanding, telemetry retrieval. Some evidence of automatic file retransmission from the MESSENGER mission. • Review of flight software telemetry production models. 3

4. Status – NM Draft Protocol Specification Data monitoring messages specified and prototyped. • System model for the protocol has been drafted and in early review • Data types, primitives, and identifier mappings have been proposed • Methods of data customization have been specified • Roles and responsibilities associated with the protocol have been identified. • Data Monitoring • Key report messages defined in the protocol using above mentioned data types, customization methods, and roles/responsibilities. • Subset of data monitoring primitives identified for BP, LTP, and ION ICI. • Reference implementation of this subset provided in branch of the ION codebase. • Demo of this given at last CCSDS meeting • Draft Protocol Specification • Protocol document exists and is being prepped for review. 4

5. DTN NM Informational Report • Overview of Proposed Key Concepts • Network Layers • Functional Areas • Functional Characteristics • Quick walkthrough of Draft Document • Outline review • Charter discussion • Scope and Schedule • Questions • Priority versus draft protocol specification • informational reports tend to serve as supporting information for a protocol specification. Should we finish the draft protocol spec first?

6. DTN NM Informational Report – Network Layers Network Layer is not a “clean” separation • Various Layers • We focus on the “Network” layer • Above the link layer • Below the application layer • Some blurring with the application layer • Are protocol support services apps? • Routing, Security, NM, Aggregation? • Break Network Layer into 3 Tiers • Tier 1: Protocol Services • Tier 2: Protocol Support Services • Tier 3: Managing Applications

7. DTN NM Informational Report – Functional Areas Highest level requirements for a DTN NM Function. • Configuration • Apply settings across network nodes • Remember multiple states and associated properties. • Provide versioning, authentication, and idempotency as appropriate. • Performance Monitoring • Collect local node information, as configured. • Aggregate information by time and type through the network, as appropriate. • Provide forensic support of reported values (timestamps, sender ids). • Event Reaction • Switch amongst pre-configured operational modes as appropriate. • Produce more/difference data based on mode. • Support fault recovery at the Tier 2/Tier3 network Management Layer.

8. DTN NM Informational Report – Management Features • Standardized Naming Scheme • Identify Data, Control formats • Enable cooperation with terrestrial protocols • “Managed Identifier” (MID) • Consolidated Data Model • Package data, reports, controls to be atomic. • Application Data Model (ADM). • Persistent Storage • Store data for aggregation. • Controls for configuration. • Measurements for reaction. • Evaluation Engines • Process data/controls as necessary.

9. DTN NM Informational Report • Quick walkthrough of Draft Document • Charter discussion • Questions • Priority versus draft protocol specification • informational reports tend to serve as supporting information for a protocol specification. Should we finish the draft protocol spec first? • Review of Operational Use Cases

10. DTN NM Draft Protocol Specification • Overview of Proposed Key Concepts • Desirable Properties • Identifiers, Application Data Modes • CONOPS • Agent Architecture • Quick walkthrough of Draft Document • Outline review • Charter discussion • Scope and Schedule

11. Delay-Tolerant Network Management Protocol (DTNMP) • Desirable Properties • Configured Push rather than Operator Pull • Do not require bi-directional comms for every query. • Small Message Sizes • Avoid high overhead of transmitting ID information for every DATUM • Use binary representations • Specify exactly data desired (no undesired bulk queries) • User-Defined Data • Network managers define custom groupings of data. • SNMP-Compatibility • Identify data such that it can be understood by terrestrial SNMP agents • Initial Challenges • Assigning Identifiers (need to keep them small) • Configuring production (pushing the data) 11

12. DTNMP: Push, don’t Pull Example: Collect A at high rate, Collect B,C at lower rate. SNMP (PULL) DTNMP (PUSH) 12

13. Keep Message Sizes Small Fully Named ASCII Data (Good) ~ 60 bytes EXPIRED_BUNDLE_COUNT = 50505 CUSTODY_REJECT_BAD_EID = 10000 Fully Named Binary Data (Better) ~ 30 bytes 0x11092A030102017A010150 50505 0x11092A030102017A010140 10000 Summary Named Binary Data (Best) ~ 19 bytes 0x11092A030102017A010150 50505 10000 13

14. Allow User-Defined Messages Bundle Protocol Data LTP Data ION ICI Data • Pre-defined sets of data • BP, LTP, ICI • Query individual items • Pre-defined collects per set • All BP Disposition • All LTP Stats • All ICI SDR Stats ExpiredBundleCount Heap Used Small Pool Size CustodyAcceptCount Head Free Unused Memory BundleFwdFailures Small Pool Free BundleExpiredCount Large Pool Size BundleQueuedCount Large Pool Free CustodyReleaseBytes • How to mix/match across MIBs? • ExpiredBundleCount + Head Used + Small Pool Size • Could make 3 queries (3 sets of NAME=VALUE) • This is wasteful from previous slide) • Define new report to represent 3 values • 1 NAME, 3 VALUES • More bandwidth efficient USER DATA ExpiredBundleCount LTP Head Used ICI Small Pool Size 14

15. SNMP Compatibility • SNMP Uses OIDs as IDs • Global, Managed Tree Structure • “Path to data” is concatenation of #s. • ifSpeed = 1.3.6.1.2.1.2.2.1.8 • Supports Binary Encoding (BER) • Compress first 2 #s: 1.3 => 43 • SDNV-encode rest • SNMP Identifier: <type> <length> <value> • Type 6 -> OID • Length (in this case) = 9 bytes • ifSpeed = 0x06092C0601020102020108 • DTNMP Uses MIDS (Managed IDs) • MIDS encapsulate OIDs (less <type> field) • Option to compress OID • Makes easy to interoperate with SNMP 15

16. DTNMP MIDs (Managed Identifiers) Initial Challenge: How do we name all of this data? Leverage existing OID infrastructure, but try to optimize to reduce size. • MID Identifies three types of data • Data formally defined in global standards • Data defined within an administrative domain • Commands (similar to ICMP capabilities) [Not Discussed Here} • MID has multiple fields • Flag Byte: • Type: Data Identifier or Command Identifier • Priority Present ? • Issuer Present ? • Tag Present ? • OID Type: Full OID, Parameterized, or Compressed OID DTNMP MID Flag Byte Priority (OPT) Issue (OPT) OID Tag (OPT) 16

17. MID Fields (1/2) • Priority • Useful when defining computed data items to avoid circular computational dependencies. • When omitted, the highest priority is assumed. (atomic data definitions have omitted priority fields) • Issuer • From the protocol point of view, a binary blob. Otherwise, a managed binary description of an organization, similar to an OID hierarchy. • For example, an identified organization’s OID. • Tag • Organization-specific identifier for the OID. This may be a version number, hash on the OID value, time generated, or any other value. • Some organizations will never use the tag, preferring to always issue unique OIDs. • Other organizations will want to keep an OID the same and use versions to refer to them separately.

18. MID Fields (2/2) • Full OID • The complete OID definition in ASN.1 notation following BER rules. i.e. an SNMP OID. • The initial type field of 0x6 is omitted for brevity in the protocol. • Parameterized OID • An OID root followed by one or more SDNVs identifying parameters. • This allows an associative array lookup for data values • Ex: bundles_from_eid(ipn:1.1) and bundles_from_eid(ipn:1.2) • Single “root” OID in the ADM bundles_from_eid • Defined to take a single parameter coded in SDNV: EID • No need to understand the EIDs in the network prior to building ADM. • Compressed OID • Experimental, may not be included in DTNMP. • OIDs are large, and often share common path. Extract path into dictionary and make first SDNV in the OID an index into that dictionary. • Similar to Bundle Protocol use of dictionary to reduce space used by EIDs.

19. Application Data Models (ADM) Pre-defined data, reports, and controls for applications managed by DTNMP. • Pre-defined, atomic data • Definitions from MIBs • Global, unique OIDs • No tag/issuer fields • All data and reports • Build blocks for user content • Data MIDs can be used in user definitions • Pre-defined controls • Also global, unique OIDs • Opcodes, description, params • Build blocks for macro commands • No ability for user-defined controls outside of these pre-defined functions. Bundle Protocol ADM Atomic Data Reports MID1 = ExpiredBundleCount MID5 = MID1, MID2 MID2 = CustodyAcceptCount MID6 = MID5, MID3, MID4 Computed Data Controls MID3 = MID1 + MID2 MID7= ClearBundleCnt() MID4 = AVG(MID3, 10s) MID8 = ClearAcceptCnt()

20. DTNMP: CONOP and Status Managed Device Managing Device Proc DTNMP Agent DTNMP Mgr DTNMP Agent Cmd/Cfg/Data Defs Agent Query Proc Push Reports SNMP Agent Proc Data Cfg Cfg Data OIDs MIB / CIB Headers drive firmware. MIB Compilers for SNMP. • A Push Model for information • Managed devices accept universal primitive definitions from MIB/CIBs • Managing devices configure unique, temporal combinations • Managed devices push data based on local autonomy

21. NMA Architecture Stand-alone application exploiting Instrumentation API and implementing subset of DTNMP for reporting. ION Instrumentation API ION BPA Network Management Application Cmd/Cfg Bundles Production Rules Ingest Local Data Adapter Autonomy Report Bundles Cfg Cmds Remote Data Aggregator Aggregate Data Atomic Data 21

22. DTN NM Draft Protocol Specification • Quick walkthrough of Draft Document • Charter discussion • Questions

23. Next Steps / Discussion • Next Steps • Draft NM Informational Report out mid-year • Reviews @ next CCSDS • Draft NM Draft Protocol Specification out mid-year • Reviews @ next CCSDS • Updated Demo @ next CCSDS Meeting • Discussion 23

24. Backup Slides Review of Informational Report Use Cases 24

25. Configuration Scenarios • Pushing New Contact Graphs • Synchronizing data across Tier-2 applications • Demonstrates application of policy: who update whose contacts? • Updating ADM and aggregation definitions • New version of telemetry pages, how to build them, or when to send them. • Demonstrates handling versioning issues in the network. • Work prototyped in RMON extensions • Security Key and Group Changes • Add new group, keys in the network • Demonstrate security model, including group-based access (ACL) • Work prototyped in IBE code in ION (@APL) 25

26. Performance Monitoring Scenarios • Tracking bundle status through the network • Cache/batch report-to addresses through the network • Demonstrates reportability of bundles without saturating network links. • SNMPv3 Gateways • Construct “pull” repositories populated by “push” data. • Demonstrates terrestrial NM interface to high-delay/distruption systems. • Prototype work completed by GRC (DTN2) and OU (ION). • Producing verbose telemetry on failure • Rule/Action configurations define verbose tlm pages on fault • Demonstrate ability to get information to operator faster 26

27. Event Reaction Scenarios • Cancelling large file transfer • Multiple bundles form CFDP transfer • Demonstrate control of bundles at all nodes in the network. • Quality of Service Enforcement • Codified policy decisions on bandwidth, rate, or contact • Demonstrates ability to control traffic over links based on rule configurations at intermediate nodes. • Path Failure Reaction • Tier-2 application configuration in reaction to loss of node. • Likely update contact graph • Demonstrate ability to automate certain fault recovery. 27