--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/plugin-architecture/cla-interface.tex Thu Apr 21 14:57:45 2011 +0100
@@ -0,0 +1,860 @@
+\subsection{Convergence Layer Adapter Interface}
+
+A Convergence Layer Adapter is responsible for communication with the underlay
+networks available to the BPA. The CLA provides transmission and reception of
+bundles, and responds to requests to open or close links to neighbor endpoints.
+Where possible, the CLA is responsible for performing DTN neighbor discovery
+and measuring link characteristics.
+
+The CLA interface described here is based on the DTN2 ConvergenceLayer, with
+modifications to create an External CLA interface similar in concept to the
+External Decision Plane (Router) interface. Additional functionality is
+designed to support discovery and the DP.
+
+Each CLA provides the functionality for use of a particular kind of underlay
+network. Multiple ``interfaces'' may be created by each CLA; each interface
+refers to a single underlay network available to the node. Interfaces are
+responsible for receiving bundles from peer nodes, and performing neighbor
+discovery. Discovery is performed separately on each interface.
+
+A potential or existing connection to another endpoint is represented by a
+link. As in DTN2, a given link is associated with a single CLA. If the node
+can reach a given endpoint via more than one CLA, then there will be a link
+for each. Links will have CLA-specific parameters providing the necessary
+information for opening the link, such as the WEP key for 802.11 or the IP
+address and port for the TCP and UDP CLAs.
+
+It is possible for a single CLA to have more than one link with the same
+destination EID. This would generally only be necessary for situations where
+there are different link parameters, and certain bundles should be sent with
+one set of parameters or another. An example of such a situation is a TCP
+CLA on a system with two hardware interfaces, eth0 and eth1. If which
+hardware interface the bundle is sent from is irrelevant, than only one link
+to a given EID is needed and the CLA will use the default hardware
+interface. But if the default route for eth1 is a router that tunnels
+traffic in IPsec and the default route for eth0 does not tunnel but has much
+better bandwidth, and we wanted to be able to tunnel sensitive bundles and
+send other bundles on the higher-bandwidth link, two links would be
+needed. An additional link parameter, the IP address to send from, would
+then constrain each link to eth1 or eth0, so that bundles sent on that link
+are transmitted correctly.
+
+Link parameters may constrain how the CLA transmits bundles in ways other
+than a hardware interface. For example, the link parameters may require a
+CLA to use only a particular 802.11 SSID. Each CLA provides a set of link
+parameters specific to it, and can use them to constrain transmission of
+bundles, or provide a default where parameters are optional (such as the IP
+address to send from).
+
+\subsubsection{Parameter Types}
+
+The CLA interface uses some of the same parameter types as the DP
+interface. These include:
+
+\begin{verbatim}
+
+GBOF ID := [sourceEID, timestamp, isFragment,
+ fragment-length, frgmtOffset]
+Link ID := Unique string identifying a link
+Link Type := PERSISTENT, ON_DEMAND, SCHEDULED, PREDICTED,
+ or OPPORTUNISTIC
+Link Attributes := [type, state, peerEID, is-reachable, is-usable,
+ howReliable, howAvailable, reactive-frag-enabled,
+ underlayAddress, clName,
+ all-CLA-specific-link-attributes]
+Link Config Parameters := A set of the following attributes:
+ is-usable, reactive-frag-enabled, underlayAddress,
+ configurable-CLA-specific-link-attributes
+ContactAttributes := [startTime, duration, bps, latency, pktLossProb,
+ LinkAttributes]
+
+
+\end{verbatim}
+
+Additional parameters include:
+
+\begin{verbatim}
+
+CLA Parameters := A list of (key, value) pairs
+Interface Parameters := A list of (key, value) pairs
+Interface ID := Unique string identifying an interface
+Link State := OPEN, AVAILABLE, UNAVAILABLE, or BUSY
+Bundle Location := How to get the bundle to send or where an incoming
+ bundle was placed (from the DS or elsewhere)
+
+\end{verbatim}
+
+Interfaces and links have both parameters and attributes associated with
+them. Parameters are used to control behavior, such as whether to perform
+fragmentation or what encryption key should be used, while attributes
+describe state, such as latency or error rate. Note that link attributes
+also include the REACHABLE and UNUSABLE flags.
+
+\subsubsection{Request Messages}
+
+Requests to the CLA are made by the BPA. Some requests may originate from
+the DP and are then passed to the CLA by the BPA.\\[1em]
+
+\method{RequestSetCLAParams(CLAParameters)}
+{
+\metP
+ {\em CLA Parameters}: A list of (key, value) pairs.
+
+\metD
+ This request sets the CLA parameters. These parameters apply to the
+ behavior of the CLA as a whole, not individual interfaces or links. The
+ key identifies the name of the parameter and the value is what the CLA is
+ supposed to set that parameter to. If any of the parameters is invalid,
+ no parameters are set.
+
+ After a CLA has been added (see RequestAddCLA), the BPA should use this
+ message to tell the CLA the canonical EID of this node (for use in
+ discovery) and where to store incoming bundles. The CLA should store
+ bundles as it receives them in the manner specified by this BPA-provided
+ Bundle Location so that the BPA can read them upon receiving
+ EventBundleReceived messages.
+
+ For basic topology management in the CLA, the CLA should at least support a
+ configuration parameter that instructs it to automatically create a link
+ and mark it as REACHABLE and AVAILABLE when a new EID is
+ discovered. Otherwise new links must be created by RequestAddLink.
+
+ CLAs may support more sophisticated topology management functionality,
+ which would be configured/enabled via this request as well. For example,
+ if configured, the CLA would delete discovered links that have been
+ UNREACHABLE for longer than a certain time, based on the presumption that
+ the endpoint will not be reachable again any time soon.
+
+\metR
+ EventCLAParamsSet
+}
+
+\method{RequestSetInterfaceDefaults(InterfaceParameters)}
+{
+\metP
+ {\em Interface Parameters}: A list of (key, value) pairs. The set of key
+ types is CLA-dependent.
+
+\metD
+ This message sets default values for interface parameters. These values are
+ used when a new interface is created, unless they are overridden at
+ creation time by parameters in RequestAddInterface. Changes to the default
+ parameters do not change any preexisting interfaces. If any of the
+ parameters is invalid, no parameters are set.
+
+\metR
+ RequestAddInterface\\
+ RequestReconfigureInterface
+}
+
+\method{RequestSetLinkDefaults(LinkConfigParameters)}
+{
+\metP
+ {\em Link Config Parameters}: A list of link attributes for which to set
+ defaults.
+%The set of attributes is CLA-dependent.
+
+\metD
+ This message sets default values for link parameters. These values are
+ used when a new link is created, unless overridden at creation time by
+ parameters in RequestAddLink.\footnote{Some parameters may be determined
+ by discovery or a measurement process implemented within the CLA.} Changes
+ to the default parameters do not change any
+ preexisting links. If any of the parameters is invalid, no parameters are
+ set.
+
+\metR
+ RequestAddLink\\
+ RequestReconfigureLink
+}
+
+\method{RequestAddInterface(InterfaceID, [InterfaceParameters])}
+{
+\metP
+ {\em Interface ID}: Identifies the interface to be added.\\
+ {\em Interface Parameters (Opt)}: A list of (key, value) pairs. The set
+ of key types is CLA-dependent.
+
+\metD
+ This requests that the CLA add an interface with the provided name. Any
+ default parameters for the interface will be used unless overridden by
+ the InterfaceParameters. Bundles sent from another node cannot be
+ received, nor can discovery be performed, until the interface is up.
+ If any of the parameters is invalid, the interface is not added.
+
+\metR
+ EventInterfaceAdded\\
+ RequestReconfigureInterface\\
+ RequestSetInterfaceDefaults
+}
+
+\method{RequestReconfigureInterface(InterfaceID, [InterfaceParameters, UpOrDown, DiscoveryOrNot])}
+{
+\metP
+ {\em Interface ID}: Identifies the interface.\\
+ {\em Interface Parameters (Opt)}: A list of (key, value) pairs. The set
+ of key types is CLA-dependent.\\
+ {\em Up Or Down (Opt)}: This field specifies whether the interface should
+ be brought down or up.\\
+ {\em Discovery or Not (Opt)}: This field specifies whether or not DTN
+ neighbor discovery should be performed on the interface.
+
+\metD
+ This request allows the specified interface to be reconfigured. If
+ provided, the Interface Parameters are the same as those set in
+ RequestSetInterfaceDefaults and RequestAddInterface; the changes are to be
+ applied immediately (if it makes sense). Interfaces are brought up or
+ down with the Up Or Down field. An interface starts down when added, and
+ cannot perform discovery until it is brought up. The Discovery Or Not
+ field allows changing whether discovery is enabled; an interface may be
+ up without discovery being enabled. If any of the parameters is invalid, no
+ parameters are changed.
+
+\metR
+ EventInterfaceReconfigured
+}
+
+\method{RequestDeleteInterface(InterfaceID)}
+{
+\metP
+ {\em Interface ID}: Identifies the interface to be deleted.
+
+\metD
+ This message requests that the interface itself brought down and
+ deleted. Existing links that happen to use the same underlay network
+ as the interface are not affected. However, depending on how the CLA
+ works, such links may no longer be able to send traffic and would
+ eventually become UNAVAILABLE (if applicable).
+
+\metR
+ None
+}
+
+\method{RequestAddLink(LinkID, LinkType, PeerEID, [LinkConfigParameters])}
+{
+\metP
+ {\em Link ID}: Identifies the link to be created.\\
+ {\em Link Type}: The type of link being added.\\
+ {\em Peer EID}: The endpoint ID for the peer of the link being added.\\
+ {\em Link Config Parameters (Opt)}: Describes the link to add.
+% The set of attributes is CLA-dependent.
+
+\metD
+ This message requests that the CLA add a link. The link is not to be
+ opened automatically by the CLA when added.
+%\footnote{Unless it's AlwaysOn?}
+The link parameters can include the link's UNUSABLE flag.
+% The underlay address of the peer (called ``nextHop'' in DTN2), if
+% provided, is also a link parameter.
+ If any of the parameters is invalid, the link is not added.
+
+\metR
+ EventLinkCreated
+}
+
+\method{RequestReconfigureLink(LinkID, LinkConfigParameters)}
+{
+\metP
+ {\em Link ID}: Identifies the link to be reconfigured.\\
+ {\em Link Config Parameters}: The new set of attributes.
+% The set of attributes is CLA-dependent.\\
+
+\metD
+ Link parameters may be changed after creation time with this
+ request. Changes are applied immediately where it makes sense, even if the
+ link is open. This request is also used to set or clear the link's
+ UNUSABLE flag. If any of the parameters is invalid, no parameters are
+ changed.
+
+\metR
+ RequestAddLink
+}
+
+\method{RequestDeleteLink(LinkID)}
+{
+\metP
+ {\em Link ID}: Identifies the link to be deleted.
+
+\metD
+ This is a request to close the link if it is open and then delete it.
+
+ Note that if the CLA is performing neighbor discovery, and has been
+ instructed to create links when peers are found, the CLA may recreate
+ this link if it is re-discovered.
+
+\metR
+ EventLinkDeleted
+}
+
+\method{RequestOpenLink(LinkID)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-RequestMessages}).
+
+\metR
+ RequestCloseLink
+}
+
+\method{RequestCloseLink(LinkID)}
+{
+\metP
+ {\em Link ID}: Identifies the link that the DP wants closed.
+
+\metD
+ This message requests that the CLA close the link if it is open.
+
+\metR
+ RequestOpenLink
+}
+
+\method{RequestSendBundle(GBOF-ID, LinkID, BundleLocation)}
+{
+\metP
+ {\em GBOF ID}: Identifies the bundle that should be sent.\\
+ {\em Link ID}: Identifies the link over which the bundle should be sent.\\
+ {\em Bundle Location}: Specifies from where the CLA should retrieve the
+ bundle to be sent.
+
+\metD
+ This is a request to send the bundle. There is not a parameter for bundle
+ blocks; the assembly of the bundle blocks into a complete bundle must
+ be performed by the BPA. The location of this complete bundle is specified
+ by the Bundle Location field.
+
+\metR
+ EventBundleTransmitted\\
+ EventBundleTransmitFailed\\
+ RequestCancelBundleSend
+}
+
+\method{RequestCancelBundleSend(GBOF-ID, LinkID)}
+{
+\metP
+ {\em GBOF-ID}: Identifies the bundle whose sending needs to be canceled.\\
+ {\em Link ID}: Identifies the link for which the bundle sending must be
+ canceled.
+
+\metD
+ This is a request that the CLA remove the specified bundle from all
+ transmission queues if possible. The CLA will post EventBundleSendCancelled
+ if the cancellation succeeds. If the CLA is currently transmitting the
+ specified bundle, several options may be available. It may still be
+ possible for the CLA to cancel the entire bundle transmission, in which
+ case the cancellation succeeds. If it is not possible to cancel the
+ transmission, the CLA could continue to transmit the bundle, or create a
+ reactive fragment. In these cases, the EventBundleTransmitted message would
+ be sent as normal.
+
+\metR
+ EventBundleSendCancelled\\
+ RequestSendBundle
+}
+
+\subsubsection{Event Messages}
+
+The CLA sends event messages to the BPA.\\[1em]
+
+\method{EventCLAParamsSet()}
+{
+\metP
+ None
+
+\metD
+ This message is sent when a RequestSetCLAParams message has been
+ successfully processed.
+
+\metR
+ RequestSetCLAParams
+}
+
+\method{EventInterfaceAdded(InterfaceID)}
+{
+\metP
+ {\em Interface ID}: Identifies the interface that was added.
+
+\metD
+ This event message is sent when an interface has been successfully added
+ by the CLA. The interface will not be up until it has been brought up
+ by a RequestReconfigureInterface message.
+
+\metR
+ RequestAddInterface\\
+ RequestReconfigureInterface
+}
+
+\method{EventInterfaceReconfigured(InterfaceID)}
+{
+\metP
+ {\em Interface ID}: Identifies the interface that was reconfigured.
+
+\metD
+ This event is sent after reconfiguring an interface in response to
+ the RequestReconfigureInterface message.
+
+\metR
+ RequestReconfigureInterface
+}
+
+\method{EventEIDReachable(InterfaceID, PeerEID)}
+{
+\metP
+ {\em Interface ID}: Identifies the interface from which the peer is
+ reachable.\\
+ {\em Peer EID}: The endpoint ID of the DTN node that can be reached from
+ this interface.
+
+\metD
+ This is a ``pass-through'' event for the BPA; the BPA is expected to
+ pass the message to the DP, and need not take any other action.
+
+ This event message is used only if the CLA has not been configured to
+ automatically create a link when a new neighbor is discovered. (If the CLA
+ has been configured to automatically create a link, when the link is
+ created, reachability is indicated to the DP by the LinkAttributes in the
+ EventLinkCreated message.)
+ When the CLA is not configured to automatically create
+ new links, the EventEIDReachable message is sent to inform the DP that
+ neighbor discovery has determined that a new peer EID is reachable, so that
+ the DP can determine whether to create a corresponding link or not.
+
+\metR
+ RequestAddLink
+}
+
+\method{EventLinkCreated(LinkID, LinkAttributes, Reason)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+\metR
+ RequestAddLink
+}
+
+\method{EventLinkDeleted(LinkID, LinkAttributes, Reason)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+\metR
+ RequestDeleteLink
+}
+
+\method{EventLinkOpened(LinkID, ContactAttributes)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+\metR
+ RequestOpenLink\\
+ EventLinkClosed
+}
+
+\method{EventLinkClosed(LinkID, ContactAttributes)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+\metR
+ RequestCloseLink\\
+ EventLinkOpened
+}
+
+\method{EventLinkAttributeChange(LinkID, LinkAttributes, Reason)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+ This is a ``pass-through'' event for the BPA; the BPA is expected to
+ pass the message to the DP, and need not take any other action.
+
+\metR
+ EventContactAttributeChange
+}
+
+\method{EventContactAttributeChange(LinkID, ContactAttributes, Reason)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-EventMessages}).
+
+ This is a ``pass-through'' event for the BPA; the BPA is expected to
+ pass the message to the DP, and need not take any other action.
+
+\metR
+ EventLinkAttributeChange
+}
+
+The following event messages inform the BPA that the CLA has added or changed
+the state of a link. In response, the BPA must update any state information it
+maintains for links, by either adding a link or changing the state of an
+existing one. The CLA has already performed the action so the BPA does not need
+to send a request to the CLA to effect the change.\\[1em]
+
+\method{EventLinkStateChange(LinkID, LinkState, Reason)}
+{
+\metP
+ {\em Link ID}: Identifies the link changing state.\\
+ {\em Link State}: The state the link has changed to.\\
+ {\em Reason}: A reason for the change.
+
+\metD
+ When sent by the CLA, this event informs the BPA of a change in the link
+ state based on some knowledge available to the CLA. The BPA should
+ update its own idea of the link state accordingly. The EventLinkOpened and
+ EventLinkClosed messages sent by the CLA set a link's OPEN state. The CLA
+ will send the EventLinkStateChange message for other state changes.
+
+ The CLA will set a link to BUSY when the queue has grown too long and will
+ return the link to OPEN when bundles can be sent again. A problem with
+ this approach must be resolved: a large number of bundle send request
+ messages could be sent between the time the CLA requests the link be
+ changed to BUSY and the time the BPA receives the message and changes
+ the link state. The CLA may not be able to honor these send requests
+ received after requesting the change to BUSY.
+
+ Note: This translates to the current LinkStateChangeRequest event in DTN2,
+ but the CLA has already changed its state so the BPA should only take
+ actions regarding its own link state.
+
+\metR
+ EventLinkOpened\\
+ EventLinkClosed
+}
+
+\method{EventAddReachableLink(LinkID, PeerEID, [LinkConfigParameters])}
+{
+\metP
+ {\em Link ID}: Identifies the link to be created.\\
+ {\em Peer EID}: The endpoint ID for the peer of the link being added.\\
+ {\em Link Parameters (Opt)}: Link attributes that may be set at link
+ creation time, i.e.\ the parameters available for RequestAddLink.
+
+\metD
+ If the CLA is configured to create links when discovery determines a new
+ neighbor is reachable, the CLA must tell the BPA to create the link, so
+ that the BPA can set up the state it keeps for links. This request tells
+ the BPA to create an OPPORTUNISTIC link, and set the link to AVAILABLE.
+ The BPA does not need to send a RequestAddLink message in response, because
+ the CLA has already created the link. The CLA will next send an
+ EventLinkCreated message to inform the DP and BPA of the creation and
+ reachability of the link.
+
+\metR
+ EventLinkCreated\\
+ RequestAddLink
+}
+
+The following events are directly related to bundles.\\[1em]
+
+\method{EventBundleTransmitted(GBOF-ID, LinkID, TotalBytesSent, TotalBytesSentReliably)}
+{
+\metP
+ % copied from DP
+ {\em GBOF ID}: Identifies the bundle or fragment that was transmitted.\\
+ {\em Link ID}: Identifies the link over which it was transmitted.\\
+ {\em Total bytes sent}: Number of bytes of data (including headers)
+ transmitted.\\
+ {\em Total bytes sent reliably}: Number of bytes of data (including
+ headers) sent reliably. This could be different from total bytes sent
+ if there were no ACKs received for some part of the data.
+
+\metD
+ This event message is sent when all or part of a bundle has been
+ transmitted. If the ``total bytes sent'' is less than the payload plus
+ header size of the bundle, the bundle has been reactively fragmented. This
+ can happen if the link is closed during transmission of the bundle. A
+ link parameter controls whether the CLA will attempt to perform reactive
+ fragmentation. If the CLA provides a means for the receiving node to
+ acknowledge receipt of data, ``total bytes sent reliably'' will specify how
+ many of the ``total bytes sent'' were acknowledged.
+
+ If a bundle has been partially transmitted but reactive fragmentation is
+ not performed, EventBundleTransmitFailed will be sent instead. If the
+ bundle send is canceled before any portion of it has been sent, the
+ EventBundleSendCancelled message is sent instead.
+
+\metR
+ EventBundleTransmitFailed\\
+ EventBundleSendCancelled\\
+ RequestSendBundle
+}
+
+\method{EventBundleSendCancelled(GBOF-ID, LinkID)}
+{
+\metP
+ {\em GBOF ID}: Identifies the bundle whose sending was canceled.\\
+ {\em Link ID}: Identifies the link for which the bundle send was
+ canceled.
+
+\metD
+ This message is sent when a bundle that was previously requested to be
+ sent has been successfully canceled by a RequestCancelBundleSend
+ message.
+
+\metR
+ RequestCancelBundleSend
+}
+
+\method{EventBundleReceiveStarted(BundleLocation, [PrevHopEID])}
+{
+\metP
+ {\em Bundle Location}: Specifies where the CLA will store the bundle.\\
+ {\em Previous Hop EID}: The node from which this bundle is being
+ received, when available.
+
+\metD
+ This message is sent by the CLA when it begins to receive a bundle. If
+ the CLA provides a means of acknowledging receipt of data to the peer
+ (such as in the TCP CL), this message must be sent before the CLA
+ acknowledges any of the bundle data. If there is no means of
+ acknowledging receipt of data (such as with the UDP CL), the CLA is not
+ required to send this message to the BPA.
+
+ The motivation for this message is to handle cases where the external
+ CLA crashes or is somehow unable to send messages to the BPA between
+ acknowledging data to the peer and sending the EventBundleReceived
+ message to the BPA. If the CLA acks data and then cannot post the
+ BundleReceivedEvent, the peer transmitting the bundle may assume the
+ bundle is transmitted (or perform reactive fragmentation), yet the
+ bundle has not actually arrived at the BPA. This could result in the
+ bundle or fragment being lost.
+
+ If the BPA finds that the CLA has died, it should collect and process
+ all bundles for which EventBundleReceiveStarted was sent but not
+ EventBundleReceived.
+
+\metR
+ EventBundleReceived
+}
+
+\method{EventBundleReceived(BundleLocation, BytesReceived, [PrevHopEID])}
+{
+\metP
+ {\em Bundle Location}: Specifies where the CLA stored the bundle.\\
+ {\em Bytes Received}: Total number of bytes in the bundle (including
+ headers).\\
+ {\em Previous Hop EID (Opt)}: The node from which this bundle was
+ received, when available.
+
+\metD
+ This message is sent when the CLA has completed receiving a bundle. If the
+ ``bytes received'' is less than the bundle length, then the bundle has been
+ reactively fragmented. This can happen when the link is closed during
+ reception of the bundle. A link parameter controls whether the CLA will
+ attempt to perform reactive fragmentation.
+
+\metR
+ EventBundleReceiveStarted
+}
+
+\subsubsection{CLA Registration}
+
+These two requests are used by the CLA at startup and shutdown.
+They are sent from the CLA to the BPA. After connecting to the BPA, the CLA
+sends a RequestAddCLA message to inform the BPA that the CLA has been created
+and is available to handle future requests from the BPA. If the CLA is shutting
+down, it informs the BPA of this fact with a RequestDeleteCLA message.\\[1em]
+
+\method{RequestAddCLA(CLAName)}
+{
+\metP
+ {\em CLA Name}: Identifies the CLA that is requesting to be added.
+
+\metD
+ While starting up, the CLA should send this request after connecting to the
+ BPA. This informs the BPA that the CLA is ready for future requests.
+
+\metR
+ RequestDeleteCLA
+}
+
+\method{RequestDeleteCLA(CLAName)}
+{
+\metP
+ {\em CLA Name}: Identifies the CLA that is being deleted.
+
+\metD
+ When shutting down the CLA sends this request message to inform the BPA
+ that the CLA is shutting down. The BPA is then expected to take correct
+ actions for a CLA going away.
+
+ It is possible for the CLA to die without sending this request, so the BPA
+ should detect this situation and take the correct actions for deleting a
+ CLA.
+
+\metR
+ RequestAddCLA
+}
+
+\subsubsection{Query/Report Messages}
+
+Query messages are sent to the CLA by the BPA. Some queries may originate at
+the DP and simply be passed to the CLA by the BPA. The corresponding Report
+messages are sent from the CLA to the BPA.\\[1em]
+
+\method{QueryBundleQueued(QueryID, GBOF-ID, LinkID)}
+{
+\metP
+ {\em QueryID}: Identifies the query (a handle) to tie the report.\\
+ {\em GBOF-ID}: Identifies the bundle being queried.\\
+ {\em Link ID}: Identifies the link being queried.
+
+\metD
+ This query is for determining whether or not a bundle is currently on
+ the send queue of the given link. A unique query id is passed and a
+ report message containing the query id is awaited. The report contains
+ the requested information.
+
+\metR
+ ReportBundleQueued
+}
+
+\method{ReportBundleQueued(QueryID, YesOrNo)}
+{
+\metP
+ {\em QueryID}: Identifies which query is being responded to.\\
+ {\em YesOrNo}: Yes if the bundle is on the link's send queue.
+
+\metD
+ This message is a response to a query and reports whether or not the
+ specified bundle is currently queued to be transmitted on the specified
+ link. The query id ties the report to the query.
+
+\metR
+ QueryBundleQueued
+}
+
+\method{QueryEIDReachable(QueryID, InterfaceID, PeerEID)}
+{
+\metP
+ {\em QueryID}: Identifies the query (a handle) to tie the report.\\
+ {\em Interface ID}: Identifies the interface being queried.\\
+ {\em Peer EID}: Identifies the endpoint ID being queried.
+
+\metD
+ This query is for determining whether or not an endpoint ID is reachable
+ from the given interface. A unique query id is passed and a
+ report message containing the query id is awaited. The report contains
+ the requested information.
+
+\metR
+ ReportEIDReachable
+}
+
+\method{ReportEIDReachable(QueryID, YesOrNo)}
+{
+\metP
+ {\em QueryID}: Identifies which query is being responded to.\\
+ {\em YesOrNo}: Yes if the peer endpoint ID is reachable from the queried
+ interface.
+
+\metD
+ This message is a response to a query and reports whether or not the
+ specified endpoint ID is currently reachable from the specified interface.
+ The query id ties the report to the query.
+
+\metR
+ QueryEIDReachable
+}
+
+\method{QueryLinkAttributes(QueryID, LinkID, QueryParams)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-QueryReportMessages}).
+% COMMENT: This would query measured link characteristics. Presumably there
+% is a well-defined set of characteristics such as bandwidth and RTT,
+% with additional CLA-specific characteristics available. This could be
+% allowed to query the parameters set at link creation time as well. It
+% could also query the link state (open or closed).
+
+\metR
+ ReportLinkAttributes
+}
+
+\method{ReportLinkAttributes(QueryID, ReportParams)}
+{
+\metD
+ See DP interface (section~\ref{sec:DP-QueryReportMessages}).
+
+\metR
+ QueryLinkAttributes
+}
+
+\method{QueryInterfaceAttributes(QueryID, InterfaceID, QueryParams)}
+{
+\metP
+ % copied from DP
+ {\em QueryID}: Identifies the query (a handle) to tie the report.\\
+ {\em Interface ID}: Identifies the interface being queried.\\
+ {\em QueryParams}: A list of keys. The key identifies which information
+ object is asked for. A list of key types is defined somewhere.
+
+\metD
+ % copied from DP
+ This query is for getting the value of any subset of a number of
+ pre-defined interface attributes. A unique query id is passed and a
+ report message containing the query id is awaited. The report contains
+ the requested information (key,value) pairs (see below).
+
+\metR
+ ReportInterfaceAttributes
+}
+
+\method{ReportInterfaceAttributes(QueryID, ReportParams)}
+{
+\metP
+ % copied from DP
+ {\em QueryID}: Identifies which query is being responded to.\\
+ {\em ReportParams}: A list of (key, value) pairs.
+
+\metD
+ % copied from DP
+ This message is a response to a query and reports the latest value
+ of the interface attributes that were queried for. The query id ties
+ the report to the query. The ReportParams contains (key, value)
+ pairs, where each key is taken from the list of keys supplied with
+ the corresponding query, and the value is the value of whatever is
+ requested for by the key.
+
+\metR
+ QueryInterfaceAttributes
+}
+
+\method{QueryCLAParameters(QueryID, QueryParams)}
+{
+\metP
+ % copied from DP
+ {\em QueryID}: Identifies the query (a handle) to tie the report.\\
+ {\em Interface ID}: Identifies the interface being queried.\\
+ {\em QueryParams}: A list of keys. The key identifies which information
+ object is asked for. A list of key types is defined somewhere.
+
+\metD
+ % copied from DP
+ This query is for getting the value of any subset of a number of
+ pre-defined CLA parameters. A unique query id is passed and a
+ report message containing the query id is awaited. The report contains
+ the requested information (key,value) pairs (see below).
+
+\metR
+ ReportCLAParameters
+}
+
+\method{ReportCLAParameters(QueryID, ReportParams)}
+{
+\metP
+ % copied from DP
+ {\em QueryID}: Identifies which query is being responded to.\\
+ {\em ReportParams}: A list of (key, value) pairs.
+
+\metD
+ % copied from DP
+ This message is a response to a query and reports the latest value
+ of the CLA parameters that were queried for. The query id ties
+ the report to the query. The ReportParams contains (key, value)
+ pairs, where each key is taken from the list of keys supplied with
+ the corresponding query, and the value is the value of whatever is
+ requested for by the key.
+
+\metR
+ QueryCLAParameters
+}