DTN Network Management

Ed BirraneEdward.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

3

Status – NM Informational Report

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.

Draft informational report consolidating multiple engineering/research efforts.

4

Status – NM Draft Protocol Specification

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.

Data monitoring messages specified and prototyped.

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

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

Network Layer is not a “clean” separation

DTN NM Informational Report – Functional Areas

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.

Highest level requirements for a DTN NM Function.

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.

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 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)

12

DTNMP: Push, don’t PullExample: Collect A at high rate, Collect B,C at lower rate.

SNMP (PULL) DTNMP (PUSH)

13

Keep Message Sizes Small

Fully Named ASCII Data

(Good)

Fully Named Binary Data

(Better)

Summary Named

Binary Data(Best)

EXPIRED_BUNDLE_COUNT = 50505 CUSTODY_REJECT_BAD_EID = 10000~ 60 bytes

0x11092A030102017A010150 0x11092A030102017A010140~ 30 bytes 50505 10000

0x11092A030102017A010150~ 19 bytes 50505 10000

14

Allow User-Defined Messages

• 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

Bundle Protocol Data

ExpiredBundleCount

CustodyAcceptCount

BundleFwdFailures

BundleExpiredCount

BundleQueuedCount

CustodyReleaseBytes

LTP Data

Heap Used

Head Free

ION ICI Data

Small Pool Size

Unused Memory

Small Pool Free

Large Pool Size

Large Pool Free

USER DATA

ExpiredBundleCount

LTP Head Used

ICI Small Pool Size

• 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

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

16

DTNMP MIDs (Managed Identifiers)

MID Identifies three types of data1. Data formally defined in global standards2. Data defined within an administrative domain3. 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

Priority (OPT) OIDFlag Byte Issue (OPT) Tag (OPT)

Initial Challenge: How do we name all of this data? Leverage existing OID infrastructure, but try to optimize to reduce size.

DTNMP MID

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.

Bundle Protocol ADM

MID1 = ExpiredBundleCount

Atomic Data

MID2 = CustodyAcceptCount

MID3 = MID1 + MID2

Computed Data

MID4 = AVG(MID3, 10s)

MID5 = MID1, MID2

Reports

MID6 = MID5, MID3, MID4

MID7= ClearBundleCnt()

Controls

MID8 = ClearAcceptCnt()

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.

DTNMP: CONOP and Status

Managed Device

DTNMP Agent

Managing Device

CfgData

Proc DTNMP Mgr

DTNMP Agent

DataSNMP Agent

Cfg

MIB / CIB

Agent QueryProc

Proc

Headers drive firmware.

OIDs

MIB Compilers for SNMP.

Cmd/Cfg/Data Defs

Push Reports

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

Network Management Application

ION BPALocal Data

Adapter

Remote Data Aggregator

Ingest

Autonomy

Cfg

Aggregate Data

Cmd/Cfg Bundles

Report Bundles

Production Rules

Atomic Data

Cmds

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

24

Backup Slides

Review of Informational Report Use Cases

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)

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

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.