Internet DRAFT - draft-ivancic-dtnrg-network-management-reqs
draft-ivancic-dtnrg-network-management-reqs
DTNRG Working Group W. Ivancic
Internet-Draft NASA GRC
Intended status: Informational June 5, 2009
Expires: December 7, 2009
Delay/Disruption Tolerant Networking - Network Management Requirements
draft-ivancic-dtnrg-network-management-reqs-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document contains four main sections. The first section provide
some a short introduction of what Delay (or Disruption or
Disconnected) Networking is. The second section describes various
Ivancic Expires December 7, 2009 [Page 1]
Internet-Draft DTN Network Management Requirements June 2009
DTN operational environments. The third section provides
requirements and desired properties for managing Delay and Disruption
Tolerant Networks. The fourth section describes characteristics that
can be found in DTN systems and suggests items that should be
considered for monitoring and/or configuration.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DTN Senarios . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Deep Space Mars Relay . . . . . . . . . . . . . . . . . . 4
2.2. Simple Sensor Networks . . . . . . . . . . . . . . . . . . 8
2.3. Data Mule . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Rapid Disruption . . . . . . . . . . . . . . . . . . . . . 9
2.5. Low Earth Orbiting Sensor Satellite . . . . . . . . . . . 10
2.6. Geostationary Bent Pipe Relay Satellite . . . . . . . . . 12
2.7. Unmanned Aeronuatical Vehicles . . . . . . . . . . . . . . 13
3. General Requirements . . . . . . . . . . . . . . . . . . . . . 14
3.1. Local Network Management . . . . . . . . . . . . . . . . . 16
3.2. Remote Network Management . . . . . . . . . . . . . . . . 16
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. System Characteristics . . . . . . . . . . . . . . . . . . . . 18
4.1. Bundle Processing . . . . . . . . . . . . . . . . . . . . 18
4.2. Convergence Layers . . . . . . . . . . . . . . . . . . . . 18
4.3. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Radios . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Processing Power . . . . . . . . . . . . . . . . . . . . . 22
4.6. Onboard Storage . . . . . . . . . . . . . . . . . . . . . 22
4.7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8. Name Resolution . . . . . . . . . . . . . . . . . . . . . 22
4.9. Local and Network Time . . . . . . . . . . . . . . . . . . 23
4.10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Network Management Utilities . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. Informative References . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Ivancic Expires December 7, 2009 [Page 2]
Internet-Draft DTN Network Management Requirements June 2009
1. Introduction
The initial Delay/Disruption Tolerant Networking has it origins in
research performed by NASA's Jet Propulsion Laboritory to establish
an Interplanetary Internet. Delay/Disruption Tolerant Networking
(DTN) has been defined as an end-to-end store-and-forward
architecture capable of providing communications in highly-stressed
network environments considered unusual from the perspective of the
terrestrial Internet. To provide the store-and-forward service, a
"bundle" protocol sits at the application layer of some number of
constituent internets, forming a store-and-forward overlay network
[RFC4838], [RFC5050]. Key capabilities of the Bundle Protocol
include:
o Custody transfer the ability for a bundle node to take full
responsibility for a bundle reaching its final destination.
o Ability for implementations to cope with intermittent connectivity
if required.
o Ability for implementations to cope with long propagation delays
if required.
o Ability to take advantage of scheduled, predicted, and
opportunistic connectivity (in addition to continuous
connectivity).
o Late binding of overlay network endpoint identifiers to internet
addresses
DTN technologies are well-suited to applications that are mostly
asynchronous and insensitive to large variations in delivery
conditions. DTN networks differ sufficiently from traditional
terrestrial networks in their characteristics and connectivityi.
Network and transport protocols must be carefully considered and
chosen to cope with these different characteristics. New transport
protocols may be designed that are suited for the problems that these
DTN network conditions impose.
In a low-propagation-delay environment, such as may occur in near-
planetary or terrestrial environments, bundle agents can utilize
chatty underlying Internet transport protocols, such as TCP, that
negotiate connectivity and handshake connections in real-time.
In high-propagation-delay environments such as deep space, DTNRG
bundle agents must use other methods, such as some form of
scheduling, to set up connectivity between the two bundle agents.
Ivancic Expires December 7, 2009 [Page 3]
Internet-Draft DTN Network Management Requirements June 2009
DTN runs the Bundle Protocol over subnet-specific transport
protocols, called convergence layers. Each of these convergence
layers may have widely varying characteristics which must be
considered.
It is important to note that DTN does not presume any particular
underlying network. As such, DTN can be used to effectively perform
a bridge between network types (i.e IP to Bluetooth or IP networks to
Consultative Committee for Space Data Systems (CCSDS) data-link
connected space systems.)
2. DTN Senarios
To gain a better understanding of Delay/Disruption Tolerent Networks
the following section decribes various scenarios. These concepts of
operations (CONOPS) will provide a framework from which network
monitoring requirments are derived.
2.1. Deep Space Mars Relay
The following is an example of the Mars Exploration Rover
Communications Operations taken from appendix A of a NASA In-Space
Routing Study [AC1L179]. This example also provides some insight
into current deep space communications operations.
Mars Exploration Rovers use two primary means of communication:
Direct-to/from-Earth (DTE/DFE) communications via X-band radio with
both low gain and high gain antennas, and Relay operations using a
UHF transceiver, fixed low gain omni-directional antenna, and a
choice of two relay satellites.
The original program requirement was to return 80 Mbits of data every
2 Sols (1 Sol = 1 Martian day), and the primary means of
communication was to be the DTE/DFE link. The UHF relay concept had
never been tried before on a Mars mission, and the MER UHF capability
was viewed as a secondary experimental option for both data return
and commanding.
As the mission progressed, it was quickly recognized how versatile
and robust the UHF relay operations were, and UHF operations quickly
became the preferred means of data acquisition. (The first attempt
to use the UHF link at 256 kbps returned 110 Mbits of data in one
sol, nearly triple the original program requirement. To date, the
best relay pass was on MER B Sol 450 when 190.3 Mbits were received
via the Odyssey relay.)
To date, about 96% of the MER data has been returned using the UHF
Ivancic Expires December 7, 2009 [Page 4]
Internet-Draft DTN Network Management Requirements June 2009
radio and the two relay satellites.
ODYSSEY RELAY OPERATIONS
The primary and preferred means of obtaining data from MER is the UHF
relay through the Mars Odyssey satellite. Launched in 2001, Odyssey
has a duplicate of the UHF radio flown on MER, and full duplex
operations are possible, using a reliable link protocol, and at
double the maximum data rate possible with MGS. Approximately 88% of
the MER data returned to date have been through Odyssey.
Mars
Odyssey
Spacecraft
+-------+ _ +-------+
| |:_:| |
Deep Space Link +-------+ +-------+
_,,..--''' .
. ___..---'' `. Proximity
-.._ `. `. Link
`- /\''' `. _,,.
/__\ `,-'
Deep ,'.------.
Space `. / | Mars |
Network `. | | Expl.|
| | Rover|
| `------'
Odyssey Relay Operations
Figure 1
Odyssey affords an average of 1.8 communication passes per Sol
(assuming a 20 deg elevation mask to avoid multipath and line-of-site
blockage), with an average data collection time per pass of about 6
minutes.
The UHF radios in both MER and ODY use a built-in CCSDS Proximity
Link 1 protocol, which automatically will manage the retransmission
of missed or corrupted data frames. The normal use of the UHF relay
is to transmit in Reliable Bit Stream Mode, sending DTE TM frames
encapsulated in Prox-1 data units.
The basic operations cycle is that the data are acquired from one of
the three possible sources, along with a catalog of what MER thought
it had sent, a data operations team compiles data from the various
possible paths (DTE/DFE/relays through different DSN stations and
Ivancic Expires December 7, 2009 [Page 5]
Internet-Draft DTN Network Management Requirements June 2009
different mission operations centers), and full and partial data
products received are examined by a Data Management Team to determine
what might be missing or corrupted. This is work that reliable
protocols such as CFDP or DTN could be doing automatically in future
missions.
Once data is manually examined, the Data Management Team forwards
retransmission requests to the Operations team, along with a
tabulation of what data products stored on MER have satisfactorily
been received and which therefore may be erased from the rover's data
storage.
The Operations team then crafts the commands to request
retransmission during a future pass, and eventually radiated to MER
in either an X-band DFE pass or via the Odyssey relay spacecraft.
The DTE/DFE command sequences have to be crafted by one team and
reviewed by another prior to radiation to the spacecraft by a third
team. In the case of retransmit commands to be relayed through
Odyssey to the rover, a fourth ODY spacecraft team has to review the
command load and get the commands uplinked to ODY. Much of this
manual work would be eliminated by well-engineered end-to-end use of
CFDP and/or DTN.
The location of received data has to be tracked down sometimes, as
when files come in to a ground DSN station or a relay spacecraft GDS
and for whatever reason fail to be forwarded to the MER GDS. Often
this requires manual searches of directories and a little detective
work. Automated routing protocols would alleviate this situation.
One of the tasks of the data operations team is to determine WHERE
the data gaps occurred; sometimes the data are missing or corrupted
during the UHF relay, sometimes the relay satellite link to earth is
the source of the gap. Where the data has gone missing is a factor
in subsequent mission planning and commanding. With the current
implementation of the system, the relay satellites do not store the
data for retransmission, so data gaps must be filled by the rover on
a subsequent pass. CFDP with store and forward and custody transfer
would alleviate much of this manual work.
In addition to the business of manually examining what data the rover
thought it sent and comparing to what had been received (after
finding it all from the 3 possible paths), each and every radio link
has to be commanded in terms of data rates, pass durations and paths.
For example, during any one day, MER would have the opportunity to
pass critical data via 2 relay paths or one DTE path. These routing
decisions are made by the Operations team every day.
OPERATIONS COMPARISON WITH CFDP
Ivancic Expires December 7, 2009 [Page 6]
Internet-Draft DTN Network Management Requirements June 2009
The MER mission was been a great success and proved the viability of
UHF Relay and Store and Forward operations. The utility and
reliability of this method of communications is so great that the
Phoenix mission (a Mars lander) is a UHF-only mission; all data and
commands to Phoenix are via a relay satellite and a UHF proximity
link radio.
The current process has various inefficiencies that can be improved
upon in future missions. The use of common end-to-end protocol
stacks will reduce some header overhead by eliminating the need for
frame encapsulation, and the whole manual process of having to hunt
for data, and having to use custom software to merge multiple
sources, evaluate missing data and create replay commands can be
replaced with the use of standardized protocols such as DTN which can
automate the process of recovering missing data. The option of using
DTN in unacknowledged mode will allow ground team control of
retransmissions when power considerations might make automatic
retransmissions inadvisable.
The original X-band design of the MER mission, and the power-saving
operations concept of severely limiting the use of the deep space
transmitter on MER meant that bidirectional communications was
difficult, and it may have been impractical to rely on a protocol
where transactions need to be acknowledged within the time of a pass;
the operational limit of the X-band transmitter was just about one
round-trip light time to Earth, so that any NAKs generated
automatically by a protocol at the DSN could not be acted upon during
that transmission session. Subsequent communications opportunities
would next come up via the relay satellites, or possibly at another
DSN station, and none of those entities would have any knowledge of
the transaction the NAK response would pertain to.
The MER uplink strategy used a very compressed and uplink-efficient
method of requesting retransmissions and file deletions. One
comparison from a study that looked at a particular day of operations
showed that the MER commands for retransmission/deletion took 4254
bytes, whereas if CFDP was used to automate, the traffic would be
22498 bytes. (This was on Sol-73, MER-A, where there were 1066 file
deletions and 66 file retransmissions required.)
The difference is due to the fact that CFDP deals with each file
separately without the "shorthand" used by MER (which can delete
ranges of files in one step). The trade is that CFDP automates the
process, whereas with the MER process, a Data Management team has to
manually determine what is missing and what data seta are complete
and therefore can be deleted from on-board storage. Essentially, the
MER process was designed to minimize uplink requirements, whereas
CFDP is designed to allow for automated and rapid release of file
Ivancic Expires December 7, 2009 [Page 7]
Internet-Draft DTN Network Management Requirements June 2009
storage space onboard. Note CFDP is a predecessor to the DTN bundle
protocol. DTN with security would likely increase these overhead
numbers relative to CFDP.
2.2. Simple Sensor Networks
Simple sensor networks consisting of low-power devices are likely to
either run with extremely reduced DTN capabilities or utilize a
sensor network to DTN proxiy. The latter is more likely as low-power
sensors with limited processing capabilities or radio transmission
range are not likely to have much onboard storage or be synchronize,
capable of routing, name resolution, or running the DTN security
protocol.
There may be cases where simple sensor networks are asleep often, but
synchronized to the extent that they can wake up a nearly the same
time to communicate some information. These simple nodes would
probably have limited network management capability. How DTN bundle
agent discovery and routing is performed in such networks is to be
determined.
Note, the current DTN bundle specification requires DTN security
capabilities for checksums (point-to-point reliability).
2.3. Data Mule
In the Data Mule scenario, DTN bundle agents communicate with each
other mainly via some type of circulating entity. This entity may be
a unmanned (or manned aircraft), a ship, a bus, or any type of
vehicle that periodically moves over the same relative area.
Connectivity is likely to consists of high periods of disruption
followed by short periods of connectivity over relatively high-
bandwidth, low-delay, symetric links.
In the Data Mule scenario, connectivity is generally of the episodic
variety (opportunistic).
In the scenario depicted in figure 2, the bundle agents could be a
concentrator for DTN aware or non-DTN aware sensor networks.
Ivancic Expires December 7, 2009 [Page 8]
Internet-Draft DTN Network Management Requirements June 2009
.-------.
|Bundle | .-------.
|Agent 1| |Bundle | .--o
`-------' /''\. |Agent 5| / `.
`. .' '._ .-----.,--. `-------' / |
\ | `.._|Data | ``. \ / `.
/ |Mule | `-. \ ' |_
| `-----' `. ,/ |
| Movement \.,.--- |
' <<======= |
/ |
/ |
| Path Well .-------. |
| Traveled |Bundle | |
| |Agent 3| |
/ ...._ `-------' \
| | `. / `\
\ _.. | `./ .'
`' `---`... `.._ `-. ,'
.-------. _, ". ``. \ _,,'
|Bundle |,' `. \ `--...,-'.
|Agent 2| `. `. |
`-------' `. _ \ .-------.
' `'-...._ | |Bundle |
`"--------' |Agent 4|
Data Mule Scenario
Figure 2
2.4. Rapid Disruption
Many wireless networks - particularly military wireless networs are
episodicalty connected because of terrain, foiliage, weather, and
jamming. Furthermore, radio signal power fades can cause rapid very-
short periods of disconnection. All of these instances may result
short periods of disruption as well as rapid changes in topology.
Applications that use the transmission control protocol (TCP) may
perform very poorly in such environments due to TCP's congestion
control algorithms - even in a non-congested environment.
Furthermore, any use DNS is problematic in a disrupted network as one
is likely to be unable to reach the DNS server. Caching DNS locally
is one possible solution.
DTN provides some potential solutions for such networks. DTN routing
may be capable of moving messages towards destination via store and
forward if the proper naming structures and routing algorithms can be
Ivancic Expires December 7, 2009 [Page 9]
Internet-Draft DTN Network Management Requirements June 2009
developed. Late Binding does not require DNS lookups, but still
requires localized name-to-address resolution which is somewhat
analogous to a cached DNS.
DTN routing (or any type of routing) in a rapidly changing topology
is problematic and can result in very poor performance over wireless
technologies as there is a potential to have the routing algorithms
self-congest the wireless links and still not be able to converge
properly.
In tactical edge military networks there may be a mix of IP and
non-IP radios. DTN Bundling, as a network overlay, provides a means
to bridge IP networks and non-IP data-links together.
2.5. Low Earth Orbiting Sensor Satellite
The Low Earth Orbit LEO scenario described is for a sensor satellite
communicating directly with ground terminals. One such network is
decribed in reference [CLEO]. Note, in this scenario, no
geostationary relay satellite is involved. Here, the contact times
may be known in order to direct the satellite transmitter to turn on.
Some type of automated hailing could also be used as is done with the
Mars rovers to Mars relay satellites.
Ivancic Expires December 7, 2009 [Page 10]
Internet-Draft DTN Network Management Requirements June 2009
LEO
Sensor
Satellite
+-------+ _ +-------+
| |:_:| |
+-------+ +-------+
,' `.
Space/Ground ,' `-. Space/Ground
Link 1 ,-' `. Link 2
,' `._
,' `.
,' Connect Connect `._
_,' T1 T2 `.
. ' ` /
Ground `. ..,' Ground
Station /\'' ___...------'''''''------....__ /\ Station
1 /__\.,--' `'--./__\ 2
_,,-' ._ _, `--.._
' `. Ground/Ground Ground/Ground ,' '
`-. Link 1 Link 2 ,-'
`._ ,-'
`. _,'
' .-----------.
| Data |
|Collection |
| Center |
`-----------'
Low Earth Orbit Sensor Satellite
Figure 3
Low Earth Orbit (LEO) is a low-propagation-delay environment of less
than ten milliseconds delay to ground, with long periods of
disconnection between passes over ground stations. Contact times
consist of a few minutes per ground station for satellite orbiting at
a couple hundred kilometers (~100 minutes per pass). Thus, the more
ground system that are available, the greater the potential for
contact. The ground stations are connected across the terrestrial
Internet, which has different operating conditions (congestion-
sensitive, always on) from the private links between satellite and
ground station (intermittent but scheduled, and dedicated to
downloading with no need for congestion control.)
In this scenario, the DTN bundle agent onboard the satellite does not
need to perform forwarding. The satellite is a source for sensor
data and may be a sink for command data.
Ivancic Expires December 7, 2009 [Page 11]
Internet-Draft DTN Network Management Requirements June 2009
The main reason to use DTN bundling in this scenario is to provide a
standardized store-and-forward technique and to break the control
loops between the space/ground link and the ground/ground link.
The space/ground link is a private link that is congestion free. The
desire is to fully utilize that link when it becomes availabe. For
Sensor satellites, the space/ground link is generally highly
asymetric with uplink to the satellite at kilobit per second rates
and downlink from the satellite at tens to hundreds of megabits per
second. Transport protocols that operate well in this highly
asymmetric enviroment are required.
The ground/ground link is over the Internet where the data rate may
not be controllable and may not be known. Furthermore, congestion
friendly transport protocols are require.
2.6. Geostationary Bent Pipe Relay Satellite
The Geostationary (GEO) Bent Pipe relay satellites are quite common
today. It is highly likely that DTN technology will be deployed in
such enviroments.
GEO
Bent Pipe
Relay Satellite
+-------+ _ +-------+
| |:_:| |
RF Link +-------+ +-------+
_,,..--''' .
. ___..---'' `. RF
-.._ `. `. Link
`- /\''' `.
/__\ `,
Ground | . .------.
Station / '. | UAV |
/ '. `------'
| \
.-----------. \
| Data | \
|Collection | `.
| Center | |
`-----------'
GEO Bent Pipe Relay Satellite to UAV
Ivancic Expires December 7, 2009 [Page 12]
Internet-Draft DTN Network Management Requirements June 2009
Figure 4
NASA's Advanced Tracking and Data Relay Satellites (TDRS) are bent
pipe relays. They have no onboard processing or storage. Only RF
energy is relayed between ground and lower oribiting spacecraft such
as the International Space Station. The relay satellite performs the
tracking function to keep the LEO system in site as long a possible
or for some predefine time period. The TDRS system is a highly
scheduled system. Thus DTN for TDRS is as much a function of
disruption due to scheduling of limited resources than disruption due
to the inability to physically make a connection.
KU-band Geostationary satellites are another form of bent pipe relay.
In the scenario described, a KU-band GEO satellite provides the RF
connectivity between the satellite ground station and an unmanned
aerial vehicle (UAV). Unlike the TDRS case,here, the antenna system
onboard the moving UAV tracks the GEO satellite. The GEO satellite
performs no tracking function.
As in the case of the LEO sensor satellite, the space/ground link is
a private link that is congestion free. Communication may be more
symmetric than for the LEO sensor satellite. In fact, for systems
which utilize commercial Ku-band GEO satellites, the link to the
aircraft is likely to of a higher data rate than the link from the
aircraft. This is due to regulatory issues regarding mobile systems
at KU-band frequencies. Regardless, the desire is to fully utilizes
the RF link when it becomes availabe. In order to obtain maximum
performance, transport protocols that operate well in this enviroment
are required .
As in the LEO sensor satellite case, the ground/ground link is over
the Internet where the data rate may not be controllable and may not
be known. Furthermore, congestion friendly transport protocols are
require.
2.7. Unmanned Aeronuatical Vehicles
The scenario depicted in figure 5 is that of a multihomed unmanned
aeronautical veihicle (UAV). In this scenario a UAV is performing
atmospheric research over the North Pole. The UAV is in contact with
a Ku-Band Satellite with a ground station located in North America
during its flight up to the North Pole. After approximately 60
degrees North Latitude, the UAV no longer can communicate with the
Ku-Band satellite and must store information. The UAV may have
communication with the Iridium satellites at any time during the
flight, but at a dramatically reduced bandwidth - perhaps only enough
to send meta-data down. The return flight is over the Pacific Ocean
along the Korean and Japanese coastal areas. At this time, Ku-Band
Ivancic Expires December 7, 2009 [Page 13]
Internet-Draft DTN Network Management Requirements June 2009
connectivity is again available, but through a different satellite
and to a different ground station located somewhere in Japan. Thus,
we have a multihomed store-and-forward system with vastly different
link capacities between the Ku-Band satellite service and the Ka-Band
Iridium Low Earth Orbiting satellite constellation service.
. ,'
`._ NORTH ,'
`._ POLE ,-'
`-.__ _,,-'
Above 60 Degrees `'------''' +-------+
No Ku-Band |Iridium|
Connectivity .'--'. +-------+
|UAV |
XXXXXXXXXXXXXXXXXXXXXXX `-++-' XXXXXXXXXXXXXXXXXX
X +--------------+ XX
GEO X +--------------+ XX GEO
Bent Pipe X || X Bent Pipe
Relay Satellite X +--++--+ X Relay Satellite
+-----+ _ +-----+ XX +------+ X +-----+ _ +-----+
| |:_:| | XX X | |:_:| |
+-----+ +-----+ X X +-----+ +-----+
. XXXXXXXXXXXXX
`: . .
`. `. . _,
\ /\''' .,'/\ ,'
\/__\ /__\,'
\ Ku-Band Ku-Band ,-'
\ ASIA North /
\ PACIFIC America ,'
| OCEAN ,' NORTH
ASIA | / AMERICA
| ,'
| /
\
'
UAV Atmospheric Research
Figure 5
3. General Requirements
DTN is in its infancy. Understanding what is useful to monitor and
what is necessary to configure is currently unknow with the exception
of some basic bundling characteristics. DTN networks can be viewed
Ivancic Expires December 7, 2009 [Page 14]
Internet-Draft DTN Network Management Requirements June 2009
as both ad hoc in nature as well as having an added complexity due to
varying degrees of delay and/or disruption and/or disconnection. In
addition, DTN networks will likely consist of connecte systems with
with wide-bandwidth, low-delay links and disconnected systems with
low-bandwidth, noisy, and perhaps long-delay links, Thus DTN network
management will be much more complex than managing a connected
system.
The notion that one may be disconnected for long periods of time make
network management, performance measurement and remote configuration
an extremely interesting an difficult problem. Performance
information may be stale. State information such as available
storage capacity may be stale. In addition, remote configuration is
quite problematic as one may lock themselves out of a system. Thus
remote validation and graceful way to recover need to be developed.
A DTN Network Managment system MUST be capable of both Local and
Remote Network Management. The Network Managment system MUST be
capable of monitoring bundle processing and system characteristics
such as: Convergence Layers, Multi-Homing, Radios parameters,
Processing Power, and Onboard Storage. A DTN Network Managment
systems MUST be capable of configuring routing, local name resolution
caches, local time, security and security policy configurations and
any convergence layer and radio parameters necessary to operate the
system.
The goal of the Management and Configuration is that it should work
for all DTN environments including systems with high-delay, long
periods of disconnection and low-bandwidth. System may be multiple
hops away and never reachable in a single hop. In addition, system
may not be synchronized (although current bundling RFC 5050 assumes
synchronization).
It is understood that there may be extreme cases where due to long
propogation delays, limited processing power and memory, and
extremely limited bandwidth, that standard DTN network management
techniques are not use and that a custom implementation will be
required.
Remote Configuration MUST be Incremental and Include Test and
Validation. In addition, there MUST be a mechanism for the DTN node
to recovery to the last know good state. The rational here is that
one cannot access this sytem locally and is likely to misconfigure
some parameter and get locked out of the DTN node and perhaps render
the DTN node non-functional. Thus the DTN node must have some
autonomous capability to sense it is non-functional and attemp to
restore itself to some last known good state. Incrementally appling
configuration changes with some test and validation will help to
Ivancic Expires December 7, 2009 [Page 15]
Internet-Draft DTN Network Management Requirements June 2009
aliviate misconfigurations or indentify them at the earliest state
possible.
3.1. Local Network Management
For a DTN system we define the term "Local Management" to imply that
a one can access a the device by being physically at the devices
(i.e. consule port) or via real-time access such as via a connected
IP network. Here we assume high bandwidth, no disruption and
insignificant delay
3.1.1. Requirement for Local Network Management
A DTN Node MUST be capable of Local Network Managment
3.1.2. Rationale for Local Network Management
Local managment of DTN will be required Use of existing network
managment techniques and technologies will enable reuse of existing
code and help in early deploment of DTNs.
Local Network Management will likely be performed prior to deploying
a DTN node, at least for initial default configurations.
The network administrator may be physically colocated with the DTN
agent and capable of direct login via a consule port. One example
may be a milatary personnel onboard an aircraft that contains a DTN
forwarding agent. Other DTN systems may be part of a DTN network
overlay, but reside on a network that is alway connected. An example
of this is a ground station for a Deep Space Network. That ground
station is always connected to the Internet via wide bandwidth links.
Neither of these situations require operation over disconnected
links.
Early testbed configurations are likely to emulate disconnections and
long delays while incorporating real-time back channels for
monitoring and configuration.
3.2. Remote Network Management
We define "Remote Management" to imply managing a DTN node over a DTN
network. This assumes that the systems may experience and or all of
the following: long propogation delays, long periods of disruption,
long periods of disconnection and operate over low bandwidths.
Ivancic Expires December 7, 2009 [Page 16]
Internet-Draft DTN Network Management Requirements June 2009
3.2.1. Requirement for Remote Network Management
A DTN node that is not connected to a network which provides real-
time access MUST be capable of being managed via a remote system
using the bundling protocol.
3.2.2. Rationale for Remote Network Management
A DTN node may be multiple DTN hops away from a managment agent. In
such cases, remote network managment is required. There is no
alternative.
3.2.3. Requirement for use of Bundles for Remote Network Management
Remote DTN network management MUST be performed using the bundling
protocol.
3.2.4. Rationale for Use of the Bundling Protocol for Remote Management
Currently, the only known way to communicate between DTN nodes in a
standard way is via the bundling protocol.
3.3. Security
3.3.1. Requirements for Secure Network Management
The network management systems must provide appropriate levels of
security for monitoring and configuration for both local and remote
monitoring and control.
3.3.2. Rationale for Secure Network Management
Without proper security controls for network monitoring and
configuration, DTN networks will not be deployed in operational
systems - particularly space or military systems which currently are
considered two primary applciations for DTNs.
3.3.3. General Comments Regarding Secure Network Management
DTNs will likel deploy multiple security levels with monitoring being
of modest security while configuration control requiring much higher
levels of security.
For local network management, secure Login and encrypted data
transfer may be accomplishe using existing techniques such a Secure
Shell (SSH) or Transport Layer Security (TLS). Remote management may
use bundling protocol or some secure DTN application similar to SSH.
Ivancic Expires December 7, 2009 [Page 17]
Internet-Draft DTN Network Management Requirements June 2009
4. System Characteristics
4.1. Bundle Processing
This section descipes items that need to be monitored specifically
related to bundle processing.
4.1.1. Bundle Statistics
The bundle processor MUST be capable of providing the following
measures: The bundle stats command shows the following counts:
o Pending - the number of pending bundles and associated Quality of
Service (QOS) parameters.
o Received - the number of bundles recieved and associated QOS
parameters.
o Locally Delivered - the number of locally delivered bundles.
o Transmitted - the number of transmitted bundles and associated QOS
parameters.
o Expired - the number of expired bundles and associated QOS
parameters.
4.1.2. Bundle Fragmentation
The bundle process should keep track of the number of reactive and
proactive fragmented bundles recieved and transmitted as well as the
number of pending fragments.
4.2. Convergence Layers
The convergence layers manage the protocol-specific details of
interfacing with particular underlying protocols and present a
consistent interface to the bundle layer. The complexity of one
convergence layer may vary substantially from another, depending on
the type of underlying protocol it adapts. The following section/
decribes some of the general characteristics of various converence
layers.
4.2.1. Internet Protocol
4.2.1.1. TCP/IP
This protocol provides bundle conveyance over a TCP connection and
specifies the encapsulation of bundles as well as procedures for TCP
Ivancic Expires December 7, 2009 [Page 18]
Internet-Draft DTN Network Management Requirements June 2009
connection setup and teardown. [TCPCL]
Some of the key measurable parameters in the TCP convergence layer
are:
DATA_SEGMENT - Indicates the transmission of a segment of bundle
data.
ACK_SEGMENT - Acknowledges reception of a data segment.
REFUSE_BUNDLE -Indicates that the transmission of the current bundle
shall be stopped.
KEEPALIVE - Keepalive message for the connection to help determine if
the connection has been disrupted.
4.2.1.2. UDP/IP
This protocol provides bundle conveyance over a UDP specifies the
convergence layer for transmitting either bundles or LTP blocks over
UDP connection.
In general, the use of the bundle protocol over a UDP CL is
discouraged. Bundles can be of (almost) arbitrary length, and the
bundle protocol does not include an effective retransmission
mechanism. In IPv4, the maximum size of a UDP datagram is nearly
64KB. Whenever possible the bundle protocol SHOULD be operated over
the TCP Convergence Layer or using some other convergence layer over
UDP (e.g. Licklider or Saratoga Transport Protocols). [UDPCL]
It may be desirable for a UDP CL to send "keep-alive" packets during
extended idle periods. This is an optional configuration. The
ability to configure and monitor UDP "keep-alive" should be available
as part of the network management capability.
4.2.1.3. SCTP/IP
Currently there is no know convergence layer for DTN over Stream
Control Transport Protocol (SCTP).
4.2.2. CCSDS
The Consultative Committee for Space Data Systems (CCSDS) provides a
forum for discussion of common problems in the development and
operation of space data systems. One of the primary purposes of
CCSDS is to develop recommendations for data and information systems
standards. There are numerous potential CCSDS data-link protocols
that could be used to transfer bundles between space systems. They
Ivancic Expires December 7, 2009 [Page 19]
Internet-Draft DTN Network Management Requirements June 2009
include: CCSDS Telemetry Packet, CCSDS Space Packet, Advance Orbiting
Systems and Proximity Space Link Protocols. Detail information can
be found at http://public.ccsds.org/publications/SLS.aspx. The
current approach for the deep space backbone is to run DTN over LTP
over the appropriate data-link protocol. Thus, there may be specific
parameters from these data-link protocols that are useful to monitor
which provide insite into DTN operations.
4.2.3. Licklider Transport Protocol
The Licklider Transmission Protocol (LTP), is designed to provide
retransmission-based reliability over links characterized by
extremely long message round-trip times (RTTs) and/or frequent
interruptions in connectivity. LTP is principally aimed at
supporting "long-haul" reliable transmission in interplanetary space,
but it has applications in other environments as well.[RFC5326]
LTP is a complex protocol and is required to maintain numerous
amounts of state information in order to be able to perform in the
environment it was designed for. In order to manage a DTN network
that utilizes LTP, maintaining measurements of the state parameters
in Section 3, Session Management Segement, Section 4, Requests from
the Client Service and Section 6, Internal Procedures of the LTP
Protocol is desirable.
4.2.4. Bluetooth
TBD - There is currently no identified standard proposed for
bluetooth convergence layer. This is currently being held as a place
holder and will either be expanded upon or removed in later
revisions. The author would appreciate any input for this area.
4.2.5. Removeable Storage
TBD - There is currently no identified standard proposed for
removable storage convergence layer. This is currently being held as
a place holder and will either be expanded upon or removed in later
revisions. The author would appreciate any input for this area.
4.3. Multi-Homing
Multihoming in the contect of a DTN forwarding agent, inidcates that
there are two or more physical interfaces from which bundles can be
recieved or transmitted. These physical interfaces my reside on the
same underlying network type (i.e. IP or Radio-Layer network) or may
reside on completely different network types (i.e. IP on interface A
and Bluetooth on Interface B). In addition, each physical interface
may correspond to a different convergence layer. Furthermore each
Ivancic Expires December 7, 2009 [Page 20]
Internet-Draft DTN Network Management Requirements June 2009
interface may be acitive simultaniously or at different time periods.
4.3.1. DARPA Dynamic Spectrum Access (DSA) Radio
The United States Defense Advanced Research Program Agency (DARPA)is
sponsoring development of a congnitive radio that is capable of
finding available spectrum and is cabable of operatin over multiple
channels. DTN is expected to be a main component of this system and
will be used for secure content storage and distribution with multi-
tier security for content search.
At this time, the author is uncertain if the radio will operate on
multiple simultaneous available links or just operate over multiple
channels. In one case, there are two or more physical interfaces
from which bundles can be transmitted or recieve. In the other, that
may not be the case. However, if one is bouncing between multiple
channels and each channel has its own physical address, that could be
considered a multi-homed radio system.
4.3.2. Deep Space / Proximity
A system such as a space relay may be multi-homed - paricularly if
one of the RF links is between Earth and the Relay and the second is
between the relay and a terrestial over. In such an example, the
radios and antenna systems and associated transmission
characteristics for proximity communications will be vastly differnet
than the characteristics for the long-haul deep-space commnuications.
Note, the links may not be active at the same time due to orbital
dynamics or simple for power resource scheduling.
4.4. Radios
Many, if not most DTN agents will be mobile and connect to the DTN
network via radio systems. As such, those radio systems SHOULD
expose critical configuration and performance parameters to the
network management system. This capability is often built into
current radio systems via vendor defined MIBS, or, for radio systems
that have vast deployement by multiple vendors, industy defined MIBS.
Radios can be Fixed-Rate or Bandwidth-On-Demand (BOD) radios. Fixed-
rate radios implies that the rate is set prior to or at the beginning
of communication and remains that way through the duration of
communications. BOD implies that the communicaiton rate may very
throughout the transimssion duration.
It is expected that specific parameters will be extremely useful to
monitor in order to troubleshoot systems as well as accertain
performance. In addition, there are likely to be specific radio
Ivancic Expires December 7, 2009 [Page 21]
Internet-Draft DTN Network Management Requirements June 2009
configuration parameters. Unfortunately, for the forseeable future,
many of these are likely to be implementation specific.
4.5. Processing Power
Whereas on may DTN devices, resources may be limited, it is likely to
be useful to monitor and record processing power. Such information
may be used for future desing or to determine what bundles can be
transmitted over what radio system. One may hold onto a bundle or
change the routing weights based on the amount of power available for
use by the entire system (i.e transmission power).
4.6. Onboard Storage
DTN is a store and forward technology. One of the DTN bundle
forwarding agents main functions will be storage and management of
bundles. Thus, it will be important to monitor this storage usage
including total amount of storage and how that storage may be
partitioned. For example, one may have policies in place that limit
the amount of storage particular sources or groups may use.
Exceeding configured limits may result in bundles being denied or
dropped. The ability to obtain information regading such denials or
drops is expected to greatly aid in trouble shooting systems and
configuration management.
4.7. Routing
Routing protocol configuration, static routes and default route are
critical to forwarding bundles to the correct endpoints. The Route
Tables MUST be exposed to the network managment system The routing
configuration parameters and all default and static routes MUST be
expose to the network management system.
A DTN routing agent (a system that act as an intermediary and can
both send and recieve bundles) MUST be capable of default and static
routing. A bundle routing agent SHOULD be capable of some dynamic
routing capability. There are cases were bundle agent is and end
system and does not act as an intermediary (i.e. simple sensor webs,
space-based sensor platforms). In such cases, default routes or
static routing MAY be sufficient.
4.8. Name Resolution
Since DTN systems are name-base, not address-base, it will be
important to monitor what the DTN router precives as the current
name-to-next-hop address (name resolution). The ability to monitor
and correlate this information to the precived state of the overall
DTN network will be critical for trouble shooting DTN network
Ivancic Expires December 7, 2009 [Page 22]
Internet-Draft DTN Network Management Requirements June 2009
operation. Thus, the DTN bundle agent MUST be provide the ability to
monitor and configure the local cached name resolution system. In
addition, reports that include the name resolution database should
include a timestamp indicated what the DTN agent beleive is its
current time. This can be used to correlate the state of this
particular DTN agent with other DTN agents in the network.
4.9. Local and Network Time
The current DTN Bundle Architecture as described in RFC4838 requires
network synchronization to operate with the bundle protocol, RFC5050.
It will be extermely useful to expose what the bundle agent beleive
it's local time and network time are. This information can be used
for "local" DTN network management and may prove useful "remote"
management.
4.10. Security
Properly implemented security when improperly configured often
renders systems inoperable. This results in the appearance that
security breaks everything. Furthermore, misconfigured security can
be extemely diffucult to track down because one should not be able to
probe a secure system without the proper credentials. This is an
extermely difficult matter even in a fully-connected, high-bandwidth,
low-latency environment.
4.10.1. Multi-layer Security
Most DTN routing agents will likely implement mult-layer security. A
system SHOULD have different layers of security for monitoring versus
configuration. A system may also have different layers of security
for monitoring different properties of the DTN node. For example,
one may wish to allow most users to monitor bundle and radio
performance, but may require higher levels of security to monitor
security configurations. This is likely to also be the case for
configuration. Configuration SHOULD require higher security
credentials than monitoring.
4.10.2. Firewall Settings
As with all current network security systems, Firewalls have proven
useful to improve the security of systems. To date, DTN firewalls
have not been implemented. This is likely to change if DTN becomes
common place and matures. Thus, the DTN agent SHOULD be capable of
exposing the firewall rules to the network managment system for
monitoring and configuration. This exposure SHOULD require
appripriate security credentials.
Ivancic Expires December 7, 2009 [Page 23]
Internet-Draft DTN Network Management Requirements June 2009
4.10.3. Radio
Many, if not most DTN agents will be mobile and connect to the DTN
network via radio systems. As such, those radio systems SHOULD
expose critical configuration and performance parameters to the
network management systemh. This capability is often built into
current radio systems via vendor defined MIBS, or, for radio systems
that have vast deployement by multiple vendors, industy defined MIBS.
5. Network Management Utilities
In order to perform the most simple of network management functions
and network troubleshooting, a set of tools is needed. Some of these
tools are listed below.
DTN-ping: An echo request and reply using bundles.
DTN-send/receive: An application the sends and recieves bundles.
DTN-traceroute: An application that can provide information on how
a bundle move through the system from source to destination and
back. It is not obvious has to how one may wish to do this in a
DTN.
DTN-perf: An applicaiton that provides performance measurements
between a source and destination similar to IPerf for Interent
Protocol networks.
DTN-heartbeat: An application that sends a periodic status to some
monitoring node in order to know all is well and the node is still
alive. This application should not use much bandwidth and should
have a configurable heart rate.
DTN-email: A DTN mail application.
DTN-chat: A DTN chat application that would be useful for
troubleshooting systems. A conference capability would be useful.
Bundle Count / Traffic Measurement: A simple application that
provide the very basics of network monitoring. Something the help
the DTN community get started with monitoring before a full
network management applicaiton is developed.
Many of these tools exist in various forms today for DTN. However,
they currently are not interoperable between various implementations
of DTN such and DTN-2 and ION.
Ivancic Expires December 7, 2009 [Page 24]
Internet-Draft DTN Network Management Requirements June 2009
It is apparent that one of the first items that should be
accomplished in order to obtain interoperability for the tool sets
listed above as well as for network management applications will be a
DTN application interface, a standard DTN API.
6. Security Considerations
Security is likely to play a major role in many DTN deployments.
Since DTN is a network overlay, in order to understand why something
may not be working as expected one will have to understand not only
what is happening at the DTN layer, but also at the lower layers.
Security at any of these layers is likely to render the system
inoperable to some degree. Thus, it is desirable to communicate
various security settings to the network management system. This,
however, becomes a security issue and protecting such information and
who can obtain access to such information is critical.
7. IANA Considerations
This document neither creates nor updates any IANA registries.
8. Acknowledgments
This document is the result of input and discussion from the DTN
Research Community in general. A splinter group was formed to
specifically address Network Management issues. The author greatly
appreciates the input and insight of that group via emails and
teleconference discussions.
Some of the introductory information was taken from documents
provided by Lloyd Wood.
9. Informative References
[AC1L179] Cerf, V. and K. Scott, "In-Space Routing Study", NASA
Study Task AC1L1-79 Report DR 318, September 2005.
[CLEO] Ivancic, W., Wood, L., Eddy, W., Stewart, D., Jackson, C.,
and A. da Silva Curiel, "Delay/Disruption-Tolerant Network
Testing Using a LEO Satellite", NASA Earth Science
Technology Conference Paper A4P2, June 2008.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Ivancic Expires December 7, 2009 [Page 25]
Internet-Draft DTN Network Management Requirements June 2009
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
September 2008.
[TCPCL] Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
Convergence Layer Protocol",
draft-irtf-dtnrg-tcp-clayer-02.txt work in progress,
November 2008.
[UDPCL] Kruse, H. and S. Ostermann, "UDP Convergence Layers for
DTN", draft-irtf-dtnrg-udp-clayer-00.txt work in progress,
November 2008.
Author's Address
William D. Ivancic
NASA Glenn Research Center
21000 Brookpark Road, MS 54-5
Cleveland, OH 44135
USA
Phone: +1-216-433-3494
Email: william.d.ivancic@nasa.gov
Ivancic Expires December 7, 2009 [Page 26]
