Versions Compared

Old Version 3

changes.mady.by.user Susanne Nägele-Jackson

Saved on

compared with

New Version Current

changes.mady.by.user Nicolai Iliuha

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Section


Column
width20%

image of person writing on glass (Photo by Kvalifik on Unsplash)

Image of empty page (Photo by Aaron Burden on Unsplash)


Column
width80%

The orchestration, automation and virtualisation(OAV)architecture focus group within the Network Technologies and Services Development Work Package (WP6) Network Services Evolution and Development Task (T2) of the GN4-3 project has Network eAcademy team initially compiled and investigated a list of required features and capabilities that needto be supported by an OAV architecture solution of a research and education (R&E) network ecosystem. This list is by no means exhaustive,or prioritised in any way,and can be used as a supporting cross-reference checklist when deciding onnew architectural designs or approaches, technologies or components.


Section


Column
width80%

The architecture should:

  • Implement security by design by addressing all relevant aspects of confidentiality, integrity and availability(CIA).
  • Support open application programming interfaces(APIs)and open source implementations whenever possible with strong developer community support and documentation readily available.
  • Support interoperability with other industrial platforms, products and standard industry-adopted architectures (see plugtests such as ETSI NFV Plugtest [NFVPLREP] for interoperability checks).
  • Support automation in all aspects of service management, including global inter-domain services.
  • Support common information and standardised data modelling to represent resources and services.
  • Support flexible composite services (based on discrete atomic network service objects) with infrastructure-independent implementation.
  • Support service discovery using a service portfolio that provides information about the service classification and inter-service dependencies and other relevant relationships.
  • Support organisations and service catalogues of all sizes (large and small).
  • Support hierarchical orchestration, including multi-domain orchestration.
  • Support implementation of loosely coupled components, i.e. building blocks with a well-defined set of functionalities.
  • Support integration of components using popular DevOps or NetDevOps tools and platforms.
  • Support abstraction/virtualisation so that the platform can be technologyindependent and service agnostic,with the possibility to manage resources independently of vendor-specific features.
  • Enable flexible scalability (scale in/out and up/down).
  • Support innovative future development and research.



Column
width35%

image of list of items (Photo by Sebastian Herrmann on Unsplash)





In amulti-domain environment with automated provisioning of composite inter-domain services, it is of great importance that the collaborating parties agree to follow a certain minimum set of principles and guidelines. Within the GÉANT community, this multi-domain environment might include GÉANT as an organisation, the NRENs, but also other related parties such as research institutions, universities, etc. In other words, any entity that has its own administrative domain and would like to build an OAV solution to manage its domain and products with their underlying services.

This list of requirements can be used as a checklist of features and capabilities needed to providean efficient, yet highly agile and dynamic environment that supports a vast set of servicesbuilt upon physical and virtual resources, as well as enable collaborative efforts with all partners. Itcan be considered a summary of characteristics or guidelines that should be part of an architecture blueprint or reference architecture for OAV within an organisation, but that at the same time can lay the groundwork for defining a common understanding and common interface between other multi-domain parties. Such an architectureblueprint for OAV is needed to set the foundation for federation, interoperation and collaboration between the separately implemented solutions in the NREN community. Adhering to this minimum set of requirements does not impose any particular restrictions on the manner of implementation of an NREN’s architecture; specifics of local implementation are a matter for each NREN. The requirements call for a technology-and service-agnostic design so that any type of technology can be used for the implementation of separate components of the architecture, and the architecture can be used for the agile, model-driven lifecycle management of any type of digital service an NREN would like to offer.

It must be stressed that the requirements anddesign principles discussed in this section are to be considered as enduring guiding principles that provide a consistent set of rules across the whole organisation and its processes. They are aligned to the standards of The Open Group Architecture Framework (TOGAF) and are based on the TOGAF Architecture Development Methodology [TADM11].

This list of requirements was used in the process to select the TM Forum Open Digital Architecture as the Architecture blueprint (ODA) and in the creation of training contents under the Network Automation eAcademy (OAV Training Portal).


References:

[NFVPLREP]   4th ETSI NFV Plugtests Report V1.0.0 (2019-07), https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/4th_ETSI_NFV_Plugtests_Report_v1.0.0.pdf

[TADM11]     TOGAF Architecture Development Methodology, 2011, https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap05.html