Interoperability is a major goal of the IDS. Therefore, the interoperability between IDS Connectors and other components is of high importance. The IDS Communication Guide shall provide the required data structure and the interaction sequences to be realized for interoperability and to be used for interoperability testing.
The Communication Guide is organized into a modular and composable structure.
Joint understanding of the terms in-band and out-of-band, as well as the control plane and data plane:
Commonalities: Both term pairs…
- represent the split of a previously joint, combined flow of information into two separate parts
- have a background in technology
- have some overlap, but put different emphasis
- origins: selection of radio frequencies (“bands”) for primary/secondary communication
- the split is motivated mainly by isolation & break-out reasons
in-band: the samefrequency,connectionormeans of communicationis used for all transfersout-of-band: for a selected subset of communication, a different, dedicated band is selected- example: main process is using HTTP, user identity verification subprocess uses SMTP (email)
- origins: in a networking device…
- the
control planeis optimized for customizability and security. it controls the data plane. - the
data planeis optimized for speed, throughput and bandwidth. it handles the data payloads. - the split is motivated mainly by “separation of concerns”
control plane: controls what happens on the data planedata plane: agnostic of control logic, only used for payload transfers
The foundation package contains elements that commonly used. This includes standards that are used as foundation for the Communication Guide.
The Foundational Standards list.
The common information model that is used in every other package. This shall include a base model containing the entities of a data space and their relation.
(find the source file of the image above here)
The realization bases on DCAT for the Data Products and ODRL for Contract Policies.
The IDS-Information Model is here.
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
part of the control plane
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
part of the data plane. How data is exchanged with focus on communication and not on how the data plane is built.
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
The catalog in the IDS is a collection of Self-Descriptions, either of IDS Connectors or IDS Resources published by such IDS Connectors. The Self-Descriptions are the first-class-citizen in the catalogs, therefore all messages have the Self-Descriptions as their target, instead of the catalogs containing them.
The messages, expected content, and the error behaviour are described in the Functions and Correlated Messages section of the Metadata Broker.
Creating and manipulating catalog entries follows different state transitions depending wether Connector or Resource self-descriptions are concerned.
An IDS Connector self-description is either unknown to a catalog (initial state), registered (ConnectorRegistered), temporarily inactive (ConnectorInactive), or deleted from the catalog (end state) as shown in Fig. C1. An inactive self-description is intended for Connectors, which are currently not reachable but intend to become active again in the dataspace. A Connector which self-description has been deleted before (aka. has reached the end state) must never come back with the same URI identifier. This is to prevent false-flag operations where evil players claim the identity of removed Connectors.
Figure C1: State transitions of Connector self-descriptions in a catalog.
Fig. C2 shows the diagram how to request a Connector self-description entry from a catalog. The DescriptionRequestMessage contains a reference to the target Connector self-discription identifier, defining which catalog entry shall be returned. There is no intermediate state so the operation is either successful or fails, for instance, due to a non-existing entry or an incorrectly formatted message.
Figure C2: Requesting a Connector self-description has no further states apart of the standard success or error cases.
An IDS Resource is either unknown to a catalog (initial state), registered (ResourceRegistered), temporarily inactive (ResourceInactive), or deleted from the catalog (end state) as shown in Fig. C3. It may be automatically created if a Connector self-description is added or extended (ConnectorUpdateMessage) and its self-description also contains Resource entries. A Resource self-description becomes inactive - and active again - if its parent Connector catalog entry becomes inactive or active. Similarily, a Resource self-description gets deleted automatically if the containing Connector gets deleted through a ConnectorUnavailableMessage.
Figure C3: State transitions of Connector self-descriptions in a catalog.
Fig. C4 shows the diagram how to request a Resource entry from a catalog, similar to the operation for a Connector self-description. The DescriptionRequestMessage contains a reference to the target Resource self-discription identifier, defining which catalog entry shall be returned. There is no intermediate state so the operation is either successful or fails, for instance, due to a non-existing entry or an incorrectly formatted message.
Figure C4: Requesting a Resource self-description has no further states apart of the standard success or error cases.
Fig. C5 shows the diagram how to send a formulated query a catalog. Different to the retrieval of Connector or Resource self-description entries, the return format is not predefined but depends on the query. The QueryMessage contains formulated query string in a standardized query language, for instance, SPARQL or the upcoming GQL. There is no intermediate state so the operation is either successful or fails, for instance, if the query language is not supported by the catalog hoster or the query itself contains syntax errors.
Figure C5: Sending a catalog query has no further states apart of the standard success or error cases.
The API Operations of catalogs in the different protocol bindings are explained in the respective protocol sections:
messages and data types: protocols: state machines for message flows and interaction patterns: API binding:
currently out of scope
currently out of scope