diff -r 000000000000 -r 2b3e5ec03512 doc/plugin-architecture/cla-interface.tex --- /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 +}