Merge branch 'NFVSOL(26)000109_SOL026_Addressing_DMTF_feedback_for_Annex_B' into 'main'

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a>    ETSI GS NFV-IFA 010: \"Network Functions Virtualisation (NFV) Release 5; Management and Orchestration; Functional requirements specification\".

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a>    ODIM Project: "Open Distributed Infrastructure Management (ODIM)". Available at: ([https://odim.io](https://odim.io)).

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

## B.1 Introduction

According to the PIM architectural framework and the information model specified in the ETSI GS NFV-IFA 053 [\[1\]](#_ref_1), the PIM function can manage multiple NFVI-PoPs and the physical resources within those NFVI-PoPs. In such a scenario, the PIM can provide a centralized entrypoint for managing the physical infrastructure of each NFVI-PoP. The Redfish® standard on the other hand lacks a clear centralized architecture. Instead the standard Redfish® service can be seen as responsible for managing the hardware resources within an individual NFVI-PoP, or a site. This relationship is demonstrated with the help of an example manifestation of a distributed architecutre comprising of multiple NFVI-PoPs as illustrated in figure B.1-1.

According to the PIM architectural framework and the information model specified in the ETSI GS NFV-IFA 053 [\[1\]](#_ref_1), the PIM function can manage multiple NFVI-PoPs and the physical resources within those NFVI-PoPs. In such a scenario, the PIM can provide a centralized entrypoint for managing the physical infrastructure of each NFVI-PoP. The Redfish® standard on the other hand specifies a management interface and data model without mandating a particular architectural development, i.e., it is agnostic to whether management is implemented in a centralized or distributed manner. In practise, a Redfish® service can be seen as responsible for managing the hardware resources within an individual NFVI-PoP, or a site. 

This relationship is demonstrated with the help of an example manifestation of a distributed architecture comprising of multiple NFVI-PoPs as illustrated in figure B.1-1.

> NOTE: Within the NFV framework, the concept of NFVI-PoP represents a physical site or a point of presence (PoP) that offers infrastructure (NFVI) for the NFV workloads. The NFVI can further contain different kinds of infrastructure resources, e.g., physical, virtual, CIS cluster. See ETSI GR NFV 003 [\[i.1\]](#_ref_i.1) for more clarification on the concepts of NFVI, NFVI-PoP and examples of variours kinds of NFVI resources. 

> NOTE: Within the NFV framework, the concept of NFVI-PoP represents a physical site or a point of presence (PoP) that offers infrastructure (NFVI) for the NFV workloads. The NFVI can further contain different kinds of infrastructure resources, e.g., physical, virtual, CIS cluster. See ETSI GR NFV 003 [\[i.1\]](#_ref_i.1) for more clarification on the concepts of NFVI, NFVI-PoP and examples of various kinds of NFVI resources. 

![Figure B.1-1: Relationship between the PIM and Redfish® services in a distributed architecture](media/image46.png)

In a distributed scenario, the PIM function acts as a central gateway towards individual Redfish® services running within each NFVI-PoP, which offer entry points to managing the NFVI physical resources via their corresponding service roots \".../redfish/v1\". Subsequent Redfish® resources and services (such as Chassis, Systems, Managers, CompositionService, TelemetryService, EventService, LogService) for a corresponding NFVI-PoP can be reached under the root URI preceeded by the appropriate address space of the respective NFVI-PoP, e.g., the IP address and port on which the Redfish® service is exposed on.

An example of an implementation leveraging the Redfish® interface in a distributed architecture is provided by the Open Distributed Infrastructure Management (ODIM) project [\[i.3\]](#_ref_i.3). ODIM provides an example of a resource aggregation function that offers a centralized management interface while interacting with distributed infrastructure resources via Redfish® APIs. 

## B.2 Management considerations for the distributed architecture

### B.2.1 General considerations