-
Notifications
You must be signed in to change notification settings - Fork 15
PNF VNFD Example
Stefan Schneider edited this page Dec 3, 2018
·
28 revisions
This is an example of a VNFD which describes a PNF. It is a living document to define how such a descriptor should look like, so that we can create a schema for it. PNF and CNNF schemas are currently developed in Issue 79.
Refactored, cleaned up VNFD example with a PDU. Using the suggestions from below.
# the VNFD header doesn't change for PDUs
descriptor_schema: "https://raw.githubusercontent.com/sonata-nfv/tng-schema/master/function-descriptor/vnfd-schema.yml"
vendor: "eu.5gtango"
name: "physical-test-vnf"
version: "0.9"
author: "5GTANGO Developer"
description: "A PNF example."
# this is the only new section
physical_deployment_units:
# mandatory: info to identify the PDU and connect to it
- id: "pdu01"
address: "example.ip" # simple info on how to connect to the PDU
port: 1234
# optional: further useful but not critical info (which might not always be available)
vendor: "cisco"
version: "16.9"
description: "cisco-router-CSR1000v"
geo_location: "AthensNorth-room6-rack3-slot6"
performance:
throughput: # predefined types like throughput, processing_delay
value: 100
unit: "mbps" # unit may be any string like "mbps" or "reqs_per_sec"
# mandatory: similar to VDU connection points. can we use those of PDUs as well?
connection_points:
- id: "mgmt"
interface: "ipv4"
type: "internal"
# optional: role, description
- id: "input"
interface: "ipv4"
type: "internal"
- id: "output"
interface: "ipv4"
type: "internal"
# remaining sections are the same for all VNFDs (indep. of VDU, CDU, or PDU)
connection_points:
- id: "mgmt"
interface: "ipv4"
type: "management"
- id: "input"
interface: "ipv4"
type: "external"
- id: "output"
interface: "ipv4"
type: "external"
virtual_links:
- id: "mgmt"
connectivity_type: "E-LAN"
connection_points_reference:
- "pdu01:mgmt"
- "mgmt"
dhcp: True
- id: "input"
connectivity_type: "E-Line"
connection_points_reference:
- "pdu01:input"
- "input"
dhcp: True
- id: "output"
connectivity_type: "E-Line"
connection_points_reference:
- "pdu01:output"
- "output"
dhcp: TrueInitial example with different suggestions.
---
descriptor_schema: "https://raw.githubusercontent.com/sonata-nfv/tng-schema/master/function-descriptor/vnfd-schema.yml"
vendor: "eu.5gtango"
name: "physical-test-vnf"
version: "0.9"
author: "5GTANGO Developer"
description: "A PNF example."
# virtual deployment units inside the VNF
physical_deployment_units:
# Carlos Proposals (see sections below wrt ETSI documents)
- id: "pdu00"
name: "testing PDU"
description: "This is a PDU for testing"
geographical_location_info: "Central Office 1234"
vendor: "5gtango"
version: "1.1"
resource_requirements: # This is very PNF specific...
throughput:
mbps: 100
requests:
reqs: 100
connection_points:
- id: "input"
interface: "eth0"
type: "internal"
protocol: "ipv4,ipv6"
role: "service_input"
description: "Input of the service"
- id: "output"
interface: "eth1"
type: "internal"
protocol: "ipv4,ipv6"
role: "service_output"
description: "Output of the service"
- id: "pdu01"
# INPUTS NEEDED
# Example: VNF contents
#vm_image: "ubuntu:16.04"
#vm_image_format: "docker"
#resource_requirements:
# cpu:
# vcpus: 1
# memory:
# size: 512
# size_unit: "MB"
# storage:
# size: 10
# size_unit: "GB"
#connection_points:
# - id: "mgmt"
# interface: "ipv4"
# type: "internal"
# - id: "input"
# interface: "ipv4"
# type: "internal"
# - id: "output"
# interface: "ipv4"
# type: "internal"
# Felipe:
# http://pseudo.co.de/ansible-cisco-csr1000v/
# http://anastarsha.com/automating-cisco-device-upgrades-with-ansible/
# https://networkop.co.uk/blog/2017/04/04/ansible-yang/
- id: "pdu02"
name: "my-cisco-router"
description: "This PNF represents a Cisco router CSR1000v"
geographical_location_info: "AthensNorth-room6-rack3-slot6"
vendor: "cisco"
version: "16.9"
model: "CSR1000v" # Can be used in the name Field/version?
element_manager: "PFSM" # External entity that will configure the PNF. Can be a FSM with ansible / RESTCONF / NETCONF
resource_requirements: # This is very PNF specific... Can be placed in the interfaces
throughput:
mbps: 100
requests:
reqs: 100
connection_points: # Related to RFC7223 -> https://tools.ietf.org/html/rfc7223#section-3
- id: "input"
interface: "Gi0/1"
type: "gigabitEthernet" # IANAifType -> https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
enabled: "True"
role: "service_input" # Will be used for the element manager to apply rules
description: "Input of the service"
- id: "output"
interface: "Gi0/2"
type: "gigabitEthernet" # IANAifType -> https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
enabled: "True"
role: "service_output"
description: "Output of the service"
# Manuel: This should not change, no?
connection_points:
- id: "mgmt"
interface: "ipv4"
type: "management"
- id: "input"
interface: "ipv4"
type: "external"
- id: "output"
interface: "ipv4"
type: "external"
# This section should not change. Should be the same as a normal VNF.
virtual_links:
- id: "mgmt"
connectivity_type: "E-LAN"
connection_points_reference:
- "pdu01:mgmt"
- "mgmt"
dhcp: True
- id: "input"
connectivity_type: "E-Line"
connection_points_reference:
- "pdu01:input"
- "input"
dhcp: True
- id: "output"
connectivity_type: "E-Line"
connection_points_reference:
- "pdu01:output"
- "output"
dhcp: True
| Attribute | Qualifier | Cardinality | Content | Description |
|---|---|---|---|---|
| pnfdId | M | 1 | Identifier | Identifier of this Pnfd information element. It uniquely identifies the PNFD. |
| provider | M | 1 | String | Identifies the provider of the PNFD. |
| version | M | 1 | Version | Identifies the version of the PNFD. |
| pnfExtCp | M | 1..N | PnfExtCpd | Specifies the characteristics of one or more connection points where to connect the PNF to a VL. See clause 6.6.4. |
| Attribute | Qualifier | Cardinality | Content | Description |
|---|---|---|---|---|
| cpdId | M | 1 | Identifier | Identifier of this Cpd information element. |
| layerProtocol | M | 1..N | Enum | Identifies a protocol that the connection points corresponding to the CPD support for connectivity purposes (e.g. Ethernet, MPLS, ODU2, IPV4, IPV6, Pseudo-Wire, etc.). |
| cpRole | M | 0..1 | String | Identifies the role of the connection points corresponding to the CPD in the context of the traffic flow patterns in the VNF, PNF or NS. For example an NS with a tree flow pattern within the NS will have legal cpRoles of ROOT and LEAF. |
| description | M | 0..1 | String | Provides human-readable information on the purpose of the connection point (e.g. connection point for control plane traffic). |
| Attribute name | Data type | Cardinality | Description |
|---|---|---|---|
| id | Identifier | 1 | Identifier of the onboarded individual PNF descriptor resource. This identifier is allocated by the NFVO. |
| pnfdId | Identifier | 0..1 | This identifier, which is managed by the PNFD designer, identifies the PNFD in a globally unique way. It is copied from the PNFD content and shall be present after the PNFD content is on-boarded. |
| pnfdName | String | 0..1 | Name of the onboarded PNFD. This information is copied from the PNFD content and shall be present after the PNFD content is on-boarded. |
| pnfdVersion | Version | 0..1 | Version of the onboarded PNFD. This information is copied from the PNFD content and shall be present after the PNFD content is on-boarded. |
| pnfdProvider | String | 0..1 | Provider of the onboarded PNFD. This information is copied from the PNFD content and shall be present after the PNFD content is onboarded. |
| pnfdInvariantId | Identifier | 0..1 | Identifies a PNFD in a version independent manner. This attribute is invariant across versions of PNFD. See note. |
| pnfdOnboardingState | PnfdOnboardingStateType | 1 | Onboarding state of the individual PNF descriptor resource. |
| onboardingFailureDetails | ProblemDetails | 0..1 | Failure details of current onboarding procedure. See clause 4.3.5.3 for the details of "ProblemDetails" structure. It shall be present when the "pnfdOnboardingState" attribute is CREATED and the uploading or processing fails in the NFVO. |
| pnfdUsageState | PnfdUsageStateType | 1 | Usage state of the individual PNF descriptor resource. |
| userDefinedData | Object | 0..N | User defined data for the individual PNF descriptor resource. This attribute can be modified with the PATCH method. |
| Name | Required | Type | Description |
|---|---|---|---|
| descriptor_id | yes | string | Identifier of this PNFD information element. It uniquely identifies the PNFD. The format will be defined in the data model specification phase. |
| function_description | yes | string | Describes the PNF function. |
| provider | yes | string | Identifies the provider of the PNFD. |
| version | yes | string | Identifies the version of the PNFD. |
| descriptor_invariant_id | yes | string | Identifier of this PNFD in a version independent manner. This attribute is invariant across versions of PNFD. |
| name | yes | string | Name to identify the PNFD. |
| geographical_location_info | no | TBD | Provides information about the geographical location (e.g. geographic coordinates or address of the building, ...) of the PNF. |
tosca.nodes.nfv.PNF:
derived_from: tosca.nodes.Root
properties:
descriptor_id: # instead of pnfd_id
type: string # GUID
required: true
function_description:
type: string
required: true
provider:
type: string
required: true
version:
type: string
required: true
descriptor_invariant_id: # instead of pnfd-invariant-id
type: string # GUID
required: true
name:
type: string
required: true
geographical_location_info:
type: TBD
required: false tosca.nodes.nfv.PnfExtCp:
derived_from: tosca.nodes.nfv.Cp
description: node definition of PnfExtCp.
requirements:
- external_virtual_link:
capability: tosca.capabilities.nfv.VirtualLinkable
relationship: tosca.relationships.nfv.VirtualLinksTo