Objective

Represent PNFs in the TOSCA model, using TOSCA syntax and semantics to define the mapping between PNF resources used in ONAP services and the physical devices themselves.

PNF Modeling - Resources and Devices

The proposed approach is to use a node type derived from NetworkFunction to represent the PNF’s appearance as a resource in services, and a separate “PNF Device” node type to represent the device itself (in the model and in inventory).  TOSCA requirements and capabilities are used to map the PNF resources within services to their corresponding PNF Devices.

As is typical, PNF devices are pre-populated in inventory before they are assigned for use by services.  This makes them a good candidate for Requirements/Capabilities logic, where the PNF Resource has a dangling requirement for a PNF Device.  The mapping would be established at run-time by selecting which pre-deployed (and inventoried) PNF Device is to be used.

In this model, a new PNFDevice Capability base type is defined.  Individual PNF devices would declare this capability (or one derived from it).  Their matching PNF Resource types would declare a requirement for its PNF Device capability.  The resulting relationship would link the network function (PNF resource) to the physical device (PNF device) as a hosted on relationship.

PNF Resources are modeled as peers to VNFs and Allotted Resources, all being derivations of a base “Network Function” node type.  There is no explicit node type for PNF Resource.    This permits the three types to be used interchangeably in Abstract Node resolution.  The three resource types (VNF, PNF, AR) do not require explicit subtypes, but instead are identified by their defined requirements:

  • Allotted Resources have a requirement for an Allotted Resource Provider service
  • PNF Resources have a requirement for a PNF Device
  • VNF Resources have neither A-R Provider nor PNF Device requirements.

Examples

This example shows a specific PNF device, along with the PNF resource that it exposes for use in ONAP services.

PNF Example 
# A specific capability for this firewall PNF device
capability_types:
   vendor.capabilities.pnfDevice.MyFirewall:
      derived_from: onap.capabilities.PNFDevice
      description:  Declaration of being a specific PNF Device

# node types for the Firewall PNF device and corresponding PNF Resource
node_types:
   vendor.nodes.devices.pnfs.MyFirewall:
      derived_from: onap.nodes.PNFDevice
      description:  A PNF Firewall Device
      properties:
         # as needed
      attributes:
         # as needed
      capabilities:
         pnf_device:
            type:  vendor.capabilities.pnfDevice.MyFirewall

   # My Firewall PNF Resource node type.
   # Note that this could derive from an abstract Firewall node type for run-time selection.
   vendor.nodes.resources.network_functions.MyFirewallPNF:
      derived_from: onap.nodes.resources.NetworkFunction
      description:  A PNF Firewall Resource
      properties:
         # as needed
      attributes:
         # as needed
      requirements:
      - pnf_device:
            capabilities:
               type:  vendor.capabilities.pnfDevice.MyFirewall
               relationship: onap.relationships.PNFHostedOn
               node: vendor.nodes.devices.pnfs.MyFirewall


This example shows a Service template consuming a PNF Firewall resource.

Service using PNF 
node_templates:
   # Node for the PNF Firewall Resource.
   # Note that the requirement for PNF Device was declared in the MyFirewallPNF node
   # type, and hence does not need to be restated here.
   my_pnf_firewall:
      type:  vendor.nodes.resource.network_functions.MyFirewallPNF
      properties:
         # as needed
      attributes:
         # as needed
  • No labels

7 Comments

  1. maopeng zhang

    Hello,

        I see there is similar topic "PNF resource IM proposal". It is based on ETSI SDO and discussed in the 5G usecases.

        Should those about PNF model be align?

  2. Chesla Wechsler

    Maopeng, I'm reviewing the PNF resource IM proposal now.  I believe having a direction for an internal data model which abstractly represents NetworkFunctions such that PNFs or VNFs (or allotted network functions) can resolve them is a good plan.  The onboarding model of the PNF and VNF ought to be able to map into that structure.  We would like to collaborate across the community on this thinking during Casablanca so that we have a Dublin proposal for an improved, consolidated, internal data model.    In Casablanca, I would like if, at the INFO model level, we could introduce a base NetworkFunctionDesc class from which VNF and PNF derive.  Some of the fields would be experimental (not implemented in Casablanca) but at least start contributing to a direction.

    1. maopeng zhang

      PNF and VNF Topology and features are distinct, and their management are distinct flows.

      Do you mean that only VNF and PNF TOSCA nodes inherit a base NF node? 

      1. Chesla Wechsler

        I actually do not want VNF and PNF to inherit from a base NetworkFunction.  I'd like to see NetworkFunction's have different dependencies if they are physical (they need a PNFDevice), allotted (they need a providing service) or neither.

        1. Chris Lauwers

          I agree, having a single NetworkFunction node type without derived types is the way to go.

          However, i think there may be a more elegant way to model PNFs than what you're proposing. If I understand correctly, you're effectively modeling a "dummy" NetworkFunction node that has a (dangling) requirement for the real PNF. While this will work, I'm concerned that this approach doesn't do a very good job of representing the physical reality. 

          There might be a simpler way to accomplish the same thing by combining substitution mapping and selectable nodes:

          • the abstract NetworkFunction node gets substituted by a "PNF service template" that itself includes a NetworkFunction node. In this service template, the NetworkFunction node template is selectable (meaning it includes a node filter)
          • The selectable NetworkFunction node template is resolved by the orchestrator by finding the "matching" PNF from Inventory.

          I'll try to create TOSCA code to make this more clear.

          1. Chesla Wechsler

            Chris Lauwers, I'd be very interested in the TOSCA, especially how it retains the abstraction where a service topology template can indicate where it contains  a NetworkFunction with capabilities for which PNFs, VNFs, and ANFs, can possibly be selected.  Do you have a timeframe?  Anatoly Katzman and Michela Bevilacqua will probably be interested as well, and perhaps Benjamin Cheung.

  3. Chris Lauwers

    Here is an alternative that combines substitution mapping and selectable node templates:

    • The same Firewall node type is used for all network functions that provide firewall functionality, independent of whether those firewalls are physical, virtual, or allotted. A network service template that includes a firewall will have abstract node templates of this Firewall type. 
    Firewall Network Function 
    node_types:
  onap.nodes.functions.Firewall:
    derived_from: onap.nodes.NetworkFunction
    properties:
      classification:
        constraints:
          - equal: {type: "Firewall"}
    requirements:
      - untrusted:
          capability: onap.capabilities.Linkable
      - trusted:
          capability: onap.capabilities.Linkable


    • At deployment time, the abstract Firewall node template needs to get substituted with a concrete implementation. This concrete implementation can be virtual, allotted, or physical. In the case of a physical Firewall (a PNF), the substituting template will include a 'selectable' node template that requires the orchestrator to find ('select') the appropriate PNF from inventory, as follows:


    Physical Firewall Template 
    # node type for the Firewall PNF device
node_types:
  vendor.nodes.devices.pnfs.MyFirewall:
    derived_from: onap.nodes.PNFDevice
    description:  A PNF Firewall Device
    requirements:
      - untrusted:
          capability: onap.capabilities.Linkable
      - trusted:
          capability: onap.capabilities.Linkable

topology_template:

  substitution_mappings:
    node_type: onap.nodes.functions.Firewall
    properties:
      firewall_rules: [ firewall_rules ]
    requirements:
      trusted:    [ firewall, trusted ]  # Trunk to trusted network
      untrusted:  [ firewall, untrusted ]  # Trunk to untrusted network

  node_templates:

    firewall:
      type: vendor.nodes.devices.pnfs.MyFirewall
      directives: 
        - selectable # Technically redundant, since the presence of
                     # the 'node_filter' implies that this node is
                     # 'selectable'
      node_filter:
        properties:
          # property filter values drive selection of the appropriate
          # firewall PNF device. These values are intended to be
          # provided as inputs, and by implication come from the
          # substituted (abstract) node template in the service
          # template that contains the firewall node template


    This example should be fleshed out by

    • Using "real" NetworkFunction node types
    • Adding firewall-specific configurable properties
    • Creating substituting templates for virtual and allotted firewalls (as well as physical firewalls)
    • where the substitution is driven by the actual properties defined in the firewall network function node type.