Child pages
  • Contributions

ONF OIMT Contribution:

Approach to modelling a VNF or PNF

Version 0.0

2019/12/19

Author: Malcolm Betts ZTE

 

 

Version

Date

Description of Change

0.0

2019/12/19

Initial version.

 

 

1        IPR Declaration

Is there any IPR and/or Patentable Interest Declaration associated with this contribution NO

NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on ZTE or any other company. The requirements are subject to change in form and numerical value after more study. ZTE specifically reserves the right to add to, amend, or withdraw statements contained herein.

THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 


2        Background

During a discussion on one of the TAPI calls in December 2019 it was suggested that a VNF should be represented by a PC. This paper provides an analysis of the options for representing a network function that is independent of the implementation (in a VNF or PNF).

3        Discussion

3.1      CIM approach

Using a PC to represent a VNF has two problems:

1)     The CIM has several different “modules”: The “functional model modules” (e.g. TR 512.2, TR 512.3, TR 512.4) that represents network functions such as forwarding, layer translation etc.: The “physical model” (TR 512 6) is used to represent the “platform” that supports the functions.
Within the functional model some specialized artefacts e.g. LTP, FD, FC have been defined. These management abstractions are directly related to the widely used functional components identified in the network architecture. The PC (TR 512.11) can be used to represent any “infrequently used” functions. The description of these functions is independent of the underlying implementation. The Spec model is used to describe the capabilities (or limitations) of the functions.
The physical model is only used when it is necessary to expose the actual implementation for example to show the relationship between a function and the supporting hardware (or software). Typically, the relationship between the functions and the physical implementation is only exposed when a new instance of a function is created or it is necessary to take action to repair the “physical” support for a function that has failed. Again, the spec model is used to describe the capabilities (or limitations) of the hardware, typically in terms of the functions that the hardware can support.  Note that when a function is supported by “software” (TR 512.12) level of indirection is introduced, i.e. the hardware supports VMs which support the network functions.

 

2)     Some VNFs are quite complex, (e.g. firewall, DHCP server, WiFi base station etc.). In some cases, the VNF is the “virtual” equivalent of what could be supported in a physical box (or NE). To manage the functionality of a VNF, using the CIM, it is necessary to decompose the VNF into smaller functions (e.g. a set of interconnected LTPs, FDs, FCs and PCs).

Using this decomposition (defined in the CIM) makes the management of the network function independent of the physical implementation i.e. when managing the network function, it is not necessary to have a different model/interface for a virtual or physical implementation (i.e. there is no need to distinguish between a VNF and a PNF that are performing the same network function). The difference between a VNF and a PNF only becomes apparent when new instances are created or repair action is required.

4        Approach to modelling a network function

  • Since the Network Function is supported by a (possibly complex) assembly of functions, it may be appropriate to use the occurrence pattern document the assembly.
  • The set of functions defined by the occurrence pattern should be placed in a constraint domain.
  • The details of the set of functions (in the constraint domain) could be hidden by encapsulating the constraint domain in a Processing Construct (PC). Using this encapsulation, only the ports around the edge of the PC would be visible.

5        Next steps

  • Further discussion within OIMT
  • Socialize with TAPI:
  • Consider adding an example (Ethernet Switch)
  • Consider converting into a position paper