Vote for NS domain and Internal NS Descriptor

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: 

• it does not give expression to the holistic properties of an NS that are beyond the properties of the components and that can occur in all four of the areas of control – configuration, capacity, fault, and performance;

This is from section 4.6 of the white paper.

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,

•  a Service represents assets (Resources) assembled by the business for use in the realization/implementation of a delivered capability (Product) and/or for use within the organization
•  the business may develop Services using Resources produced and managed by multiple organizations. 
• Services have a defined behavior and set of characteristics
• A Service has external connection points (Cps) or network links (virtual or physical).

From an internal perspective,

• Services are constructed / designed, providing some capability that is 'greater' than the parts.
• Services can be decomposed into other services and/or resources
• Service must be 'homed' in the context of the service,

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:

• Virtual Function (VF) / Virtual Network Function (VNF)
• Virtual Function Component (a subcomponent of a VNF)
• Connection Point
• Virtual Link (VL)
• Allotted Resource (AR)
• Collectors and other Resource types (to be described in more detail in future versions)

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:

• Zero, one or more Virtualised Network Function Descriptors (VNFD);
• Zero, one or more Physical Network Function Descriptors (PNFD) used by the NFVO to determine how to connect PNFs to VLs;
• Zero, one or more nested NSD;

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.

• Zero, one or more Virtual Link Descriptors (VLD) used by the NFVO to deploy Virtual Links (VL); and
• Zero, one or more VNF Forwarding Graph Descriptors (VNFFGD).

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.

1. Modeling a Network Service as an ONAP “Service” results in less administrative overhead for Service Designers.      In ONAP, homing occurs on individual Network Functions (Resources) only within the context of a “Service”.  If we want ONAP to perform “homing” for (the Network Functions that comprise) a Network Service, then      that Network Service must exist in some “Service context”.  If we      were to model an onboarded Network Service as a “Resource”, then the      Service Designer would need to create an encompassing “Service”, even in      the cases whereby the Service Provider wants ONAP to only perform the equivalent functionality of an NFVO+VNFM relative to the Network Service.  This would result in additional administrative overhead during service design.  Modeling the onboarded Network Service as an ONAP “Service” would avoid this unnecessary overhead.
2. The desired runtime behavior for ONAP support of a Network Service is more closely aligned to the desired runtime behavior of an ONAP “Service” In the ONAP instantiation scenario, runtime processing of an ONAP “Service” entails decomposition into its component Network Functions, each Network Function then being “homed”, followed by orchestrated instantiation of the now-homed component Network Functions in the proper sequence.  For an onboarded Network Service, the desired runtime behavior is for ONAP to decompose that Network Service into its component VNFs, “home” each of those VNFs to the proper cloud instance, and then orchestrate the instantiation of those now-homed VNFs in the proper sequence.
3. Modeling a Network Service as a Resource results in additional complexity being needed in “Homing” In ONAP, homing takes place on a decomposed set of Resources, each Resource being “homed” separately in the context of the “Service” to which it belongs.  A Resource can have internal complexity, however “homing” doesn’t take place on these internal components.  (E.g., a      VNF is homed holistically, and not each VF Module within that VNF.)       If we were to model a Network Service as a Resource, and if we want ONAP to “home” the component VNFs that comprise that Network Service, then      additional complexity will be needed in ONAP to perform homing on “sub-Resource” level objects.
4. A NS is a 'beginning' of a service, and hence is not a resource.

1. For NS to go from being a collection of resources to representing a service,  a drawback of the current NS model is that: 

   • it does not give expression to the holistic properties of an NS that are beyond the properties of the components and that can occur in all four of the areas of control – configuration, capacity, fault, and performance;

   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

2. In order for a NS to be a service, more is needed (attributes, relationships, ...).   In other words a NS can be incorporated into the existing service descriptor and instance classes.

ETSI NFV terminology definitions (from ETSI NFV003):

• network service: composition of Network Functions and defined by its functional and behavioural specification

        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.

• Network Function (NF): functional block within a network infrastructure that has well-defined external interfaces and well-defined functional behaviour

        NOTE: In practical terms, a Network Function is today often a network node or physical appliance.

• Virtualised Network Function (VNF): implementation of an NF that can be deployed on a Network Function Virtualisation Infrastructure (NFVI)
• Physical Network Function (PNF): implementation of a NF via a tightly coupled software and hardware system

Missing option C . Develop Model so that NS can be represented in either domain

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.