Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1) Management of the application-specific functionality of a VNF is envisioned by ETSI NFV as being handled by OSS/BSS that are considered as SM/NM/EM, and outside of the scope of ETSI NFVO and VNFM functionality.  ETSI NFV is currently silent about how such application level management is to be performed for a given VNF.  This can be seen by the lack of specification of the EM to VNF interactions in Fig 5-1 below, as well as in the delegation of application configuration to the EM in the highlighted portions of the figure labeled B.3.2.2 below.  (Figures taken from ETSI GS NFV-MAN 001 V1.1.1, 2014-12).  In other words, It seems that the ETSI NFV community assumed took the perspective that there were already well-established systems, precedence and standards around the BSS/OSS tools (e.g., SM/NM/EM) needed to manage non-virtualized network functions  Service Providers already the tools what was "new" with NFV wastraditional Network Functions (i.e., PNFs), and the job of ETSI NFV therefore was to put standards around that which was new: how to instantiate and managed "Virtualized" Network Functions to the point that they can look to the established systems (SM/NM/EM) indistinguishable from "traditional Network Functions".


2) In the context of Figure B.3.2.2 above, "deployment specific parameters" should be understood as that subset of VNF configuration data that must be applied in the VNF in order to make it an endpoint capable of being managed by the non-ETSI NFV OSS/BSS/SM/NM/EM. 

...