Description

A NetworkFunction is a resource which is able to fulfill a well-defined, non-trivial functionality for a service.

...

-          the nf_classification property - provides useful data governed filtering criteria, whose values should not be used in any ONAP platform logic but which could be used in model-specific logic.

-          the name of a sub-type - no ONAP platform logic should ever use the name of a sub-type. 

It is non-trivial in many senses. First, a NetworkFunction is non-trivial in terms of its connectivity with the outer world. A NetworkFunction-based type is normally defined with multiple capabilities and requirements of different types, which are serving different purposes. Since there is no typical “connectivity set” shared by all function, it cannot be captured by means of TOSCA in the base NetworkFunction node type. That is, the NetworkFunction node type is practically unusable per se. It needs to be further sub-typed, along with extending it with additional capabilities and requirements.

A NetworkFunction is also non-trivial in terms of its internal structure. A NetworkFunction normally has its own internal topology that spans over multiple VMs and has internal networks. A NetworkFunction-typed node is expected to be implemented through substitution. This substitution can be specified by the service designer in design time. However, the service designer may also leave a NetworkFunction-typed node without design-time implementation. In this case, the most appropriate substitution should be found by the Orchestrator in run time.

Whether a NetworkFunction is Virtual, Physical, or Allotted is determined based on its other requirements.  

• A NetworkFunction that requires a PNF Device (i.e., a custom hardware element preinstalled into the network) is a Physical Network Function, PNF
• A NetworkFunction that requires a Providing service is an Allotted Resource (e.g., a Firewall as a Service offering, or an embedded network function in a network operating system)
• A NetworkFunction with neither of these requirements in a VIrtual Network Function, or VNF.

By avoiding subtyping NetworkFunction into physical, virtual, etc., the type hierarchy needed for abstract runtime resolution is preserved.  This permits the platform to select concrete types which satisfy the service requirements using the non-normative OASIS recommendation on abstract resolution based on type through operator specified means such as policy. 

It may be advantageous to derive some classic network functions such as firewall, router, load balancer, etc., from NetworkFunction.  Doing so still preserves the ability to use abstraction to represent a network function within a Service that uses it. 

TODO: explain why this type does not have any capabilities and requirements

Properties

Attributes

Nothing special

Capabilities

TODO: explain why this type does not have any capabilities and requirements

Requirements

TODO: explain why this type does not have any capabilities and requirements

TOSCA Definition

node_types:
   onap.nodes.Resource.NetworkFunction:
    description: |
      a base of the ONAP hierarchy of network functions
      If you have a requirement for a factory, you're allotted
      If you have a requirement for a PNFdevice, you're physical 
      If you have neither, you're virtual.
      Expect to see network functions be group members for naming and homing.
    derived_from: onap.nodes.Resource
    properties:
      # classification is inherited from onap.nodes.Resource, type, role, function should be required
     nf provider_classificationdetails:
        descriptiontype: |onap.datatypes.ProviderDetails
        required: false
  data governed valueattributes:
used by operations to filter network functionslocalization_language:
        type: onap.datatypes.NetworkFunctionClassification  SOME STANDARD ENUMERATION MUST EXIST
        required: true: false
        description:  instance-specific localization chosen for driving human-readable interfaces
      
      
    capabilities:
      # Expect to define these in the derived node_type, with mappings to appropriate the NetworkFunctionComponent CP
      # This exposes external CPs of the NF.
    requirements:
      # Expect to define these in the derived node_type, with mappings to appropriate inner nodes
	  

Examples

The examples below show possible type definitions of a firewall network function abstraction.

The type AbstractFirewall defines the basic set of properties and connectivity requirements shared by absolutely all firewall networking functions in the world. It captures the fact that a firewall is normally connected to at least 2 networks, and these networks are given descriptive names.

...

node_types:
  onap.nodes.functions.AbstractFirewall:
    derived_from: onap.nodes.FunctionNetworkFunction
    properties:
      nf_classification:
        constraints:
          - equal: {nf_functiontype: "Firewall"}
    requirements:
      - unprotected:
          capability: onap.capabilities.Linkable
      - protected:
          capability: onap.capabilities.Linkable
      

The type VerySpecialFirewall below is an example of how could look a concrete firewall node type provided by a vendor could look. This vendor-specific type extends the connectivity schema of its basic type by the connection to an additional management network.

node_types:
  vendorXXX.nodes.VerySpecialFirewall:
    derived_from: onap.nodes.functions.AbstractFirewall
    requirements:
      - management:
          capability: onap.capabilities.Linkable  

A NetworkFunction is a resource which is able to fulfill a well-defined, non-trivial functionality for a service.

Well-defined means that its specialty can be captured by a word understandable across the industry, such as a firewall, a router, a load balancer, etc. 

It is non-trivial in many senses. First, a NetworkFunction is non-trivial in terms of its connectivity with the outer world. A NetworkFunction-based type is normally defined with multiple capabilities and requirements of different types, which are serving different purposes. Since there is no typical “connectivity set” shared by all function, it cannot be captured by means of TOSCA in the base NetworkFunction node type. That is, the NetworkFunction node type is practically unusable per se. It needs to be further sub-typed, along with extending it with additional capabilities and requirements.

A NetworkFunction is also non-trivial in terms of its internal structure. A NetworkFunction normally has its own internal topology that spans over multiple VMs and has internal networks. A NetworkFunction-typed node is expected to be implemented through substitution. This substitution can be specified by the service designer in design time. However, the service designer may also leave a NetworkFunction-typed node without design-time implementation. In this case, the most appropriate substitution should be found by the Orchestrator in run time.

...

...

The type SpecialAllottedFirewall below is an example of how a concrete node type that is allotted from some larger infrastructure firewall service could look. This specific type extends the connectivity schema of its basic type by the connection to an additional management network.  It also adds an allotted resource provider requirement, which designates it as an allotted resource (the providing service itself is not shown).

 node_types:
  onapvendorYYY.nodes.Resource.NetworkFunctionSpecialAllottedFirewall:
    description: |
      a base of the ONAP hierarchy of network functionsderived_from: onap.nodes.functions.AbstractFirewall
      If you have a requirement for a factory, you're allottedrequirements:
      - management:
      If you have a requirement for a PNFdevice, you're physical 
      If you have neither, you're virtual.
      Expect to see network functions be group members for naming and homing.
    derived_from capability: onap.nodescapabilities.Resource
Linkable
   properties:    -   nfprovider_classificationservice:
        description node: |vendorYYY.service.AllottedFirewallProviderService
          data governed value used by operations to filter network functions
        typecapability: onap.datatypescapabilities.NetworkFunctionClassificationAllottedResourceProvider
        required: true
    capabilities:
      # Expect to define these in the derived node_type, with mappings to appropriate the NetworkFunctionComponent CP
      # This exposes external CPs of the NF.
    requirements:
      # Expect to define these in the derived node_type, with mappings to appropriate inner nodes

Examples

 relationship:  onap.relationships.AllottedBy 

The type SpecialPhysicalFirewall below is an example of how a concrete node type that is a traditional PNF could look. This specific type extends the connectivity schema of its basic type by the connection to an additional management network.  It also adds a PNFDevice requirement, which designates it as physical network function.

 node_types:
  onap vendor.nodes.resources.network_functions.AbstractFirewallMyFirewallPNF:
     derived_from: onap.nodes.Resources.FunctionNetworkFunction
  properties:     nf_classificationdescription:       constraints:
        - equal: {nf_function: "Firewall"}
  requirements:A PNF Firewall Resource
      - unprotectedproperties:
       # capability: onap.capabilities.Linkableas needed
    - protectedattributes:
       # capability: onap.capabilities.Linkable
      
  vendorXXX.nodes.VerySpecialFirewall:
    derived_from: onap.nodes.functions.AbstractFirewallas needed
     requirements:
      - managementpnf_device:
 
        capability: onap.capabilities.Linkable  

Examples

node_types:
  onap.nodes.functions.AbstractFirewall:
  derived_from: onap.nodes.Function   properties:     function:       type: string
      constraints:
        - equal: "firewall"
  requirements:     - unprotected:
        capability: onap.capabilities.pnfs.LinkableMyFirewall
    - protected:         capabilityrelationship: onap.capabilitiesrelationships.LinkablePNFHostedOn
      
  vendorXXX.nodes.VerySpecialFirewall:     derived_fromnode: onapvendor.nodes.functions.AbstractFirewall
    requirements:
      - management:
          capability: onap.capabilities.Linkable  

devices.pnfs.MyFirewall