DTN2-BPQ: comparison doc/plugin-architecture/plugin-architecture.tex

equal deleted inserted replaced

--1:000000000000
+:2b3e5ec03512
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\documentclass[11pt]{article}
+\usepackage{graphicx,times,lscape,fancyheadings,color}
+\textwidth 6.5in
+\textheight 9.0in
+\oddsidemargin -0.1in
+\topmargin -0.5in
+\parindent 0.0in
+\parskip 5pt
+\setcounter{secnumdepth}{4}
+\chead{}
+\input{local-macros}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{document}
+\title{DTN Plugin Architecture \\
+{\large Approved for Public Release, Distribution Unlimited.  [2/27/2007]}
+}
+\author{Rajesh Krishnan, Christopher Small, Ram Ramanathan, Joanne Mikkelson,
+and Prithwish Basu\thanks{Contact: pbasu@bbn.com, 617.873.7742}\\
+BBN Technologies, 10 Moulton St, Cambridge MA 02138}
+\date{\today}
+\maketitle
+\tableofcontents
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newpage
+\section{Introduction} \label{sec:intro}
+In this document, we describe a DTN reference system architecture.  The purpose
+of this document is to identify the components of the DTN reference system,
+and to define and specify the semantics of the interfaces between the
+components.
+%We seek feedback from the DTN community on the architecture and
+%the interfaces described here, for possible inclusion in future versions of
+%this document.
+The reader is assumed to be familiar with the Bundle Protocol
+specification~\cite{BP-ID}, the Bundle Security Protocol
+specification~\cite{BSP-ID}, and the DTNRG reference
+implementation~\cite{DTN2}.
+A particular goal of this architecture is to enable the community to experiment
+with multiple solutions for persistent storage, routing, naming and late
+binding, policy, and DTN convergence layers, while continuing to build upon a
+common core of open DTNRG standards and software. This is accomplished by
+defining interfaces that allow the experimental features to plug into the
+common core.  In this document, the term {\em system} will refer to the
+SPINDLE-II DTN system (the core of which is based on the DTN2 system), unless
+specified otherwise.
+\subsection{Glossary of Abbreviations and Technical Terms} \label{sec:glossary}
+Some commonly used acronyms and terms used throughout this document are listed
+and described below.
+\begin{description}
+\item[A/M] Application / Middleware
+\item[BPA] Bundle Protocol Agent
+\item[BP] Bundle Protocol
+\item[BSP] Bundle Security Protocol
+\item[CLA] Convergence Layer Adapter
+\item[DBMS] Database Management System
+\item[DP] Decision Plane
+\item[DS] Data Store
+\item[DTNRG-public] A design specification that will undergo the DTNRG consensus process during DTN Program Phase 2.
+\item[EID] Endpoint IDentifier for denoting a DTN endpoint (see~\cite{BP-ID})
+\item[GBOF-ID] Global Bundle Or Fragment ID
+\item[KB] Knowledge Base
+\item[Link] An association between two DTN endpoints (detailed description in Section \ref{sec:linktypes})
+\item[MANET] Mobile Ad hoc NETwork
+\end{description}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newpage
+\section{Overview} \label{sec:complist}
+The high-level components and interfaces of the system are illustrated in
+Figure \ref{fig:componly}.
+%%%%%%%%%%%%
+\begin{figure}[htbp]
+\centering
+\includegraphics[height=3in]{figs/components-toplevel.pdf}
+\caption{\label{fig:componly} Architectural Components and Interfaces}
+\end{figure}
+%%%%%%%%%%%%
+%
+The system SHOULD contain the following components (described in
+Section \ref{sec:compdesc}):
+\vspace{-4pt}
+\begin{enumerate}
+\setlength{\parskip}{-3pt}
+\item Bundle Protocol Agent (BPA), a DTNRG-public component
+\item Data Store (DS)
+\item Decision Plane (DP)
+\item Convergence Layer Adapter (CLA)
+\item Application/Middleware (A/M)
+\end{enumerate}
+Table \ref{tab:comp-functions} summarizes the key functionality provided by
+each of the five components. The above components MAY be implemented in
+separate processes to enable language and tool-chain independence across
+components.
+Instances of the BPA will be also referred to as the {\it core} and instances
+of the other four components shall be referred to as {\it plugins}.  The DS
+SHOULD provide a service that is accessible from all other components of the
+system.\footnote{As a result, the system can support both daemon-centric and
+database-centric concepts of operation.}
+The system MUST implement the relevant DTNRG-public interfaces as name below
+and described in Section \ref{sec:interfaces}:
+\vspace{-4pt}
+\begin{enumerate}
+\setlength{\parskip}{-3pt}
+\item Data Store Interface (used by BPA, CLA, DP, and A/M)
+\item Decision Plane Interface (used by BPA)
+\item Convergence Layer Adapter Interface (used by BPA)
+\item Bundle Protocol Agent Interface (used by A/M)
+\end{enumerate}
+All interfaces SHOULD be provided using the Inter-Component Communication
+protocol (discussed in Section \ref{sec:iccp}, defined in a separate document)
+for uniformity.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\begin{landscape}
+\begin{table}[htbp]
+\centering
+{\small
+\begin{tabular}{|p{1.5in}|p{1.5in}|p{1.5in}|p{1.5in}|p{1.5in}|}
+\hline
+{\bf BPA} & {\bf DS} & {\bf CLA} & {\bf DP} & {\bf A/M}\\
+\hline
+Implement the Bundle Protocol specification
+&
+Store, retrieve, and delete key-data pairs
+&
+Provide a bundle transport mechanism
+&
+Receive link and bundle event notifications from the BPA and
+generate actions (requests).
+&
+Generate, submit, and receive application bundle payloads
+\\
+\hline
+Implement the Bundle Security Protocol specification
+&
+Database management for metadata, including schema management,
+and query processing
+&
+Neighbor discovery (via scanning or staring)
+&
+Provide an adaptive dissemination service that can be used
+by various routing and naming protocols
+&
+Create/remove registration with BPA
+\\
+\hline
+Implement the Bundle Protocol Agent Interface (accessed by A/M)
+&
+Knowledge base management for metadata, including ontology management,
+query processing, and rule-based inference
+&
+Link formation, tear-down, and characterization (e.g., delay, capacity,
+loss)
+&
+Perform a long-term characterization of available communication
+opportunities (e.g., computes a cost metric)
+&
+Register procedure(s) for handling delivery failure
+\\
+\hline
+Use and implement support for DP interface, CLA interface, and DS interface
+&
+Manage storage of bundles, bundle metadata, registration information, BPA state
+if any, connectivity (historic, current, and scheduled) information, naming
+ontology, and cached content
+&
+Link status reporting (e.g., in response to queries)
+&
+Process policy inputs and respond to queries regarding decision choices
+that conform to policy
+&
+\\
+\hline
+&
+Database triggers
+&
+Implement CLA interface
+&
+Perform forwarding and scheduling decisions for bundles
+&
+\\
+\hline
+&
+Implement DS interface
+&
+&
+Perform route computation and/or route discovery
+&
+\\
+\hline
+&
+&
+&
+Perform name resolution and distributed name KB management
+&
+\\
+\hline
+&
+&
+&
+Implement DP interface
+&
+\\
+\hline
+\end{tabular}
+}
+\caption{Summary of functionality of system components \label{tab:comp-functions}}
+\end{table}
+\end{landscape}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newpage
+\section{Architectural Components} \label{sec:compdesc}
+In this section we describe each of the system components mentioned in Section
+\ref{sec:complist} (DS, CLA, DP, A/M). These will be implemented as plug-ins in
+the SPINDLE-II system; in other words, a newly developed module (implemented as
+a process) can be started on the node and its services will be automatically
+available to the other already running DTN processes.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Bundle Protocol Agent}
+\label{sec:bpa}
+The bundle protocol agent (BPA) of a DTN node offers bundle protocol (BP)
+services.  The BPA executes procedures of the BP and the Bundle Security
+Protocol (BSP) with help from other components in the system.  The BPA MUST
+comply with the DTNRG specifications for the BP~\cite{BP-ID} and the BSP
+~\cite{BSP-ID}.
+The BPA is responsible for implementing the mechanisms of the bundle protocol,
+but any key decisions (for example, those based on particular policies or
+optimization strategies) that need to be taken during the execution of such
+mechanisms MAY be exported to the {\em Decision Plane (DP)} module.  Typically
+these decisions are indicated within the BP and BSP specifications as local
+policy or implementation issues.
+The BPA is responsible for taking actions on every bundle that passes through
+the DTN node.   For example, the BPA is responsible for reading, creating,
+and updating fields in the bundle header.
+A comprehensive list of functional requirements for the BPA in terms of
+conformance to the BP and BSP can be found in a companion document \cite{MJ}.
+Some key functions are:
+\begin{enumerate}
+\item Forwarding a bundle to a ``next-hop'' node via a specified convergence
+layer adapter.  The BP specification talks about forwarding to the ``minimum
+reception group'' for each bundle in each of the unicast, multicast, and
+anycast scenarios. The DP must compute these lists and returns them to the BPA
+along with scheduling instructions to handle ``Class of Service'' requirements.
+\item Fragmentation and reassembly of bundle payload (both reactive and
+pro-active).
+\item Implementation of the Custody-transfer mechanism in the bundle header,
+sending Custody Acknowledgments, etc.: The decision of whether to accept,
+refuse, or relinquish custody is taken by the DP. Once a decision has been
+made, a list of DP-specified actions such as re-forwarding the bundle may have
+to be taken (depends on policy).
+\item Delivery to application: Deliver incoming bundle to application if it is
+{\it registered} on this node; otherwise abandon delivery based on policy.
+\item Discarding and Deleting a bundle: If the set of ``retention
+constraints'' on a bundle is empty, then discard the bundle and all references
+to it. Deleting a bundle involves removing all retention constraints and then
+discarding it.  This may happen upon bundle expiration. These mechanisms can
+richly interact with the policy module within the DP.
+\item Sending administrative bundles such as status reports.
+\item Security functions such as authentication, confidentiality,
+and data integrity.
+%prevention of DOS over resource strapped networks.
+\end{enumerate}
+In addition, the BPA SHOULD {\it implement} the Bundle Protocol Agent Interface that
+can be accessed by applications, and {\it use} the other interfaces listed in
+Section \ref{sec:complist}.
+%The interactions between the BPA and other components are described in
+%Section \ref{sec:XXX}.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Data Store}
+\label{sec:ds}
+The Data Store (DS) module offers a persistent storage service and is
+responsible for storing bundles, knowledge about bundle metadata, network state
+information (routing tables, name ontology data, content metadata, policy
+rules), and application state information (registrations and other metadata).
+We note that the SPINDLE system may eventually need to cater to a wide spectrum
+of solutions for the data storage layer. These may range from a dumb file
+system residing on Flash memory attached to a low power sensor node to a very
+powerful logic engine running on a powerful DTN node.  Hence a DS in the
+SPINDLE system could exist in one of the following incarnations of increasing
+capability:
+\begin{enumerate}
+\item A simple key-value store (that can be based on a file system) that allows
+other modules to add, retrieve and delete key-value pairs. Bundles, bundle metadata
+and network state information can exist in such a store. This may be
+applicable for resource-strapped devices such as battery-powered sensor
+nodes.
+\item A DBMS that allows other modules to add, delete, and get
+elements with multiple fields information (by its key). An DBMS might
+expose only {\it canned queries} to other modules, or it might allow other
+modules to submit queries, e.g. written in SQL.
+\item A full fledged knowledge base (KB) that supports deduction or inference
+by means of execution of rules (e.g., Prolog style) on stored facts. In
+addition to add/delete(key)/get(key) features, a KB will support advanced
+deductive database style querying features. Advanced KBs like Flora-2 even
+allow setting up ``triggers'' that fire when a certain rule executes
+successfully, and this typically results in the execution of a specified
+callback function.  A KB will include support for data storage, either
+internally, or via a back-end storage system such as MySQL or Berkeley DB.
+\end{enumerate}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Decision Plane} \label{sec:dp}
+The Decision Plane component includes the following subcomponents which may
+interact with each other:
+\begin{enumerate}
+\item {\it Router module:} Functions of a Router module include unicast and
+multicast route computation, generation of next hop(s) for bundles, replication
+and forwarding, bundle scheduling, decision to take custody of a bundle,
+decision to discard a bundle, etc.
+Note that while the BPA performs the forwarding mechanism to a particular CLA,
+it is the Router module that performs the consulting role for the BPA.  Similarly,
+for custody transfer, the BPA performs the mechanism of assuming and
+relinquishing custody and sending a custody-ACK to the previous node, but it
+consults the external router module to decide whether to take custody or not.
+\item {\it Adaptive Dissemination module:} This is responsible for determining
+{\it what} network state to distribute, and {\it to whom}, and {\it when}. It
+is also responsible for gathering network state encoded in incoming
+dissemination bundles and populating the KB appropriately, if one exists. For
+example, decisions such as whether to alter the content of a flooded
+network-state bundle before re-dissemination will be taken by this module. This
+module is also responsible for interacting with CLA (via the BPA) to track
+changes in the status of incoming/outgoing links and then capture these changes
+in the ``to-be-disseminated'' network state.  Even though the network state is
+stored in the KB, the dissemination logic may be implemented outside the KB for
+performance reasons, if necessary.
+\item {\it Policy module:} This will let users add and delete policies that may
+be stored in the KB, if one exists. Basic functions include interpretation of
+policy, enforcement of policy, and dispatching an event afterward. Performance
+reasons aside, ideally every bundle or network event in the SPINDLE system
+should be subjected to policy enforcement. This advocates a
+``trap-and-dispatch'' (or ``event-condition-action'') style design.  An
+alternative style is that of ``consultation.'' The policy module listens on
+a well known port for policy-enforcement requests
+and reacts only when asked.
+\item {\it Naming and Late binding module:} This module maintains and
+opportunistically shares name ontologies (or {\it schemes}, as referred to
+in~\cite{BP-ID}) between DTN nodes. This module is called upon to resolve rich
+intentional names to canonical endpoint identifiers of care-of nodes that are
+subsequently used by the Router module. This is also responsible for
+registration and dissemination or synchronization of Name KBs (in particular,
+intentional name to canonical name bindings stored within).
+\item {\it Content-based access module:} responsible for performing content
+caching/replication, distributed indexing, and content-addressable search.
+This may use several services from other DP modules, e.g., dissemination, late
+binding, external router.
+%{\it does this fall under Decision or App? Or maybe there should be no
+%distinction?}
+\end{enumerate}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Convergence Layer Adapter}
+\label{sec:cla}
+A Convergence layer adapter's function (as described in \cite{BP-ID}) is to
+send and receive bundles on behalf of the BPA. It achieves this by utilizing
+the services of the native protocol which is supported in one of the {\it
+underlying} networks that the node is homed on. A CLA thus {\it adapts} the
+packet/frame/signal transmission service provided in the underlying network to
+an abstract bundle transmission service that presents itself to the BPA.
+A CLA is responsible for maintaining information about DTN {\it links} (status,
+schedule, and possibly other QoS parameters) and discover them if possible.
+After discovering a DTN peer or monitoring the status of a link, the CLA is
+responsible for generating and posting events to the BPA about such facts.
+These facts then get relayed to the DP and may also be stored in the DS.
+%The CLA may also interact directly (IPC poke?) with some decision modules
+%(adaptive dissemination) for triggered dissemination under certain
+%circumstances.
+%{\it What is the service contract of send/receive with the BP? and how are the
+%CLA params presented to BP?}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Application/Middleware}
+\label{sec:am}
+The application agent (also referred to as the A/M module) uses the BP services
+to transmit and receive bundle payloads. This can act as a multiplexed DTN
+communication service to other non-DTN applications running on the node.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newpage
+\section{Interfaces}
+\label{sec:interfaces}
+In this section we describe the primitives for each of the four interfaces
+identified in Figure \ref{fig:componly}.
+The BPA implements the BPA interface that can be used by A/M and DP to send and
+receive bundles.
+The DP implements the DP interface that is accessed by the BPA to serve various
+decision points identified in the BP (such as routing, scheduling, name
+resolution, custody acceptance, and storage management).
+The DS implements the DS interface for storing bundles, bundle metadata,
+application registrations, connectivity information, and other system state.
+The DS interface can be accessed system-wide.  The CLA, for example, may access
+the DS interface for storing and retrieving connectivity information that is
+discovered or scheduled/specified.  The DP, for example, may access the DS
+interface for storing and retrieving information related to routing, naming,
+policy, and content caching/indexing.
+The CLA implements the CLA interface which is accessed by the BPA for
+bundle transport and link management.
+We briefly discuss at the end of this section the Inter-Component
+Communication Protocol (ICCP), the details of which will be described
+in a separate document.
+\subsection{Interface Conventions}
+We note that this is a ``semantic'' interface, that is, we expect it to be
+specifying the kinds of things that go across the interface and their meanings,
+not necessarily at a level necessary for implementation. We expect, though,
+that an implementation-level specification can be generated from this easily.
+All messages are assumed to be transparently reliably delivered.  This
+functionality may be provided by the inter-component communication protocol
+mentioned in Section \ref{sec:iccp}.
+All parameters are assumed to be ``required'' unless specifically
+noted to be ``optional'' (Opt).
+The interface messages are named in a top-down hierarchical
+fashion. For example, in the DP and CLA interfaces, at the highest
+level, there are four kinds of messages: Event, Request, Query,
+Report. At the next level, there are Link-specific and Bundle-specific
+messages, for each message type. At a further level, there is
+Created/Deleted, Transmitted/Received etc. which are
+the next level down.  This naming convention is intended for readability
+of the specification only. The implementation should adopt/retain the style
+most convenient to it.
+Query/Report messages consist of a set of ``paired'' messages---a Query
+message from a plugin to the BPA requesting certain information from the BPA
+and a report message (for that query) from the BPA to the plugin delivering the
+requested information, if possible.\footnote{Note that Query/Report messages are
+possible in the reverse direction as well, e.g., the BPA can send a Query
+message to the CLA or the DS and can expect a Report back.} Unlike the
+Request-Event messages which are only loosely tied, there is a tighter coupling
+between query and report; in particular, a report identifies which query is
+being responded to.
+\subsubsection{Links and Link Types} \label{sec:linktypes}
+A link in DTN2 is an association between two DTN endpoints. In other words it
+can be represented as a relation between two EIDs which is established over a
+certain convergence layer. A link possesses physical attributes such as
+datarate, (estimated) delay, error rate, loss rate etc. as well as other
+attributes including {\it type}, {\it state}, and other {\it flags}.  A
+measurement process (in the convergence layer adapter) can track and
+update the values of these attributes.
+\begin{table}
+\centering
+\begin{tabular}{|l|c|c|c||c|c|}
+\multicolumn{1}{c}{ } & \multicolumn{3}{c}{States} & \multicolumn{2}{c}{Flags} \\
+\hline
+Link Type & OPEN, BUSY & UNAVAILABLE & AVAILABLE & UNUSABLE & REACHABLE\footnotemark \\
+\hline
+Persistent (AlwaysOn)             & x & x &   & x &  \\
+\hline
+On-demand            & x & x & x & x &  \\
+\hline
+Opportunistic (Discovered)           & x & x &   & x & x\\
+\hline
+Scheduled            & x & x & x & x & x\\
+\hline
+Predicted            & x & x &   & x & x\\
+\hline
+\end{tabular}
+\caption{\label{table:link-tsf} Link types and possible states/flags.}
+\end{table}
+\footnotetext{Anticipated changes in the way bundle queuing is done for
+closed links might make the REACHABLE flag unnecessary. Thus this column
+is likely to disappear in future versions.}
+There are three link types implemented in DTN2: Persistent (AlwaysOn),
+On-demand, and Opportunistic (Discovered).\footnote{DTN2 uses AlwaysOn
+to denote what the DTN Architecture refers to as Persistent;
+``Discovered'' is influenced by the term
+``neighbor discovery'' commonly used in mobile ad hoc networking literature.}
+We extend the semantics of the Opportunistic link to support a wider range
+of neighbor discovery procedures.  We add the
+remaining two types discussed in the DTN Architecture: Scheduled, and
+Predicted.\footnote{
+There is a Scheduled link type in DTN2 but it is not fully implemented.}
+Not all link states and flags apply to all link types.\footnote{In
+particular, note that there is no discovery for on-demand links, and
+reachability is assumed.} Table \ref{table:link-tsf} depicts the various {\it
+types} of links and their corresponding range of {\it states} and {\it flags}
+that SHOULD be allowed in a DTN system. A detailed description of the various
+link states and flags can be found in Section \ref{sec:linkstates}.
+A Persistent (AlwaysOn) link is simply a static link, and it should always
+be open. The
+link is opened as soon as it is created. If the link closes for any reason the
+link becomes UNAVAILABLE and the BPA will attempt to reopen the link.
+An example of an AlwaysOn link would be a wired connection to a peer such as a
+T1.
+An On-demand link is assumed to be usable at any time as required, but is not
+opened until there are bundles to be sent over the link. When in this state,
+the link is AVAILABLE. Once the link is OPEN, if no bundle traffic is sent over
+an on-demand link for a while, the BPA will consider the link idle and
+automatically close the link, returning it to AVAILABLE. If the link closes for
+any reason other than being idle or being explicitly closed by an operator, the
+link becomes UNAVAILABLE and the BPA will periodically attempt to reopen the
+link. If the link is successfully reopened, the link state returns to OPEN. A
+dial-up connection over a modem would be represented by an
+on-demand link.
+An Opportunistic (Discovered) link is used with CLAs when there is no need
+to form a {\em point-to-point} connection for a link to be open.
+Discovered links are intended to capture characteristics of communications in
+multihop broadcast wireless networks (MANETs). Note that
+in a broadcast channel context there really is no ``link'' {\it per se,} but peers
+discover ability to communicate, which we declare as links.
+%We shall assume, as
+%is consistent with current state of art, that the CLA only discovers and
+%uses two-way communication possibilities.
+% XXX:  I think above sentence is too strong, I can imagine CLAs that
+% discover one-way communication possibilities through an out-of-band
+% mechanism; --krash
+One
+popular way of peer discovery is using a Hello protocol~\cite{OLSR}, where each
+node puts the set of nodes it can hear in the Hello, to help determine
+existence of bidirectional communications. Thus, receiving a hello is {\em not}
+an indication of bidirectional communications, although it is a necessary
+condition.
+Discovered links may be constrained, for example, in a ``only k links out
+of n'' situation.
+%As long as the CLA can transmit on any k---it need not transmit
+%simultaneously, but may transmit in round robin.
+If the situation calls for choosing a particular set of k links and
+locking out the other (for example, if a CLA knows which satellites it
+can associate with but can do so only k at a time), then these would
+not be Discovered links by definition (they are not for point to point
+links).\footnote{In a one-of-many link situation A $\rightarrow$
+one-of(B,C,D), the ``choosing'' is either ``hard'' (i.e., you cannot
+send on the other links for more than a threshold period of time), or
+``soft'' (you can do round robin).  With hard links the DP has to
+first choose the link to use (this may be part of topology control),
+say A $\rightarrow$ C. In this case, both A $\rightarrow$ D and A
+$\rightarrow$ B are both closed and unreachable. With soft links you
+can keep the links open and send on each within milliseconds of each
+other.  In the current semantics, Discovered links only cover the
+``soft type'', that is, when all can be kept open and reachable.}
+Thus, with discovered links, any time a peer is
+reachable, bundles can be transmitted or received without any additional
+action, so the link is always OPEN if it is REACHABLE. The link will remain
+open if the peer becomes
+unreachable temporarily, but if the peer remains unreachable for a long time,
+then the link can be considered closed, and the state will be changed to
+UNAVAILABLE (the closed state).
+Note that a special case of the Opportunistic link is implemented in DTN2
+which is subsumed by the more general semantics discussed above.  In the
+current implementation, links are created and opened when a previously
+unknown peer somehow connects to the node to open a link.  If it can be
+inferred from this connection that traffic can be sent from the node to this
+peer, an opportunistic link is created and opened so that bundles may be sent
+to the new peer. Once an opportunistic link is closed for any reason, it
+becomes UNAVAILABLE and will only be reopened if the peer opens the
+link again. An example of an opportunistic link is one created when a peer
+opens a TCP or dial-up connection to the node; the node now knows it can
+communicate with and send bundles to the peer that initiated the first
+connection, and represents this fact with an opportunistic link.
+Scheduled links can be thought of as an extension to on-demand links. When a
+scheduled link is created, it is set to AVAILABLE. This means the link is
+available to be opened.
+%Unlike on-demand though, the opening is not under any user's control but under
+%the control of the ``clock''. When the scheduled time comes, it moves
+%automatically into state OPENING. There it waits for a contactUpEvent just
+%like the on-demand link. When this event happens, it moves into OPEN.
+When the scheduled time comes, the BPA will open the link. (This adds a
+new requirement to the functionality of the BPA.)
+\typeout{XXX If this new requirement is hard, DP can track schedule and open
+at the right instant.} A
+scheduled link is expected to be reachable during the scheduled interval.  If
+the link is still scheduled to be open when it closes, it becomes UNAVAILABLE,
+and otherwise it becomes AVAILABLE until the next time the link is scheduled to
+be opened. If the link is UNAVAILABLE and the link is scheduled to be open,
+the BPA will try to reopen the link,
+like it does for UNAVAILABLE on-demand links, until the end of the scheduled
+opportunity. During the time the link is scheduled to be open, if the CLA can
+ascertain reachability, the REACHABLE flag can be used to provide extra
+information to the DP. A scheduled link would represent, for example,
+communications with a satellite which is overhead at regular intervals.
+A predicted link is similar to a discovered link. When created, it is
+UNAVAILABLE. A separate process (perhaps in the DP) computes the next time it
+expects the link to be REACHABLE. However,
+that is used for DP purposes only to make routing decisions, and the link is
+not opened automatically when the predicted time arrives. Instead, the
+discovery process
+%(hellos)
+is initiated shortly before the predicted time by the CLA.
+%When you hear back from the contact, a contactUpEvent forces the state into
+%OPEN. Then the OPEN to BUSY transition and the transitions to UNAVAILABLE are
+%as in discovered links.
+When the neighbor becomes reachable, the link becomes OPEN and then behaves
+like a discovered link: it is OPEN until the peer is unreachable for too long,
+at which point the link is closed and set to UNAVAILABLE. At the end of the
+predicted opportunity, discovery for the peer is discontinued. The difference
+between discovered and predicted links is that for predicted links we don't
+initiate discovery until the predicted time (or shortly before). For CLAs where
+the discovery process is continuous (e.g.\ MANETs), there is no functional
+difference in the CLA between predicted links and discovered links, but even in
+this case, the DP can make decisions based on whether a link has a predicted
+opportunity or not. A regularly observed UAV flyover would be described
+by a predicted link.
+\subsubsection{Link States and Flags} \label{sec:linkstates}
+The DP and CLA interfaces make use of four link states present in DTN2:
+UNAVAILABLE, AVAILABLE, OPEN, and BUSY.\footnote{DTN2 also has an OPENING state
+used for determining whether ContactDownEvent should be sent, but this state
+need not be used in the interface. The CLA posts EventLinkClosed and the BPA
+may need to keep track of on-demand links for which the RequestOpenLink message
+has been sent and EventLinkOpen has not been received yet, but in the external
+interface the link is simply not OPEN until the EventLinkOpen message has
+arrived.} The link can be in only one of these four states at a given time. Two
+additional states are added: UNUSABLE and REACHABLE. These two states are
+independent of the other four, so the link state should be considered a set of
+flags.
+The OPEN and BUSY \typeout{XXX We may want to revisit the idea of changing
+BUSY into a flag distinct from OPEN.} states signify that the
+link is open.  For links whose CLA requires a specific action to be done before
+communication can happen (e.g.\ dialout, set up a TCP connection, initiate a
+route discovery on a MANET to a remote node, etc.), these states mean that
+whatever needs to be done has been done and bundles can be sent on the link.
+For Discovered links, these states indicate that the peer is or very recently
+was reachable.  If the link is BUSY, the CLA is applying back-pressure to the
+BPA by requesting that the BPA not try to send any more bundles over the
+link.\footnote{In DTN2 this is set when the per-CLA bundle queue gets too long
+or as part of LinkAttributeChange Event. The DP would then have to perform a
+query to determine whether this has been set.}
+Closed links are either UNAVAILABLE or AVAILABLE. The difference between these
+two states generally pertains to whether or not the BPA must automatically try
+to reopen the link. The state is AVAILABLE is when the link is {\it closed},
+but {\it openable}.  UNAVAILABLE is when the link cannot be opened for some
+reason. The BPA will periodically attempt to reopen UNAVAILABLE links of the
+following types: AlwaysOn, On-demand, and Scheduled. For other link types,
+there is only one kind of closed state, so those links are always UNAVAILABLE
+when closed.
+The availability concept has more to do with the {\it ability} to open a link
+rather than policy directives such as ``I think this link is dangerous
+(eavesdroppers in there), so you SHOULD not open it even if it can be''. The
+latter concept is captured by {\it usability}. A link can be marked with the
+UNUSABLE flag based on policy. This flag can be set by the DP. If a link is
+marked UNUSABLE, the BPA and DP should not attempt to open it.
+Usability is different from availability in that it is not an
+``inability'' but a ``forbidding''. Note that the peer endpoint of an
+UNUSABLE link can still open a link and send bundles to the node; those
+bundles should be accepted and processed by the node because the UNUSABLE
+flag only disallows the local node from opening the link and sending bundles
+over it.
+The reachability of a link pertains to the ability to actually communicate over
+the link and talk to the peer. The DTN neighbor discovery process, if enabled,
+will use the underlay network to determine whether other DTN nodes are
+reachable. Nodes should provide their canonical EIDs as part of the discovery
+process so that links may be created and used in future decisions.  When the
+CLA ascertains bidirectional communications with some adequate quality (and
+keeps ascertaining it), the link will be marked REACHABLE. If discovery notices
+that a neighbor has become unreachable, the REACHABLE flag will be cleared.
+The REACHABLE flag is meant to express the communication ability currently
+present in the underlay network and is used to inform decisions made by the DP.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% The four interface sections
+\input{ds-interface}
+\input{decision-interface}
+\input{cla-interface}
+\input{bpa-interface}
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\subsection{Inter-Component Communication Protocol} \label{sec:iccp}
+Communications between the BPA and other components will use messages
+formatted using XML.  We currently plan to build upon and extend the
+external router interface protocol developed by MITRE for this purpose.
+Some extensions to the support the Data Store interface were described in
+Section~\ref{sec:ds-iccp-impl}.  For example, the MITRE solution
+uses UDP multicast, but we believe that it will be beneficial to
+support TCP as well.
+Details of this protocol will be described in a separate document.
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\newpage
+\begin{thebibliography}{99}
+%\bibitem{MaxProp} J. Burgess, B. Gallagher, D. Jensen, and B. L. Levine,
+%``MaxProp: Routing for Vehicle-Based Disruption Tolerant Networks,'' {\em Proc.
+%IEEE Infocom 2006.}
+\bibitem{MITRE-IF} J. Bush and R. Durst, ``DTN External Router Interface,''
+{\em Presentation at DARPA DTN Phase 2 Kickoff}, August 2006.
+\bibitem{DTN2} M. Demmer, ``DTN2: DTNRG Reference Implementation''. Available
+from {\tt http://www.dtnrg.org}
+\bibitem{Flora2} FLORA-2: An Object-Oriented Knowledge Base Language.
+{\tt http://flora.sourceforge.net}
+\bibitem{MJ} J. Mikkelson and C. E. Jones, ``Bundle Protocol Agent Functional
+Requirements,'' October 2006 (available upon request).
+\bibitem{OLSR} T. Clausen, Ed. and P. Jacquet Ed., ``Optimized Link State
+Routing Protocol (OLSR),'' {\tt http://ietf.org/rfc/rfc3626.txt}
+\bibitem{BP-ID} K. Scott and S. Burleigh, ``Bundle Protocol Specification,''
+IRTF DTNRG Internet Draft revision 06, August 2006.
+\bibitem{BSP-ID} S. Symington, S. Farrell, and H. Weiss, ``Bundle Security
+Protocol Specification,'' IRTF DTNRG Internet Draft revision 01, March 2006.
+\bibitem{XSB} XSB: A Logic Programming and Deductive Database system.
+{\tt http://xsb.sourceforge.net}
+\end{thebibliography}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\end{document}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%