Merge branch...

<mark>Editor's Note:    The above list to be updated if more relevant Redfish&reg; objects are identified to be mapped against the IFA053 NfviPopInfo object.</mark>

### 5.3.5 Physical resource inventory object

The physical resource inventory object, specified as PhysicalResourceInventory in ETSI GS NFV-IFA 053 [\[1\]](#_ref_1), does not correspond to any specific object in the Redfish® data model specification. However, it can be related with the NFVI-PoP object as specified in table 5.3.5-1.

**Table 5.3.5-1: Definition of the Physical resource inventory object**<a name="table_5.3.5-1"></a>

|Attribute Name|Data Type|Cardinality|Description|

|-|-|-|-|

|id|Identifier|1|Identifier of the resource.|

|nfviPops|NFVI-PoP|1..N|List of relevant NFVI-PoP data objects.|

In a distributed scenario where each NFVI-PoP is managed by its own Redfish® service, the collective physical resource inventory information can be represented as a collection of the respective NFVI-PoP data objects.

<mark>Editor's Note:    The physical resource inventory object is candidate to be omitted from this version of the present document to avoid any confusion. It can be included once it is clear how to aggregate the overall physical resource inventory belonging to different NFVI-PoPs.</mark>

## 5.4 Performance management related objects

### 5.4.1 PMJob

- Subscribe to notifications related to changes in inventory

- Notify subscribers according to the subscriptions

<mark>Editor's Note: Retrieving and updating inventory information across different NFVI-PoPs managed by the PIM requires further consideration as Redfish may lack support for distributed architecture. An additional aggregation/abstraction layer may need to be provided by the PIM to offer a consolidated view and management functionality across different NFVI-PoPs, and to interact with individual Redfish services operating within each NFVI-PoP. This aspect can potentially be explained by an informative annex in this document. The normative provisions related to this aspect may be omitted from the scope of the first edition of the present document.</mark>

## 7.2 API version

The API {VERSION} for the profiled Redfish® interface [\[2\]](#_ref_2) shall be set to \"v1\". Details about the API structure of the Redfish® interface [\[2\]](#_ref_2) are provided in clause 4.3.2 of the present document.

<br />

# Annex B (normative or informative): Title of annex

# Annex B (informative): Relationship between the PIM and the standard Redfish® service 

## 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.

> 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. 

## B.1 First clause of the annex

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

### B.1.1 First subdivided clause of the annex

**Figure B.1-1: Relationship between the PIM and Redfish® services in a distributed architecture**

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.

## B.2 Management considerations for the distributed architecture

### B.2.1 General considerations

The different PIM service interfaces specified in the present document are specified from the perspective of an individual NFVI-PoP. The physical resources within an NFVI-PoP are managed via the Redfish® protocol and its applicable API endpoints that are profiled to realize different PIM service interfaces. The root URI (\".../redfish/v1\") for these API endpoints stays the same for an NFVI-PoP. In case of multiple NFVI-PoPs, the PIM identifies the appropriate Redfish® service and its root URI for managing the physical resources across NFVI-PoPs.

### B.2.2 Considerations for inventory management

The PhysicalResourceInventory information model specified in ETSI GS NFV-IFA 053 [\[1\]](#_ref_1) represents inventory related information for all the NFVI-PoPs managed by the PIM. In a distributed scenario concerning multiple NFVI-PoPs where each NFVI-PoP is managed by its own Redfish® service, the overall physical resource inventory information can be represented as a collection of the respective NFVI-PoP data objects (see clause 5.3.4 for the definition of NFVI-PoP object.)

Retrieving and updating inventory information across different NFVI-PoPs managed by the PIM requires the PIM to identify the appropriate Redfish&reg; services of corresponding NFVI-PoPs and invoke inventory management operations towards those services on a per NFVI-PoP basis. Furthermore, a central aggregation layer is required at the PIM which offers a consolidated view of physical resource inventory across different NFVI-PoPs. This version of the present document does not specify any normative provisions related to this aggregation aspect.</mark>

According to the approach mentioned above, an example definition of the physical resource inventory object corresponding to PhysicalResourceInventory in ETSI GS NFV-IFA 053 [\[1\]](#_ref_1) is demonstrated in table B.2.2-1. However, such object is not managed via the physical resource inventory management service interface in this version of the present document. 

**Table B.2.2-1: Example definition of the Physical resource inventory object**<a name="table_B.2.2-1"></a>

|Attribute Name|Data Type|Cardinality|Description|

|-|-|-|-|

|id|Identifier|1|Identifier of the resource.|

|nfviPops|NFVI-PoP|1..N|List of relevant NFVI-PoP data objects.|

<br />