DTN Network Management
Ed Birrane
Edward.Birrane@jhuapl.edu
443-778-7423
Topics

Status



Informational Report



Key Points
Document Review
Draft Protocol Specification




DTN NM Informational Report
DTN NM Draft Protocol Specification
Key Points
Document Review
Reference implementation status
Next Steps / Discussion
2
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


3
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.
Status – NM Draft Protocol Specification
Data monitoring messages specified and prototyped.

System model for the protocol has been drafted and in early review




Data Monitoring




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.
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

4
Protocol document exists and is being prepped for review.
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?
DTN NM Informational Report – Network
Layers
Network Layer is not a “clean” separation

Various Layers
We focus on the “Network” layer




Some blurring with the application layer
Are protocol support services apps?



Above the link layer
Below the application layer
Routing, Security, NM, Aggregation?
Break Network Layer into 3 Tiers



Tier 1: Protocol Services
Tier 2: Protocol Support Services
Tier 3: Managing Applications
DTN NM Informational Report – Functional
Areas
Highest level requirements for a DTN NM Function.

Configuration




Performance Monitoring




Apply settings across network nodes
Remember multiple states and associated properties.
Provide versioning, authentication, and idempotency as appropriate.
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.
Initial Challenge: How do we name all of this data?
infrastructure, but try to optimize to re
DTN NM Informational Report –
Management Features !MID Identifies three types of data

Standardized Naming Scheme








!
!
!
!
!
Package data, reports, controls to
be atomic.
Application Data Model (ADM).
Persistent Storage

Store data for aggregation.
Controls for configuration.
Measurements for reaction.
27
Evaluation Engines

Data formally defined in global standards
Data defined within an administrative domain
Commands (similar to ICMP capabilities) [Not Di
!MID has multiple fields
Identify Data, Control formats
Enable cooperation with terrestrial
Flag Byte
Priority (OPT)
protocols
“Managed Identifier” (MID)
!Flag Byte:
Consolidated Data Model


1.
2.
3.
Process data/controls as necessary.
Issue (OPT)
OID
Tag (OPT)
DT
Type: Data Identifier or Command Identifier
Priority Present ?
Issuer Present ?
Tag Present ?
OID Type: Full OID, Parameterized, or Compres
DTN NM Informational Report

Quick walkthrough of Draft Document

Charter discussion

Questions
1. 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?
2. Review of Operational Use Cases
DTN NM Draft Protocol Specification

Overview of Proposed Key Concepts





Quick walkthrough of Draft Document


Desirable Properties
Identifiers, Application Data Modes
CONOPS
Agent Architecture
Outline review
Charter discussion

Scope and Schedule
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)
DTNMP: Push, don’t Pull
Example: Collect A at high rate, Collect B,C at lower rate.
SNMP (PULL)
12
DTNMP (PUSH)
Keep Message Sizes Small
Fully Named
ASCII Data
(Good)
~ 60 bytes
EXPIRED_BUNDLE_COUNT = 50505
Fully Named
Binary Data
(Better)
~ 30 bytes
0x11092A030102017A010150
50505
0x11092A030102017A010140
~ 19 bytes
0x11092A030102017A010150
50505
10000
Summary
Named
Binary Data
(Best)
CUSTODY_REJECT_BAD_EID = 10000
10000
Allow User-Defined Messages
Bundle Protocol
Data
LTP Data
ION ICI Data
ExpiredBundleCount
Heap Used
Small Pool Size
CustodyAcceptCount
Head Free
Unused Memory
BundleFwdFailures
Small Pool Free
BundleExpiredCount
Large Pool Size
BundleQueuedCount
Large Pool Free
CustodyReleaseBytes
USER DATA
ExpiredBundleCount
LTP Head Used
ICI Small Pool Size
• 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
• 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
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
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
1.
2.
3.
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
Priority (OPT)
Issue (OPT)
OID
Tag (OPT)
DTNMP MID
 Flag Byte:





Type: Data Identifier or Command Identifier
Priority Present ?
Issuer Present ?
Tag Present ?
OID Type: Full OID, Parameterized, or Compressed OID
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.
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.
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()
DTNMP: CONOP and Status
Managed Device
Proc
Proc
Proc
Agent
Query
Managing Device
DTNMP
Agent
Cmd/Cfg/Data Defs
DTNMP
Mgr
DTNMP
Agent
Push Reports
Data
Cfg
Cfg
Data
OIDs
Headers drive firmware.
MIB /
CIB
SNMP
Agent
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
NMA Architecture
Stand-alone application exploiting Instrumentation API and implementing
subset of DTNMP for reporting.
ION Instrumentation
API
Network Management Application
Cmd/Cfg
Bundles
Production Rules
Ingest
Local Data
Adapter
Autonomy
Cfg
Atomic Data
21
ION
BPA
Cmds
Remote Data
Aggregator
Aggregate
Data
Report
Bundles
DTN NM Draft Protocol Specification

Quick walkthrough of Draft Document

Charter discussion

Questions
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
Backup Slides
Review of Informational Report
Use Cases
24
Configuration Scenarios

Pushing New Contact Graphs

Synchronizing data across Tier-2 applications


Updating ADM and aggregation definitions


Demonstrates application of policy: who update whose contacts?
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

25
Add new group, keys in the network

Demonstrate security model, including group-based access (ACL)

Work prototyped in IBE code in ION (@APL)
Performance Monitoring Scenarios

Tracking bundle status through the network

Cache/batch report-to addresses through the network


SNMPv3 Gateways

Construct “pull” repositories populated by “push” data.



Demonstrates reportability of bundles without saturating network links.
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

26
Demonstrate ability to get information to operator faster
Event Reaction Scenarios

Cancelling large file transfer

Multiple bundles form CFDP transfer


Quality of Service Enforcement

Codified policy decisions on bandwidth, rate, or contact


Demonstrate control of bundles at all nodes in the network.
Demonstrates ability to control traffic over links based on rule
configurations at intermediate nodes.
Path Failure Reaction

27
Tier-2 application configuration in reaction to loss of node.

Likely update contact graph

Demonstrate ability to automate certain fault recovery.