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.
This example shows a Service template consuming a PNF Firewall resource.
7 Comments
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?
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.
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?
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.
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:
I'll try to create TOSCA code to make this more clear.
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.
Chris Lauwers
Here is an alternative that combines substitution mapping and selectable node templates:
This example should be fleshed out by