Corrections to PDU section

Some relevant concepts are:

- PNF: Physical network function. It refers to a HW box that provides a networking function. For example: Routers, firewalls and load balancers.

- PDU: Physical deployment unit. It refers to the instance of the PNF in a VIM or VIM_account that will be managed.

- HNF: Hybrid network function: Network function composed of both physical and virtual elements.

- **NF: Network Function.** Element ready to play a well-known role in a given Network Service, with well known Day-0/Day-1 procedures as well as Day-2 actions and metrics. Examples of NFs are EPC, IMS, BNG, PE, DNS, firewall, LB, etc.

- **VDU: Virtual Deployment Unit.** It refers to a virtual machine that is part of a Network Function. In the context of a NF instance it will be a specific VM running in a specific VIM target.

- **PDU: Physical Deployment Unit.** It refers to a HW box that is part of a Network Function. In the context of a NF _instance_ it is connected to some well-known networks that can be related to VIM targets known by OSM.

- **VNF: Virtual Network Function.** Network Function exclusively composed of VDUs (i.e. virtual machines).

- **PNF: Physical Network Function.** Network Function exclusively composed of a **unique** PDU (i.e. a **unique** HW box).

- **HNF: Hybrid Network Function:** Network function composed of both Virtual Deployment Units (VDUs) and Physical Deployment Units (PDUs), or a even a set of PDUs.

In OSM, there are no fundamental differences between modelling a VNF, a PNF or a Hybrid Network Function (HNF). In those cases where we want to define NS packages consisting of PNF packages or HNF packages, OSM needs to be instructed about the available PDUs.

Before including a PDU as part of a HNF Descriptor file, which would be similar to a VNFD, the PDU needs to be register.

Before instantiating an NF that includes PDUs (i.e. a PNF or an HNF), we would need to check that there are some PDUs of the appropriate type available in the target location and that they have been conveniently registered in OSM.

A PDU can be registered through the UI (Instances --> PDU Instances), for example:

A PDU that is available can be registered in OSM through the UI (Instances --> PDU Instances). For example:

![Creating a PDU through the UI](assets/800px-OSM_pdu.png)

It can also be created through a YAML file which looks like this:

It can also be registered through the OSM CLI passing a YAML file similar to this one:

```yaml

name:           router01

    mgmt:       false

```

Then, using the OSM CLI, the yaml file is used to register the PDU.

Then, using the OSM CLI, the YAML file is used to register the PDU:

```bash

osm pdu-create --descriptor_file PDU_router.yaml

```

Finally, the PDU is included in the descriptor as it was any VDU (with the applicable parameters) by setting `pdu-type`, and Day1/2 configurations can be applied to it. For example, a PDU could be modeled like this:

On the other hand, the PDU should have been already included in the NF descriptor as if it were a VDU (with the applicable parameters) by setting `pdu-type`, and Day1/2 configurations can be applied to it. For example, a PDU could be modeled like this:

```yaml

    vdu:

              ...

```

At instantiation time, OSM looks for a free PDU in the target `VIM_account` with the same type declared at `VNFD.vdu.pdu_type` and having al least all the interfaces declared at `VNFD.vdu`, that is, each `VNFD.vdu.interfaces.name` must be present at `PDU.interfaces.name`.

At instantiation time, OSM looks for a free PDUs in the VIM target with:

- the same type declared at `VNFD.vdu.pdu_type`, and

- that have at least all the interfaces declared at `VNFD.vdu`, that is, each `VNFD.vdu.interfaces.name` must be present at `PDU.interfaces.name`.

## Intra-VIM SDN management (for SDN Assist)