GAIA-X: Technical Architecture - Release - June, 2020 - Selbstregulierung ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
GAIA-X: Technical Architecture Release – June, 2020
Imprint Publisher Federal Ministry for Economic Affairs and Energy (BMWi) Public Relations Division 11019 Berlin www.bmwi.de Authors DE-CIX Management GmbH Günter Eggers (NTT Global Data Centers EMEA GmbH) Bernd Fondermann (German Edge Cloud GmbH & Co KG) Google Germany GmbH Berthold Maier (T-Systems International GmbH) Klaus Ottradovetz (Atos SE) Dr.-Ing. Julius Pfrommer (Fraunhofer IOSB) Dr. Ronny Reinhardt (Cloud&Heat Technologies GmbH) Hannes Rollin (T-Systems International GmbH) Arne Schmieg (German Edge Cloud GmbH & Co. KG) Sebastian Steinbuß (IDSA e. V.) Dr. Philipp Trinius (T-Systems International GmbH – Telekom Security) Andreas Weiss (EuroCloud Germany) Dr. Christian Weiss (Deutsche Telekom AG) Dr. Sabine Wilfling (Scheer GmbH) Current as at June 2020 Design and production PRpetuum GmbH, 80801 Munich You can obtain this and other brochures from: Federal Ministry for Economic Affairs and Energy, Public Relations Division Email: publikationen@bundesregierung.de www.bmwi.de Central ordering service: Tel.: +49 30 182 722 72 Fax: +49 30 181 027 227 21 This brochure is published as part of the public relations work of the Federal Ministry for Economic Affairs and Energy. It is distributed free of charge and is not intended for sale. The distribution of this brochure at campaign events or at information stands run by political parties is prohibited, and political party-related information or advertising shall not be inserted in, printed on, or affixed to this publication.
Content
1 Introduction............................................................................................................................................................................................................................................................................................................................................................................... 3
1.1 Objectives 3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Architecture Principles 3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Architecture Guidelines 4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Architecture Overview 4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Core Architecture Elements ........................................................................................................................................................................................................................................................................................................ 7
2.1 Services and Nodes 7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Data Assets 8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Consumer and Provider 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Self-Description 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Policies and Usage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.1 Data-Centric Usage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.2 Policy-Driven Workload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Interconnection and Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Monitoring and Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.1 Logging and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.2 Monitoring and Alerting ..................................................................................................................................... 17
2.8.3 Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Organization and Governance Viewpoint ...................................................................................................................................................................................................................................... 18
3.1 Relation between Service Provider and Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Rights and Obligations of Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Identity and Trust Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Trust Framework by certified Self-Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Service Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Federation, Distribution and Decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Ecosystem Viewpoint ................................................................................................................................................................................................................................................................................................................................. 25
4.1 GAIA-X Infrastructure Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 GAIA-X Data Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Standards for Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 GAIA-X Federated Ecosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Information Security and Data Protection Viewpoint ............................................................................................................................................................................. 30
5.1 Shared responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Federated Catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Data Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5.1 GDPR compliance of GAIA-X Federated Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5.2 GDPR compliance of GAIA-X Participants regarding Customer user data . . . . . . . . . . . . . . . . . . 33
5.5.3 GDPR compliance regarding Customer/Provider relation (GDPR capability of
Participant, service, Node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6 Terms and Conditions & Assurance Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 CO N T E N T
6 Onboarding & Certification................................................................................................................ 36
6.1 Onboarding a Provider and Consumer to GAIA-X 36 ........................................................................................
6.2 Onboarding Services and Nodes to GAIA-X 36 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Assuring Basic Level 37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Assuring Substantial and High Level 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Modularity and Recognition of Existing Certification, Standards and
related Schemes 38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Outlook and Next Steps ..................................................................................................................................................................................................................................................................................................................... 39
7.1.1 Overarching Advancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.2 Structured Advancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.3 Conclusion .................................................................................................................................................................... 44
Appendix A: Definitions ............................................................................................................................................................................................................................................................................................................................................ 45
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Advanced Smart Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Service Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Data Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B: Non-exhaustive list of Attribute Classes ................................................................................................................................................................................................... 46
(I) GAIA-X Node Attributes of Class: Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
(II) G AIA-X Node Attribute Classes: IT Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
(III) GAIA-X Node Attributes of Class: Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Contributers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Disclaimer
This document summarizes fundamentals of GAIA-X, comprising all relevant definitions,
concepts, and architectural aspects; especially new GAIA-X participants are encouraged to
read it diligently. Nevertheless, this document represents work in progress. As such, it con-
solidates the current status of discussion and will be subject to future improvements and
extensions. The contents encompass several levels of detail, ranging from abstract design
principles down to technical elaborations.3
1 Introduction
GAIA-X is set to be an Infrastructure and Data Ecosys- By matching both, Provider and Consumer can
tem according to European values and standards. This start to interact within the GAIA-X ecosystem.
overall mission drives its architecture.1 The architec- # Identity and Trust: Helps GAIA-X Participants to
ture employs digital processes and information tech- verify that their engagement with others and the
nology to facilitate the interconnection between all services they use are plausible, authentic and
participants in the European digital economy. By lev- backed by Self-Descriptions and Policies.
eraging existing standards, open technology and con-
cepts, it enables open, consistent, quality-assured and In particular, GAIA-X is aligned with the European
easy-to-use innovative data exchange and services. Data Strategy2, which aims to create a genuine single
Additionally, GAIA-X will become a facilitator for market for data, and is open to data from across the
interoperability and interconnection between its Par- world. Data may encompass personal, as well as
ticipants, for data as well as services. non-personal data, including sensitive business data.
The intention is to provide businesses an easy, safe and
secure way to an almost infinite amount of high-qual-
1.1 Objectives ity industrial data.
Digital Sovereignty is the power to make decisions The objective is to design and implement a data shar-
about how digital processes, infrastructures and the ing architecture (including standards for data sharing,
movement of data are structured, built and managed. best practices, tools) and governance mechanism, as
The GAIA-X architecture outlines technical solutions well as an EU federation of cloud infrastructure, related
to establish Digital Sovereignty according to EU infrastructure and data services.
standards.
One particular important aspect of Digital Sover- 1.2 Architecture Principles
eignty is Data Sovereignty. Data Sovereignty is the
execution of full control and governance by a Data The following architecture principles are directly
Owner over data location and usage. By applying the derived from the vision and objectives of the architec-
core architectural principles outlined below, GAIA-X ture. They represent the core values this architecture
will enable Providers and Consumers to participate in should comply with.
a digital sovereign ecosystem. GAIA-X builds on a
unique selection of technological approaches to bring 1. Openness and Transparency: The specification and
digital sovereignty to life: documentation of GAIA-X technologies and archi-
tectures will be accessible to GAIA-X Participants
# Federation: Supports standardized access to GAIA-X worldwide. The technical steering and roadmap of
as well as multiple decentralized implementations. GAIA-X is done in public and the involvement of
This way, a rich digital ecosystem is fostered. private sector players is disclosed. Everyone’s contri
# Self-Descriptions and Policies: The basic elements butions are welcomed. Technology choices will be
on a technical level for the selection, initiation and made in order to encourage distribution of collabo
coordination of interactions between Providers ratively created artifacts under open source licenses.
and Consumers. Self-Descriptions represent GAIA-X is aware that these technologies are evolving
GAIA-X offerings. Policies represent requirements. and is open to future innovation and standards.
1 Project GAIA-X A Federated Data Infrastructure as the Cradle of a Vibrant European Ecosystem
https://www.bmwi.de/Redaktion/EN/Publikationen/Digitale-Welt/project-gaia-x.html
2 A European Strategy for Data https://ec.europa.eu/info/sites/info/files/communication-european-strategy-data-19feb2020_en.pdf4 1 INTRODUCTION
2. Interoperability: All GAIA-X Participants will be ted solutions. Instead this architecture takes into
able to interact with each other in a well-specified account approaches like federation, distribution
way. This architecture describes the technical and decentralization, as detailed in a later chapter.
means to achieve that but is agnostic to and works
beyond specific implementations. 4. Usage-friendliness and simplicity: State-of-the-art
user experience, open standards and protocols, and
3. Federated Systems: GAIA-X specifies federated streamlined processes will be crucial for GAIA-X
systems of autonomous Providers, tied together by adoption and acceptance. Between two behaviorally
a specified set of standards, frameworks, and legal equal alternatives, the less complex one is to be
rules. The federation supports decentralization preferred.
and distribution.
5. Machine-Processability: All GAIA-X artifacts (like
4. Authenticity and Trust: An identity management requests, descriptors, notifications or messages,
system with mutual authentication, selective disc- including Self-Descriptions and policies) are ma
losure, and revocation of trust is needed to foster a chine readable. For the exchange of these artifacts,
secure digital ecosystem without building upon systems expose APIs (“Application programming
the authority of a single corporation or govern- interfaces”) as the primary means of interaction in
ment. GAIA-X. Human User Interfaces will leverage APIs
to enable the interaction of humans with GAIA-X.
Automation is supported by this architecture.
1.3 Architecture Guidelines
6. Semantic representation: By building on machine-
The following architecture guidelines enforce compli- processability, it is ensured that a GAIA-X data
ance with GAIA-X’s vision and principles. They ensure model is established, which carries the semantics
that the architecture is for the benefit of all GAIA-X of the ecosystem and effectively delivers interope-
Participants. rability. Core elements for semantic representation
are policy requirements and Self-Descriptions, ena-
In order to fulfill its vision and principles, the GAIA-X bling the translation of actual use cases into digital
architecture imposes technical guidelines. Every Par- processes.
ticipant will directly benefit, as the architecture is
built on them.
1.4 Architecture Overview
1. Security-by-design: GAIA-X puts security techno-
logy at its core to protect every Participant and The GAIA-X ecosystem as a whole is structured into a
system who is part of a GAIA-X eco system. Data Ecosystem and the Infrastructure Ecosystem.
2. Privacy-by-design: The European Union puts spe- Activity in the Infrastructure Ecosystem (see Section
cial emphasis on privacy regulations. In order to 4.1) is focused on providing or consuming infrastruc-
comply, this architecture already fundamentally ture services, which in GAIA-X are represented pri-
considers all privacy-related aspects. marily by the Asset called Node (see also section 2.1).
3. Enabling federation, distribution and decentrali- In Data Ecosystems (see Section 4.2), the main Asset is
sation: The core values should be reflected in the Data (see also Section 2.2). The architecture supports
engineering choices. This means that it is not a and enables Data Spaces and builds Advanced Smart
goal to build up centralized, homogeneous, isola- Services in industry verticals. This way, GAIA-X is1 INTRODUCTION 5
developed in accordance with European Data Strategy sumers are Services, ultimately also tying Data and
and supports innovative data applications and inno- Nodes together (see section 2.1).
vation across industry sectors.
The whole GAIA-X ecosystem is carried by a common
Participants, typically representing organizations and solid foundation consisting of Policy Rules, an
engaged within these ecosystems, are differentiated Architecture of Standards of interconnection. Figure 1
into the major roles, Provider and Consumer (see sec- gives a high-level overview of the GAIA-X architec-
tion 2.3). Yet, other roles exist and will be introduced ture.
in later sections. Cases where a Participant is both a
Provider as well as a Consumer at the same time, are GAIA-X defines technical concepts, functionality for
also possible. the federation and interoperability (such as for Iden-
tity and Access Management) that apply to the whole
Data and Infrastructure Ecosystems are not separable. GAIA-X ecosystem. GAIA-X takes on an orchestrating
The binding element between Providers and Con- role. However, it is not involved in individual transac-
Figure 1: H
igh-level overview of the GAIA-X architecture showing the major architecture elements and
functions accompanied by the Federation Services.
Data Ecosystem
Advanced Smart Services
Identity & Trust Sovereign Data Exchange
• Federated Identity Management • Policies & Usage Control
• Trust Management Data Spaces • Usage Control for data protection
• Federated Access • Security Concepts
• Self-Description • Relation between Service Providers
and -Consumers
• Service Governance
• Monitoring & Metering • Rights and Obligations of Participants
• Onboarding & Certification
Federated Catalogue Compliance
Infrastructure Ecosystem
Policy Rules & Architecture of Standards, interconnection
Physical Storage Data Spaces
Participants Services Data
Provider Consumer Both Nodes Logical
© BMWi6 1 INTRODUCTION
tions between Participants. Instead, GAIA-X provides # Self-Description: See Section 2.4 for details.
an opportunity for Providers to enhance their exist- # Service Governance: See Section 3 for an in-depth
ing isolated offerings to become GAIA-X-enabled. description.
# Monitoring and Metering: See Section 2.8 for
To bring the architecture principles to life, a set of more.
Federation Services is defined, implemented and
operated. The term Federation Service relates to infra- Sovereign Data Exchange
structure services, as well as organizational support
functionality, such as onboarding and certification. The sovereignty of data exchange is ensured by usage
control mechanisms and an overarching security con-
Federation Services are grouped into four domains: cept. In addition, standards for interoperability of the
data exchange will be selected.
Identity and Trust
# Policies and Usage Control: See section 2.6 for
Identity and Trust is seen from different angles across details.
the whole architectural stack. Detailed descriptions # Usage Control for data protection: See Section 5.5
are provided from different viewpoints in the follow- for coverage of data protection.
ing sections: # Security Concepts: Security concepts are covered
in detail throughout Section 5.
# Federated Identity Management: Identity Manage-
ment describes the provisioning of identifiers also Compliance
used for authentication. See Section 3.3 for details.
# Trust Management: Trust Management aims at Security and Data Protection depend not only on
establishing trust for every GAIA-X interaction. technical solutions, but also on organizational and
Please refer to Sections 3.3 and 3.4. governance aspects.
# Federated Access: Federated Access specifies how
access can be managed in a federated fashion. See # Relation between Service Providers and Consu-
Section 5.2 for a detailed explanation. mers. See section 3.1 for details.
# Rights and Obligations of Participants. See section
Federated Catalogue (Interoperability) 3.2 for details.
# Onboarding and Certification. See section 6 for
The Catalogue contains the offerings of Providers in details.
the GAIA-X ecosystem. Section 2 contains concepts
and results concerning core architecture elements The following sections provide a detailed discussion
and their relations to each other. of GAIA-X terms and concepts.7
2 Core Architecture Elements
In GAIA-X, an Asset is either a Node, Service, Service centers, edge computing, basic hardware, network
Instance or Data Asset. These are all elements of the and infrastructure operation services to more sophis-
GAIA-X ecosystem. The term Asset indicates an ticated, but still generic infrastructure building blocks
intrinsic value, as it can be marketed as a product like virtual machines or containers. Nodes are generic
within GAIA-X. The remaining terms are defined in in the sense that different Services can be deployed on
more detail in the following sections. An overview of them. Nodes expose functional and non-functional
the interactions between Assets and the GAIA-X Par- attributes via their Self-Description, allowing Node
ticipants is given in the following diagram. Consumers to select them based on their requirements.
One prominent attribute is the Node’s geolocation.
2.1 Services and Nodes Hierarchies of Nodes are supported by GAIA-X, so
Nodes can contain further Nodes as children. An
A GAIA-X Node is a computational resource. The scope example for this is a Node representing a pan-Euro-
of what a Node can represent can range from data- pean Node Provider that is structured into country
Figure 2: M
ajor relations between GAIA-X Assets and GAIA-X Participants. Participants can
take on multiple roles.
GAIA-X GAIA-X
Service Consumer Data Owner
controls
GAIA-X Service or makes
External Client available
consumes
GAIA-X GAIA-X
exposes
Service Instance Data Asset
hosts
es
iat
nt
ho
sta
sts
contains
in
GAIA-X provides GAIA-X
Service
Node
Legend
es
lic
Role of a m
su
en
n
se
Participant provides co provides
s
Asset
Self-Description
GAIA-X GAIA-X GAIA-X
Service Provider Service Instance Provider Node Provider
© BMWi8 2 CO R E A R C H I T E C T U R E E L E M E N T S
regions, which are themselves structured into data Asset. Consumers and Providers can also host private
center locations, racks and individual servers, which data within GAIA-X that is not made available (and
themselves are exposed as GAIA-X Nodes. hence not a consumable Data Asset).
A GAIA-X Service is a cloud offering. Services can be Data Assets are exposed and provided by GAIA-X Ser-
standalone or built in relation to other GAIA-X Services vices, where they can be searched and consumed by
by turning them into more complex service networks. another GAIA-X Service or a GAIA-X Participant.
The term Service does not favor any of the common From this, it follows that data being provided or con-
as-a-Service concepts like Infrastructure-as-a-Service, sumed by a GAIA-X Service is hosted on a GAIA-X
Platform-as-a-Service and so on. Services are offered Node. A GAIA-X Participant is the Owner of a Data
by a GAIA-X Service Provider and consumed by GAIA-X Asset. This must not necessarily be the same Partici-
Service Consumer. pant as the Provider of the Service that exposes the
Data Asset.
A GAIA-X Service Instance is the realization of a Service
on Nodes. Every Service might use a single Node or While the structure and the content of the data being
run distributed on multiple Nodes. When a particular used is not of relevance for the GAIA-X architecture,
Service runs on top of another Service, Service Cascades the GAIA-X architecture covers metadata and mecha-
are formed. nisms to make data an exchangeable and tradable
good. As the capability of Self-Description is a major
aspect of the GAIA-X Architecture, Data Assets pro-
2.2 Data Assets vide a Self-Description as well. This mechanism ena-
bles exchange, sharing and brokerage of data between
A GAIA-X Data Asset is a data set that is made availa- GAIA-X Services, and between GAIA-X Services and
ble to Consumers via a Service that exposes the Data non-GAIA-X Services.
Figure 3: Possible horizontal and vertical service integration in GAIA-X
Service can be moved
in Infrastructure Ecosystem Horizontal
Integration
Service Service
(e.g. in Data (e.g. in Data
Space) Space)
Vertical
Service Service Service Integration
(e.g. IaaS) (e.g. IaaS) (e.g. IaaS)
Node Node Node
© BMWi2 CORE ARCHITECTURE ELEMENTS 9
Self-Descriptions for Data Assets should include the # Data Owner: Data Assets are exposed by a Service
Owner, usage policies and provenance details, techni- Instance. The Provider of the Service Instance is
cal descriptions (data scheme, API,…) and content not necessarily the same Participant as the Data
related descriptions. The Self-Description can provide Owner. An example for this is a Database Service
additional details on the Data Asset, like data quality Instance provided to Consumers from a target
or legal aspects. industry. The Service Instance can make the data
available to the Data Owner itself. But the data can
Based on the mechanism of Self-Descriptions as out- also be exposed to further Participants, for exam-
lined above, a Data Asset is able to specify its own ple, as part of a Data Ecosystem. In this case, the
requirements with regard to Security and Data Pro- Data Owner can attach restrictions to the usage of
tection as well as other administrative requirements, his data in the form of Policies.
e.g. data lifecycle. See also the Section on Usage Con-
trol Policies.
2.4 Self-Description
2.3 Consumer and Provider GAIA-X Self-Descriptions express characteristics of
Assets and Participants. A GAIA-X Self-Description
A GAIA-X Participant is a natural or legal person (and describes properties and claims of an Asset or Partici-
their representatives) that can take on one or a multi- pant. Self-Descriptions are tied to the Identifier of the
ple of the following roles: Provider, Consumer, Data respective Asset or Participant. The Providers of an
Owner, Visitor. The combination of multiple Roles by Asset are responsible for the creation of the respective
one GAIA-X Participant depends on the respective Self-Description. Trusted parties can sign portions of
Business Case. the Self-Description to establish trust.
Users are technical accounts derived from a Partici- Self-Descriptions in combination with trustworthy
pant. As an example, if a company becomes a GAIA-X verification mechanisms empower Participants in
Participant, there can be many employees of that their decision-making process. Specifically, Self-De-
company with individual accounts. Actions performed scriptions can be used for:
by a User are made on behalf of the Participant from
which the User is derived. See Section 3.3 on Identity # Discovery of Assets in a Catalogue
and Trust Management for details. # Tool-assisted evaluation, selection and integration
of Service Instances and Data Assets
All Nodes, Services and Service Instances have an # Enforcement, continuous validation and trust
associated Provider. The Service Instance and Data monitoring together with Usage-Control Policies
Asset merit a more complete description of the inter- # Negotiation of contractual terms concerning
action between roles: Assets and Participants
# Service Instance Provider: Service Instance Provi- GAIA-X Self-Descriptions are characterized by the fol-
ders provide Service Instances, which they instan- lowing properties:
tiate on one or more Nodes. Service Instance Pro-
viders are often also Consumers of Nodes and # Machine-readable and machine-evaluable
Services (which they can license for the instantia- # Technology-agnostic
tion). Furthermore, Service Instances can consume # Adhering to a generalized schema
further Service Instances on which they depend. # Interoperable, following standards in terms of for-
mat, structure, and included expressions10 2 CO R E A R C H I T E C T U R E E L E M E N T S
# Flexible, extensible and future-proof in terms of Future GAIA-X Catalogue Services implement query
adding new properties and property classes algorithms on top of the Self-Description Graph. Fur-
# Navigable and uniquely referenceable from any thermore, certification aspects and usage control poli-
where, in a decentralized fashion cies can be expressed and checked based on graph
# Expressive semantics, uniquely defined by a defi- information that cannot be gained from individual
ned schema vocabulary Self-Descriptions. For example, a Service Instance
# Accompanied by statements of proof (e.g. certifica- cannot depend on other Service Instances that are
tes and signatures), making them trustworthy by deployed on Nodes in a foreign jurisdiction.
providing cryptographically secure verifiable
information A Self-Description includes the Identifier of the Asset
or Participant, metadata and one or many descriptor
The Self-Descriptions refer to other GAIA-X Self-De- sections. The descriptor sections are named Testimo-
scriptions. These relations can be expressed in a graph nials. They contain one or more claim statements,
data structure with typed relations. This is called the comprised of subjects, properties and values. Meta-
GAIA-X Self-Description Graph. The Self-Description data describe Self-Descriptors and Testimonials by an
Graph can be seen as a set of relation triples. For identifier and additional properties such as issuing
example, a textual representation: timestamps, expiry data, issuer references and so forth.
Testimonial can have references to other Self-De-
(OKORO, implements, ArchiveStorage) scriptors that link to the particular subject. Each Testi-
(ArchiveStorage, hostedOn, NodeABC123) monial can have a cryptographic signature wherein
(NodeABC123, providedBy, NodeProviderA) trusted parties verify the contained claim statements.
Figure 4: Self-Description assembly model
Self-Description Testimonial
Metadata Metadata
1 *
Testimonial – 1..n Claims – 1..n
Proof Info 1..n Proof Info 1..n
© BMWi
Figure 5: Example for Claim Statement
Subject Value
hasCertificate
Node e.g. ISO 27001
© BMWi2 CORE ARCHITECTURE ELEMENTS 11
Figure 6: Linked claim statements as a graph representation
hasCertificate issuedBy name
Node ISO 27001 DUV Jane Doe
buildOnSpec
providedBy
CP Series 371 OpenCompute
© BMWi
The Self-Description itself can have a cryptographic schemas will build upon Linked Data Standards like
signature, including an initial set of Testimonials. Fur- RDF/OWL 4 and JSON-LD5 and represent these in a
ther Testimonials can be added to the Self-Descrip- common format (e.g. JSON6) to enable broad adoption
tion later on, but trust for them is not covered by the and tooling. GAIA-X builds upon existing standards
signature for the overall Self-Description (Figure 4). for schema definitions, for example based on W3C
schema definitions 7 to get a common understanding
Claims are expressed using subject-property-value of the meaning and purpose of any property and
relationships following resource description stand- claim statement.
ards. As an example, the certification of a Node can be
expressed as in Figure 5. Mandatory and optional claim statements for the
Self-Descriptions are semantically defined in an exten-
The generic data model for claims is powerful and sive hierarchy of Self-Description Schemas. Figure 7
can be used to express a large variety of statements. shows mandatory elements of the top-level Self-De-
Individual claims can be merged together to express a scription Schemas.
graph of information about an asset (subject). For
example, whether a Node is certified by BSI with Individual claim statements as attributes are referred
hardware CP Series 371 based on an OpenCompute for simplicity. A number of attribute categories will be
Specification3 is expressed as shown in the Figure 6. defined. A Self-Description attribute category
describes any number of Self-Description attributes
To get a common understanding of the meaning and that have a common conceptual basis.
purpose of any property within the claim statement,
semantic description techniques are used to express The requirements for provided attributes are kept to a
the objects and properties that are linked to existing minimum to enable a broad range of Providers,
and common definitions or to a defined GAIA-X Nodes, Services and potential Consumers to partici-
schema. The declarative representation of GAIA-X pate in GAIA-X.
3 https://www.opencompute.org/
4 McGuinness, D. L., & Van Harmelen, F. (2004). OWL web ontology language overview. W3C recommendation, 10, 2004.
5 Sporny, Manu, Dave Longley, Gregg Kellogg, Markus Lanthaler, and Niklas Lindström. “JSON-LD 1.0.” W3C Recommendation, 2014.
6 JSON-LD For Linked Data. https://json-ld.org/
7 https://schema.org/; W3C RDF https://www.w3.org/RDF/ or W3C Verifiable Credentials Data Model
https://www.w3.org/TR/vc-data-model/12 2 CO R E A R C H I T E C T U R E E L E M E N T S
Examples of Attribute Categories per Self-Description # Services: Self-Descriptions of Services describe
in GAIA-X are discussed below. Services as defined in Section 2 (Basic Architecture
Elements). Attribute Categories for Services are
# Providers: Every Provider of Nodes and Services still under discussion and are not yet finalized.
has to be registered as Provider and thus requires a # Consumers (optional): Self-Descriptions of Con-
Self-Description. The categories comprise identity, sumers are optional, but may be required for
contact information, certification. accessing critical Data Assets and/or specific
# Nodes: Self-Descriptions of Nodes describe relevant domains. Attribute categories for Consumers are
functional and non-functional attributes of Nodes still under discussion and are not yet finalized.
as described in Section 2 (Basic Architecture Ele-
ments). The Attribute Categories comprise avail A first, non-exhaustive collection of relevant attribute
ability, connectivity, hardware, monitoring, physi- classes is attached in appendix B.
cal security and sustainability.
Figure 7: S
chematic inheritance relations and properties for the top-level Self-Description
Schemas.
© BMWi2 CORE ARCHITECTURE ELEMENTS 13
2.5 Catalogue toolbox in hand, existing integrators, cloud providers
or anyall are free to integrate the GAIA-X offerings
The concept Self-Description is the foundation of the into their own offerings. Another option to offer
federated GAIA-X Catalogues. Catalogues are the Assets to Consumers is a graphical portal frontend
main building block for the publication and discovery that is using the same API and base functionality. To
of Self-Descriptions of Assets and Participants. To sat- support an ease concept, custom filter and policy
isfy Consumer needs and to objectively find the best definitions with domain specific languages (DSL) are
fitting offerings in the tangle of registered Assets, an introduced. The policy and query statement defini-
open and transparent query algorithm is implemented tions facilitate filtering to reduce the complexity and
without any GAIA-X internal ranking. Beside search make it possible to find the best matching Asset based
functionality, a graph-based navigation interface is on the Self-Descriptions and to find relations between
provided to traverse the complex tangle of offered Assets in a human-friendly manner that can be auto-
Services, Nodes and linked Self-Descriptions, includ- mated when necessary.
ing the attached claims with chain of trust statements.
Consumers can verify each Self-Description individu-
ally and decide which one to select in a self-sovereign 2.6 Policies and Usage Control
manner – GAIA-X does not act as a runtime interme-
diary or broker. In GAIA-X, Policies define a set of restrictions. They
can be viewed as the counterpart of the Self-Descrip-
Catalogue Federation tion. It describes invariants that must be assured in a
software execution environment based on the infor-
Multiple federated catalogue software instances can mation from the Self-Descriptions of Assets and Par-
be operated independently at different locations. ticipants.
Self-Descriptions in a Catalogue are either entered
directly by the respective Provider, imported from Policies are also dynamically evaluated at runtime,
another federated GAIA-X Catalogue or even imported and not only during onboarding and instantiation.
from an external collection. The GAIA-X Catalogues Suitable alerting and escalation measures can be
act as an access point to information that verifies the linked to Policies to handle changes in a dynamic
content of Self-Descriptions. However the origin of a environment.8
Self-Description must, be known, to prevent abuse.
2.6.1 Data-Centric Usage Control
A Catalogue can represent different views on existing
offerings, such as domain-specific selections of Assets. While access control restricts access to specific
This feature will be helpful as long as the Consumer is resources (e.g., a Service or a file), data sovereignty is
aware and able to switch off any catalog restriction in additionally supported with Data-Centric Usage Con-
a simple way and get access to all offered Assets. trol. The goal of Data-Centric Usage Control is to
make sure that specified usage restrictions and obli-
Portal and API Integration gations are realized even after access to data has been
granted. Therefore, Usage Policies must be bound to
For integration purposes, e.g. DevOps automation data being exchanged and continuously controlled
tools, the Catalogues provide access through an appli- during the data flow of processing, aggregating or for-
cation programmer interface (API). With this simple warding. Usage Policy enforcement is subject at sys-
8 See the position paper by the Industrial Data Space Association for possible technical refinements of the Usage Control concepts:
https://www.internationaldataspaces.org/wp-content/uploads/2019/11/Usage-Control-in-IDS-V2.0_final.pdf14 2 CO R E A R C H I T E C T U R E E L E M E N T S
tem design, configuration and runtime. It also sup- 2. Enforcement of Usage Policies: Different kinds of
ports auditing after data processing by creating audit- obligations require different mechanisms for enfor-
able logs and provenance tracking. The following cement. Technical enforcement including auditabi-
examples illustrate security requirements that cannot lity would be preferred for various scenarios, but
be achieved using traditional access control, but can this is often hard to achieve. Therefore, organiza-
be achieved with Data-Centric Usage Control: tional measures to enforce usage policies must also
be considered, as well as legal measures. In GAIA-X,
# Secrecy: Classified data must not be forwarded to possible and required measures for the enforcement
Nodes or Services which do not have the required of usage policies need to be discussed and defined.
certification.
# Separation of duty: Two data sets from competi- 2.6.2 Policy-Driven Workload Control
tive entities must never be aggregated or proces-
sed by the same Service. In GAIA-X, the workload can shift between Nodes at
# Usage scope: Data must never leave the Node or runtime. Service Instances can be deployed on multi-
Service to an external endpoint. ple Nodes and can move between Nodes. Furthermore,
Service Instances that consume other Service Instances
The project GAIA-X identified Usage Policy Enforce- can switch between equivalent offerings.
ment as an important architectural aspect to achieve
Data Sovereignty. In this context important concepts Policy-Driven Workload Control requires that the
have to be defined for the context of a federated definition of restrictions confirm to the mobility of
cloud system: Service Instances. For example, certain tasks must be
performed by Service Instances from Providers with a
1. Specification of Usage Policies: The Usage Policies defined certification level, or only Nodes within a
specified by a data provider must be both machine given jurisdiction can be used.
and human readable, and therefore interoperable.
The underlying specification language and the
required capabilities need to be defined. This 2.7 Interconnection and Networking
includes:
a. Capabilities to express technical, organizational The GAIA-X target architecture aims at creating two
and legal conditions. ecosystems, a Data Ecosystem and an Infrastructure
b. The capability to create and maintain usage Ecosystem. Data and infrastructure should be combi-
policies (administration). nable in nearly arbitrary ways to enable movement of
Figure 8: High level overview of interconnection and networking within GAIA-X.
GE
C
C
P
= Best effort Communication Service
ED
HP
SS
CS
Self-description = Elevated interconnection and
ICP Measurement networking services available
(e.g., closed user groups)
ICP Measurement
Cloud Service Providers (CSP)
Self-description
High Performance Computing (HPC)
Sector-specific Clouds (SSC)
EDGE
© BMWi2 CORE ARCHITECTURE ELEMENTS 15
Figure 9: Simplified example of interconnection between Nodes.
«Node»
Region
«Node»
DataCenter
«Node» «Node»
Availabilty Zone 1 Availabilty Zone 2
«Device Node» «Device Node»
Availabilty Zone 1::AB Blade 600 Availabilty Zone 2::AB Blade 600
connect connect
Wide Area Network
« System So ware Node» « System So ware Node»
Availabilty Zone 1::AB Blade 600::Virtual Availabilty Zone 2::AB Blade 600::Virtual
WA Ware Node XYZ WA Ware Node 123
connectedBy
Availabilty Zone 1::Data Center Availabilty Zone 2::Data Center
Network Network
«Device Node» connectedBy connectedBy «Device Node»
Availabilty Zone 1::AB Blade 600 Interconnection Service Availabilty Zone 2::AB Blade 600
« System So ware Node» « System So ware Node»
communicate communicate
Availabilty Zone 1::AB Blade 600::Virtual Availabilty Zone 2::AB Blade 600::Virtual
WA Ware Node ABC WA Ware Node 789
© BMWi
data and services in a federated cloud architecture. # Self-Description: networking and interconnection
However, regardless of their abstract virtual locations, are covered by Self-Descriptions (see Chapter 2.4).
services and data have a physical location. Obviously, Self-Descriptions of networking and interconnec-
the central ideas of GAIA-X require communication tion aspects exist on two levels: the first is cloud
support by design. Thus, GAIA-X integrates intercon- providers’ internal network, the second is cloud
nection and networking aspects into the architecture. providers’ external network. To date, both are
The architecture considerations on networking and described as GAIA-X Node connectivity attributes.
interconnection rely on three building blocks as Regarding cloud provider internal networking, the
described in the following. networking hardware of single machines is descri-
bed as the type and speed of Network Interface
Controllers (NICs) (see Appendix B). Regarding16 2 CO R E A R C H I T E C T U R E E L E M E N T S
cloud provider external networking, Self-Descrip- networking. In the external case, GAIA-X can pro-
tions cover the external links a cloud provider vide interconnection and networking service offer
owns to connect a Node to the Internet (“inter- ings to customers that provide elevated services
connection”), e.g., links to any upstream network compared to the standard Quality of Service of the
providers such as peering point presences, transit public Internet (as described above). Examples for
network providers, or other Internet Service Pro- such elevated services could be interconnection
viders (ISPs). Naturally, external networking Self- with latency and throughput QoS guarantees or
Descriptions can be tied to a Node representing a secure and isolated communication in closed user
larger infrastructure, such as a cloud provider’s groups for sector-specific clouds such as the medi-
data center presence or even a whole cloud region cal sector.
(see Appendix B). The purpose of interconnection
and networking Self-Descriptions is to support the To date, interconnection and networking services are
GAIA-X matching process of Services and their considered to be within the general GAIA-X architec-
execution environments, i.e., the selection process ture because they are modelled them alongside other
via the Catalogue. concepts such as Providers, Nodes, and other cloud
# Inter cloud provider (ICP) measurements: descri- services. Moreover, the most relevant attributes
bing connectivity between GAIA-X Nodes/Provi- required for interconnection and networking are cov-
ders is an important factor, however it may be dif- ered in the current draft of Self-Descriptions of Nodes.
ficult to guarantee that packets travel across certain
links between cloud providers without deeply In the near future, the specifications of a measurement
interfering with routing decision made by possibly system for GAIA-X as well as a concept for a measuring,
being many different organizations. Consequently, metering and billing network and Strong connectivity
the approach of self-describing connectivity is services are planned. Moreover, it is planned that an
complemented by connectivity measurements, SD-WAN-like approach for the GAIA-X matching pro-
e.g., latency measurements. By incorporating mea- cess will allow users to specify their networking
surements modules into the overall GAIA-X archi- requirements in terms of QoS and topology, which
tecture, GAIA-X is able to provide a consistent view will be matched to the available services and infra-
of the connectivity between cloud Providers and structure in GAIA-X in the best possible way. Over the
Consumers. Together with the information contai- long term, the three building blocks Self-Description,
ned in Self-Descriptions, connectivity measure- ICP measurements, and interconnection and net-
ments are a valuable input for many scenarios, e.g., working services are envisioned to enable the forma-
optimizing the selection of Nodes from multiple tion of a federated GAIA-X backbone infrastructure.
cloud providers for multi-cloud scenarios or fin-
ding a cloud provider’s optimal data center to serve
a certain consumer or EDGE provider. However, 2.8 Monitoring and Metering
measurement information can only give probabi-
listic guarantees on Quality of Service (QoS) para- Monitoring is an important component of federated
meters such as latency and throughput. systems and cloud services in particular. Due to a het-
# Interconnection and networking services: inter- erogeneous technology landscape, access to monitor-
connection and network providers can offer inter- ing is a technical hurdle for the loose coupling of Ser-
connection and networking services similar to vices and Nodes from different Providers. Hence, to
other cloud Service Providers. This covers cloud enable the development of Infrastructure and Data
provider internal networking (e.g., VLANs, load Ecosystems, GAIA-X aims to provide standard mecha-
balancing, etc.) as well as cloud provider external nisms for monitoring. This does not prevent the exist-2 CORE ARCHITECTURE ELEMENTS 17
ence of specialized monitoring services with addi- as well as conceptual definitions, such as monitoring
tional capabilities. The topic of monitoring is handled levels and classifications of monitoring targets. This
differently for three distinct cases: allows the interoperability of monitoring and opera-
tions tools with the full range of Services and Nodes
1. Logging and Auditing in GAIA-X. Furthermore, since Services can form a
2. Status Monitoring and Alerting Service-Mesh, monitoring information can be aggre-
3. Metering gated and forwarded in a standard way to increase the
visibility a Service Consumer has into the overall sys-
Monitoring capabilities will be described as part of the tem.
Self-Description mechanism so that Consumers can
select Services and Nodes according to their Monitor- Where possible, existing standards are used for the
ing needs. GAIA-X will not perform monitoring of monitoring interfaces. There are two major models
Services itself. But it is possible that a third party mon- for monitoring: Pull-Monitoring where logs can be
itors the availability of Services on behalf of other retrieved by the Customer and Push-Monitoring where
GAIA-X Participants. For example, to supervise Ser- updates and alert notifications (with optional filter-
vice-Level KPIs that are part of a certification or con- ing) are automatically sent to the Consumer. There
tractual agreement. can be different levels of granularity and detail for
monitoring. The details of the access to monitoring
2.8.1 Logging and Auditing are established between the Provider and Consumer.
Logging refers to the access to runtime log information All GAIA-X Nodes and Services must have monitoring
that is generated by a Service or Node. This is both capabilities. Consumers get monitoring access to
used during the development of distributed systems Nodes and Services according to the usage agreements
in GAIA-X (including debugging) and at runtime. Some they have with the respective Provider. A failure of
Services and Nodes may require auditing due to legal monitoring on the Provider side is seen as a service
and contractual requirements. Oftentimes, logs for outage with respect to Service-Level Agreements.
auditing have to be transferred and stored in a tam-
per-secure manner on a separate system. 2.8.3 Metering
To improve the transparency and to increase the inte- Metering is similar to monitoring, but specifically
gration of Services from many vendors, standard refers to the access to performance indicators and
interfaces are provided. consumption statistics. Metering is not only impor-
tant for transparency with respect to billing, but also
2.8.2 Monitoring and Alerting crucial to the resource-efficient scaling and opera-
tions of large-scale cloud applications. GAIA-X itself
Monitoring in the context of GAIA-X refers to the does not act as a billing provider or clearing house.
access to status information of Services and Nodes, as But GAIA-X will define standard interfaces and mech-
well as alerting. Monitoring is essential for the opera- anisms for metering to be used by the Consumers and
tion of large-scale distributed applications. GAIA-X Providers. Where possible, these are based on existing
will define standard mechanisms and interfaces for standards.9 The availability of standard metering
monitoring. The monitoring definitions of GAIA-X interfaces will be part of the Self-Description of
are on two levels: Technical interfaces for monitoring, Nodes and Services.
9 For example, ISO/IEC TR 23613: 2020, Information technology – Cloud computing – Cloud service metering elements and billing
modesYou can also read
