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]