Priority1
SummarySupport PNF modeling and associated workflow design in SO.
Use CasesAll
R1 StatusSupported by SDC and A&AI. Not supported by SO.
R2 Status

In order to orchestrate interfaces to physical devices and equipment it is necessary to model them.

Some use cases may chose to model existing infrastructure to which ONAP managed services will connect as Physical Network Functions.



Project

Impact

SDC

Visualize and model PNFs.

SO

Orchestrate services depending on PNFs.

SDN-C

Implement PNF connections.

MULTICLOUD

Support plug-in adapter enabling access to PNF attributes.

2 Comments

  1. Srinivasa Addepalli

    In 5G use case meeting on Oct 26th,  there is very good discussion on PNFs and their usage from ONAP.

    Few challenges/solutions we discussed are:

    1. How does ONAP know the PNF IP addresses, mainly when PNF gets the IP addresses dynamically from DHCP? Two possible mechanisms were discussed.
      1. During onboarding of PNF in ONAP,  PNFD is expected to be provided with  MAC address of the PNF & DHCP Server IP address.  ONAP at run time (first time and periodically) get the IP address of the PNF by referring to the DHCP server using MAC address.
      2. During onboarding of PNF in ONAP,   PNFD is expected to be provided with FQDN of PNF and DNS Server IP address.  ONAP uses this FQDN to get the IP address assigned to the PNF.  This requires capability in PNF to update its DNS Server with its host name and IP address it got from local DHCP Server.
    2. How does PNF made known about ONAP service IP addresses?  For example PNFs need to know about DCAE service IP address to send VES logs. It also need to know the credentials it should use to talk to DCAE.  In case of VNFs, this information is passed as user data (cloud-init) to VNFCs.  A mechanism was discussed
      1. Let PNF expose netconf/yang for APP-C to program this information.
    3. Actual network function configuration of PNF.
      1. If it is L3 and below, it is SDN-C that configures the PNF.  For example, slice configuration (in case of 5G) is below L3 and hence SDN-C would program PNF.
      2. If it is L4 and above, it is APP-C that configures the PNF.
      3. Yang/Netconf model driven approach is right thing to be supported.
    4. Support for legacy PNFs:  There could be a need to support PNFs that are not ONAP ready (that is, they may not support Netconf/yang, may not support VES and other ONAP specific functionality)
      1. Some kind of translation modules are required outside of ONAP.  Legacy PNFs with this translation appear as  ONAP-ready PNFs to ONAP.


    Correct me if I did not capture the discussion well.

    Thanks

    Srini


  2. Rebecca Lantz

    Is there any update to PNF modeling?   R1 status indicates not supported by SO, was this support added in R2?  Anything planned for R3?