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]