There has been a long debate on whether NS belongs to service or resource, and whether to support a separate class to model NS or do service extension to support NS. It seems like that we haven't have a unified conclusion on it, which hampers the modeling work on service and resource.
Therefore I suggest the modeling subcommittee to start 2 vote activities for it:
- A, NS belongs to service domain
B, NS belongs to resource domain - A, Support NS descriptor internally(in run time)
(NOTE: Choice A means that SDC supports the design and distribution of an independent NSD, also in the run time, the Orchestrator supports the orchestration and management of an independent NS.)
B, Do service extension to support NS and do not support NSD internally (in run time).
(NOTE: Choice B means that the extended SD should support what has been described in NSD and ONAP won't support the design work of an independent NSD internally.)
Please add your concerns and suggestions in this page.
We are going to start vote on the first question. For the second question, it still needs more discussion on that.
5 Comments
Arun Gupta
For NS to go from being a collection of resources to representing a service, the following is worth noting, quoted from the ETSI Open Source MANO white paper from May 2018, "Experience with NFV Architecture, Interfaces, and Information Models" (link to PDF): a drawback of the current NS model is that:
This is from section 4.6 of the white paper.
Kevin Scaggs
Some background and a position follows:
Background
Service Definition
Service – a collection of one or more resources that are connected together and are connected to other services to provide functional capabilities that, when deployed in a service provider’s network, can be packaged into a Product/Offer.
From an outside world perspective,
From an internal perspective,
Resource Definition
A Resource represents physical and non-physical (virtual) components which are owned / managed by the business or provided by a Supplier and are used (directly or indirectly) to construct services.
Resources may be, for example: human resources (skills and expertise), devices and accessories, components drawn from the Application, Computing and Network domains (network elements, software, computing resources), or information (data). Specifically, resources can include virtual network functions (Vnfs), physical network functions (Pnfs), allotted network functions (Anfs), as well as virtual links (Vls).
Multiple Suppliers may provide the same resource. Depending on availability and cost, a Service may be fulfilled using the Resources from one Supplier or another when ordered by a customer.
Resource – an individual functional capability that can be combined/connected with other individual capabilities to form a Service. This is a basic building block that is modeled generically, and when included in a service, can be customized to meet the needs of the service. Several different resource types are defined in ONAP:
Network Service from IFA014
The Network Service Descriptor (NSD) is a deployment template which consists of information used by the NFV Orchestrator (NFVO) for life cycle management of an NS.
An NS is a composition of Network Functions (NF) arranged as a set of functions with unspecified connectivity between them or according to one or more forwarding graphs. As illustrated in figure 4.1-1, the description of a NS as used by the NFV Management and Orchestration (MANO) functions to deploy an NS instance includes or references the descriptors of its constituent objects:
NOTE 1: The information contained within the PNFD is limited to the description of the connectivity requirements to integrate PNFs in an NS.
NOTE 2: An NSD references at least either one VNFD or one nested NSD.
A VNF Forwarding Graph Descriptor (VNFFGD) describes a topology of the NS or a portion of the NS, by referencing a pool of connection points and service access points, the descriptors of its constituent VNFs, PNFs and of the VLs that connect them. It may also contain one or more Network Forwarding Path (NFP) descriptors.
NOTE 3: Different VNFFGDs can be contained in a given NSD. Each VNFFGD uses subsets of the lists of VLDs, VNFDs and PNFDs included in the NSD.
NOTE 4: For a given NS different VNFFGs can result in packets/frames traversing identical sequences of (V)NFs, depending on the NFP descriptors included in the VNFFGDs.
NOTE 5: In a given VNFFG the connectivity topology represents how the (V)NFs among which packets/frames can be exchanged are connected to each other. A Network Connectivity Topology (NCT), as defined in ETSI GS NFV-SWA 001 [i.3] represents a higher logical level connectivity, possibly a global view of combined connectivity from different VNFFGs of a given NS.
Some reasons to model a NS as a service.
For NS to go from being a collection of resources to representing a service, a drawback of the current NS model is that:
This is from section 4.6 of the ETSI Open Source MANO white paper from May 2018, "Experience with NFV Architecture, Interfaces, and Information Models" - link to PDF
Xu Yang
ETSI NFV terminology definitions (from ETSI NFV003):
NOTE: The Network Service contributes to the behaviour of the higher layer service, which is characterized by at least performance, dependability, and security specifications. The end-to-end network service behaviour is the result of the combination of the individual network function behaviours as well as the behaviours of the network infrastructure composition mechanism.
NOTE: In practical terms, a Network Function is today often a network node or physical appliance.
John Quilty
Missing option C . Develop Model so that NS can be represented in either domain
Lingli Deng
As far as I understand, the intention for the first poll is to determine where to continue the work which has been started from Casablanca, which it has been put to resource domain. Currently, we have two separate weekly threads, one for resource modeling discussion and the other for service modeling discussion. We need to decide which forum to use for followup NS modeling discussion.
From my personal perspective, I understand comments from both sides, and would go for either option the group decides or recommend (or even option C, a third thread if needed), as long as we get a place to land this work.
My 2 Cents.