Skip to end of metadata
Go to start of metadata

Based on timeplan of modeling subcommittee, high level requirements need to be finished by M0, 

There are 4 categories of high level requirement,

The first category is that those requirement will be implemented and commited by the impacted projects in this release

the second category will document the current implementation in those projects.

Other two categories like lower priority and experimental will not be included in the release 3, the contributor will work with best effort to influence future release.

Owners of each requirement needs to coordinate the modeling spec commitment and code commitment with PTLs of impacted project.

1) Will be implemented and included in the release 3


Modeling Domain

Modeling Requirement

Modeling Requirement Description

Impacted

Projects

Use Case

Relevance

Modeling Spec

Commitment

Code

Commitment

Provider

Priority

Mapping to M1 requirementOwner

Resource

VNFD

ONAP Resource Data Model for Design Time?

-Agreement that the VNF Descriptor model for On-Boarding and the Internal ONAP models are distinct. (note: an internal model may be used as one of the on-boarding options)
•For R3 the VNF Descriptor On-Boarding options include: HEAT and TOSCA (SOL004 v2.5.1 VNF Package, ONAP R3 Resource DM) (see note)
-Acknowledgement that there are two Internal ONAP VNF Descriptor Data Models that, for R3, will evolve wherever possible in a coordinated way in support of the Casablanca Use Cases
•ONAP R2+ Design-Time Resource DM clean version enhancements for VoLTE, CCVPN, vCPE (stretch goal)
•ONAP SDC TOSCA AID enhancements for vCPE
-Engage impacted ONAP Components to understand the VNF Descriptor aspects of these two Internal ONAP R3 Resource Data Models are applied
•Document ONAP R3 VNFD on-boarding and internal models roadmap with all ONAP components stakeholders

SDC

A&AI

OOF

SO

VFC

Policy

VoLTE

VCPE

CCVPN

AT&T

Intel

AT&T

Intel

AT&T: High

SDC (Y)

A&AI (Y)

SO (Y)

OOF(Y)

Policy (Y)

VFC (Y)

 PNF for 5G

 software version


SDC

SO

 5G
 Nokia

SDC (Y)

SO (Y)



2) Documentation after implemented, or implemented but not in the release

Modeling Domain

Modeling Requirement

Modeling Requirement Description

Impacted

Projects

Use Case

Relevance

Modeling Spec

Commitment

Code

Commitment

Provider

Priority

Mapping to M1 requirement Owner

 Service

 

Service Order

It includes the definition of the managed objects that allows a BSS system to create/delete/update/get an order of a service to a ONAP instance. The Service Order Modeling provided by Ext API R2 team must be reviewed to become part of the ONAP common service IM

(Service Order - Information Model View)

Ext API(y)

VoLTE

CCVPN

Change Mgt


CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Orange

CMCC

Huawei

ZTE

Vodafone

Orange

CMCC: High

Vodafone: High

AT&T:  High

Verizon-High

ExtAPI

(Y)

Andy Mayer (AT&T)

 Service Catalog A Service Catalog is a group of ServiceDescriptors that an organization provides to the consumers via ONAP.

https://wiki.mef.net/display/CESG/Service+Catalog

Ext API VoLTE

CCVPN

CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Orange

CMCC

Huawei

ZTE

Orange

CMCC: High

Vodafone: High

AT&T:  High

Verizon-High

ExtAPI

(Y)

 Kevin Scaggs (AT&T)

 Service Descriptor

Design time model: service descriptor model,

document the existing service model in SDC

Ext API

SO

SDC

(All)

VoLTE

CCVPN

5G

vCPE

CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Orange

CMCC

Huawei

ZTE

Orange

CMCC: High

Vodafone: High

AT&T: High

Verizon-High

SDC (Y)

EXTAPI(Y)

SO(Y)

LIN MENG

(CMCC)

Resource  LicensePresently modeled and used in SDC,

(ONAP license model)

SDC (No impact, information providing only)


 AT&T

Verizon


 AT&T:  Medium

Verizon-Medium

SDC (Y) Kevin Scaggs(AT&T)
Alloted resource

1 document the existing SDCs current implementation

2 continue to work on the feature. (maybe some implementation will follow these features)

SDC AllAT&T

Intel

AT&T

Intel

AT&T: High SDC (Y)

Andy Mayer (AT&T)

Scaling (HEAT template) Scaling Use Case Extension .

Casablanca focus: Document the Policy Model that is being implemented by the ONAP Policy Framework.

SDC (no impact)

A&AI (no impact)

SO (no impact)

Policy

Clamp (no impact)

 vDNS (Scaling)

AT&T


CMCC: Medium

Vodafone: Medium

AT&T:  High

SDC (no impact)

A&AI (no impact)

SO (no impact)

Policy (Y)

Clamp (no impact)

 Andy Mayer (AT&T)

Gil Bullard ((AT&T)

ResourceComposite
  • the composition relationship between different resources which is implemented by the current SDC code shall be documented
  • the semantics rules of the current SDC/VNFSDK implementation shall be documented; potential new rules would be captured and brought back to SDC for the next release
SDC

VNFSDK(y)

 VoLTE

CCVPN

CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Intel

CMCC

Huawei

ZTE Intel

CMCC: High

Vodafone: High

AT&T:  High

Verizon-High

SDC (Y)

VNFSDK

(Y)

 Network Service

1 create a data model for network service

SDC

VFC

VoLTE

CCVPN

5G

CMCC

Huawei

ZTE

AT&T

CMCC

Huawei

ZTE

 CMCC: High

Vodafone: High

AT&T:  Medium

SDC (Y)

VFC (Y)

 Chuyi Guo

Telemetry

Events & VES

VES Event Descriptor Model according to VES spec v6.0

DCAE

SDC


AT&T

Verizon


AT&T:  High

Verizon-High

DCAE(Y)

SDC (Y)


Below tables are not downgrade, but casablanca won't make it

3) Lower Priority:

Modeling Domain

Modeling Requirement

Modeling Requirement Description

Impacted

Projects

Use Case

Relevance

Modeling Spec

Commitment

Code

Commitment

Provider

Priority

 Owner

Service


servicecomposite Design/run time model : Service IM review according to the agreed Service Composite pattern. (Composite Pattern UML diagram) SDC (L)

Ext API (=SDC)

SO

 VoLTE

CCVPN

 CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

 CMCC

Huawei

ZTE

CMCC: High

Vodafone: High

AT&T:  High

Verizon-High

 Service Scaling A run time service instance could be updated by scaling in/out its capacity via deleting/adding new resources instances, e.g. sites in CCVPN usecase. SDC

SO

AAI

VoLTE

CCVPN

CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon


 CMCC: High

Vodafone: High

AT&T:  Medium

Verizon-Medium

Service Instance

Run time model: service instance model

in relation to the design time model and Service Composite pattern. (Composite Pattern UML diagram)

A&AI

Ext API

SO

SDC

(All)

VoLTE

CCVPN

vCPE

 CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Orange


CMCC: High

Vodafone: High

AT&T: High

Verizon-High

Resource

 

ResourceComposite

Design time model: Resource composite model introduction according to the agreed Service Composite pattern. It includes the NS model review from Service component to Resource Composite and change of Modeling Domain (Composite Pattern UML diagram)

The ResourceComposite includes below sub-requirements:

  • support composite pattern (i.e., ResourceAtomic and ResourceComposite) in the IM and DM

SDC(->)

VNFSDK

VoLTE

CCVPN


CMCC

Huawei

ZTE

Vodafone

AT&T

Verizon

Intel

CMCC

Huawei

ZTE
Intel


CMCC: High

Vodafone: High

AT&T:  High

Verizon-High


 Network Service

(modeling subcommitee  DM approve firstly)

Context:
  1. In R2 VoLTE case, SDC support VoLTE service composed of IMS/EPC service as VNF. IMS/EPC Service can be composed of VNF, and VLD resources.
    In service layer, VOLTE service should focus on the IMS/EPC/... service composition, not coupled with the specific IMS/EPC/... resource composition. In the different scenes, IMS service can be implemented in different resources layer, for example, small capacity or large capacity, VNF in one DC or VNF on multiDC, even all PNFs or PNFs/VNFs, etc The multiple resource composition should not affected the service design. So network service is introduced, which is in charge of different IMS resource composition and let the service design not coupled with the resource composition design in detail.
  2. TMF support service and resource, and also in resource layer, there is resource composite. and Network service from ETSI can be mapping to the resource composite
  3. model subcommittee progress:

Network service is agreed in resource IM group. Networkservice IM Network service Descriptor has been discussed in DM group. Networkservice DM

4. SDC progress

org.openecomp.resource.vfc.NSD has been imported in ONAP catalog in R2 https://gerrit.onap.org/r/gitweb?p=sdc.git;a=tree;f=catalog-be/src/main/resources/import/tosca/nfv-types/NSD;h=bf5cabb52dc41025f4708c7c095e304196e7e6a6;hb=refs/heads/master

SDC functionality does not support NSD yet in R2

SDC requiremnets in R3:

1. SDC design UI, catalog(FE,BE,Database, API) shall support NS and related package based on R2 link

2. In resource design, NS descriptor shall be composed of VNFD, and VLD at least to support VoLTE based on R2 resources

3. In service design, service descriptor could be composed of the NSD.

4. NS descriptor shall refinement to support R3 NS DM Proposal( Stretch goal)

SDCVoLTE

CCVPN

5G

CMCC

Huawei

ZTE

AT&T

CMCC

Huawei

ZTE

CMCC: High

Vodafone: High

AT&T:  Medium

Chuyi Guo
 VNF instance (run time) Run time model of a VNF instance

(low)

 A&AI VoLTE

CCVPN

5G

vCPE

CMCC

Huawei

ZTE

AT&T

Verizon
Intel

CMCC

Huawei

ZTE

CMCC: High

Vodafone: High

AT&T:  High

Verizon-High

 Kevin Scaggs (AT&T)
PNF instance (run time)Run time model of a PNF Instance.SDNC

A&AI

SO

VoLTE

CCVPN

5G

CMCC

Huawei

ZTE

Vodafone

CMCC

Huawei

ZTE

CMCC: Medium

Vodafone: Medium

Victor Gao
 WAN Connection Wan Connection Information Model


SDC(->)

SO

A&AI

SDNC

VoLTE

CCVPN

CMCC

Huawei

ZTE

AT&T

Verizon

CMCC

Huawei

ZTE

CMCC: High

Vodafone: High

AT&T:  Medium

Verizon-Medium

Zhuoyao HUANG
SD-WANCCVPN SD-WAN Information Model

CMCC

Huawei

AT&T

Verizon


CMCC: High

Vodafone: High

AT&T:  Medium

Verizon-High

chuanyu chen
ElementGroup enhancement

(lower)

Tied to modeling of Scaling, Homing, Placement, etc.SDC

SO


 AT&T
 AT&T:  MediumAndy Mayer (AT&T)

Infrastructure

Multi-cloud

The cloud abstractions needed for homing in the edge cloud across public cloud and service-provider-owned-cloudMulticloud

Edge automation

AT&T


AT&T:  Medium

Telemetry









4) Experimental:

Modeling Domain

Modeling Requirement

Modeling Requirement Description

Impacted

Projects

Use Case

Relevance

Modeling Spec

Commitment

Code

Commitment

Provider

Priority

 Owner

Resource

Container

Resource modeling changes in the IM, design time DM and runtime DMMulti-Cloud


Intel

Intel


Acceleration Management (BoF)

Discussing the requirement for acceleration management in ONAP, including research motivation,problem statement, as well as proposals. Welcome to join this thread.

( Acceleration Management (BoF) )






Lei Huang












20 Comments

  1. Hello, it is not clear to me what are detail requirements per each of the item in the "Modeling Requirement" column.

  2. HI

    Can you clarify: 

    Telemetry

    Events & VES

    Vnf Event Descriptor Model

     What is the ambition in terms of modeling?

    Add in the common model the VES event model as defined in R60 ? All domains? 



  3. Thank you for putting together this table. It is very helpful.

    I have three comments:

    1. The composite/atomic pattern was discussed and only agreed upon by the service IM team, but as you have shown it has implications on the resource model. I would like to request that before a "global" decision be made that affects multiple areas of the model, that this discussion be re-opened to the modeling team at large, and that a poll be taken before the pattern is officially adopted.
    2. Network service - this is related to the above comment in that a decision was made to make a NS a composite resource based on a service IM discussion to adopt the composite/atomic pattern with neither decision (i.e. make NS a composite resource, and adoption of composite/atomic pattern) discussed and agreed to by the resource IM team. The discussion needs to be re-opened to the modeling team at large. In the future, any decisions that affect multiple areas of the model should be reviewed and approved at the modeling subcommittee level before adoption.
    3. Hardware acceleration. As this table shows, it isn't even clear what this is, though I assume that it represents the requirements presented by China Mobile in Beijing? Could you please provide a clear definition of this work item and how it differs from our current support in the model for HPA.
    1. Hi Jessie

      FYI ... on your point #2, the TM Forum has made a similar decision, i.e., we use an object class know as Resource Function to cover atomic (VNF and similar) and composite (NS and similar) entities. This is in the SID Logical Resource model and also explained in TM Forum TR255 series. 

      Steve Fratini

      1. Steve-

            There are a number of TR255 documents. Could you tell me which one exactly? I couldn't find it in the SID either, but I have version 16.5. In which version does this appear?

        Thanks,

        Jessie

        1. Jessie

          See Section 2 of TR255 (main document). 

          Further detail about Resource Functions is in Section 2 of GB922 Logical and Compound Resource Computing and Software R17.5.1. 

          Steve

          1. Steve-

                Please provide the title of the "main" document, as 4 documents are in the TR255 zip file.

            Jessie

  4. I see VNF Instance as being part of the runtime model.

    I see PNF referenced as both design time model and runtime model.

    Why wouldn't we have a PNF instance for the runtime model?


  5. Our understanding was that "Acceleration Management" was not accepted as a use case, and that this requirement should thus be removed.

  6. Ext API is mentioned for service order but it's worth to be noted that Ext API also provided a modeling for service (service inventory assets retrieved from AAI) and serviceSpecification (that a serviceCatalog resource). These could be also reviewed by Modeling team.

  7. On Jessie's point "The composite/atomic pattern was discussed and only agreed upon by the service IM team...", I thought I would take another shot. Through a number of separate modeling activities it has become apparent that:

    • whilst the Composite pattern is applicable in some cases, applying the pattern too high in the inheritance hierarchy causes greater complexity of rules. 
      • as the Composite pattern says that an atomic thing cannot be decomposed into further like parts. Key classes in the network model such as Forwarding Domain, ForwardingConstruct must be composite BUT as they cannot be composed of each other they cannot be in the same Composite pattern. Hence it is best to repeat the pattern at the leaves where it applies rather than to impose it way up the hierarchy
    • as the pattern causes distinct classes for the atomic form and the composite form, the pattern should be applied with care.
      • If a thing is atomic because of policy, i.e. the user is not allowed to look at greater detail, the policy may change and then the class of the thing must change to allow it to be opened up. This will cause unnecessary disruption in the running solution as compared to a simple recursive model where there is a null reference to detail (and perhaps a property indicating why the reference is null)
    • the composite pattern is not sufficient alone to explain the actual assembly of the parts. When considering the assembly it is important to understand the way the things are arranged, which ports on which things are connected and which ports are exposed (for the next level of assembly)
      • It appear that considering a model that focuses on the assembly of the system of components is more important

    To be clear, I made these points (via several slides) in the service IM discussion, so I am only reiterating my ongoing concerns in this broader context.

    1. Nigel and all, 

      This is not to contradict the points from Nigel but rather to point out another facet of complexity. 

      We had some similar discussions in the TM Forum ZOOM work. The distinction between composite and aggregate is not always black and white. For example, in the design phase, a VNF is atomic from the perspective of the service provider who purchases the VNF and perhaps wants to compose with other VNFs to form a Network Service. However, from a real-time management perspective, the service provider does know about the VNFCs within the VNF and can, for example, scale the VNF to have more or less VNFCs. So, a VNF is not an atom during the working phase. Same point concerning the deployment phase where the VDUs (supporting a VNF) can be deployed in separate "locations." The point is that the pattern in question here depends on the given phase of the entity. 

      Steve

  8. I believe we have already spent enough time speaking of composite vs recursive model (at least from dec 2017). 

    1. I spent time providing arguments and examples that explained why I think the pattern is not appropriate for the Service model, especially not where and how it is proposed to be applied. At the time, I used some Resource examples. I am simply reemphasizing that the pattern, as proposed, is not helpful in the resource model. As Jessie pointed out, it was only with respect to Service that the decision was made.

      I do not recall anyone actually explaining what was wrong with my argument (or even analyzing my argument in detail). Either this means there was a blindingly obvious flaw, in which case it would be helpful if someone could point it out (as it is not obvious to me), or the arguments have not really been assessed. I am assuming the latter at this point and hence am re-raising the key points in this broader context.  

      Incidentally, I am not proposing a simple recursion in the general case, although I do think that a simple recursion is quite suitable in some degenerate cases, I am proposing that we develop a component - system model similar to the TOSCA "metamodel" and that we use properties to indicate the current point of opaqueness.

      But if you would all prefer that I simply wait until we get to the necessary level of sophistication of use case, I am OK with that.

      1. I agree with Michela.

        We discussed BOTH the Resource and Service models at length in December. We gave examples and there were no disagreements. In contrast, both Joel and I objected to examples made using the recursive pattern.

        Your position seems to be "we made a decision, and what if it is wrong". The essence of modeling is making decisions. If it is wrong, then we fix the model. Otherwise, like this discussion, we get nowhere.

        We made a decision. We have then redecided on the decision at least 5 times. It is tiresome.


        1. OK. I only came across a decision in a narrow context (of service modeling) and was led to believe by some comments in this thread that there was another opportunity to assess the decision in a broader context. If the decision has already been made by this broader group, I apologies for not realizing. As was the case with the Service model, and as I noted in my comment here, I am OK to live with the decision and use the model as is. I will wait till we get to the sophistication of use case that requires us to change. At that point I will make some proposals.

  9. Hi,

    To be clarified the following modeling requirement/modeling description

    VNFD & Alloted resourceONAP Resource Data Model for Design and Runtime

    What feature is intended to be added in the Resource Information model? 

    Why the description refers to the Data model ? 

  10. Can you enrich the modeling description in terms of what are the information model impacts ?

  11. 1.In the resource level, there is lack of VL resource, which is already used in the R2 usecases(vCPE or VoLTE) and needs to be enhanced in R3. suggest to add it.

    2. In the service level, there is service catalog. Should we add the resource catalog as an requirement?
        In my mind, at least network service, VNF, etc as resources need a catalog.

    Additions:
    Could the PNF and PNF instances be merged into one requirement? Similarly, VNF and VNF instances.