1. DTN Network Management
Ed Birrane

2. Topics Status Informational Report Draft Protocol Specification
DTN NM Informational Report
DTN NM Draft Protocol Specification
Informational Report
Key Points
Document Review
Draft Protocol Specification
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, 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 ). 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 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 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. Example: Collect A at high rate, Collect B,C at lower rate.
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
0x11092A A010150
50505
0x11092A A010140
10000
Summary
Named
Binary Data
(Best)
~ 19 bytes
0x11092A A010150
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 DTNMP Uses MIDS (Managed IDs)
Global, Managed Tree Structure
“Path to data” is concatenation of #s.
ifSpeed =
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 = 0x06092C
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
Flag Byte
Priority (OPT)
Issue (OPT)
OID
Tag (OPT)
DTNMP MID 16

17. MID Fields (1/2) Priority Issuer Tag
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 Parameterized OID Compressed 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
Cfg
Report Bundles
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
Draft NM Informational Report out mid-year
next CCSDS
Draft NM Draft Protocol Specification out mid-year
Updated next CCSDS Meeting
Discussion 23

24. Review of Informational Report
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 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