At the Montreal joint architecture/modeling meeting, there was discussion on network service vs. service.  Data was presented regarding the fields needed in the instance data model by AAI and VFC.  I attempted to capture an initial proposal for comment.

There are a number of items that I need more understanding about:

  • what are nsdmodel, scaleparameters, and inputparameters?
  • flavourid and nslevel seem like they should be relationship to other entities instead of "foreign keys", is that true?


In addition, we  need a discussion on some items:

  • AT&T has used a type/role/function classification function to provide a standard way to encode some data for filtering that is used in place of descriptions.  I'd like to propose that for consideration instead of a free form description field (or a field that takes different ungoverned values based on the flow being written).  Establishing data governance around these values can be instrumental for your operations teams and your automation.
  • It's like to propose a datatype for "ProviderDetails" which captures fields like the descriptorId, descriptorVersion, productName, packageId, etc.  A property of type ProviderDetails would be added to the internal design time model for Service and NetworkFunction.

Let's use three terms:

  • OnboardingServicePackage contains the OnboardingServiceDescriptor among other things
  • OnboardingServiceDescriptor (of which one format is the SOL 001 NSD - a point of contention here as to whether this is any different than creating an ONAP service in the designer)
  • PlatformServiceModel (which is what SDC produces as the service model that the components use)
  • ServiceInstance (the results of an instantiation from the PlatformServiceModel)

Chesla Wechsler to take action item to write up schemaless behavior need which would accommodate service-level properties which are not global (i.e., do not belong in the STANDARD COMMON definition of service-instance) but which still need to be stored on certain service-instance to which they apply.  Chesla will talk to AAI PTL about this, as this is a feature that would be needed on AAI.

Schemaless behavior (note, I haven't spoken to the AAI PTL yet):

The internal service model global type has properties and attributes which are common to all service-instances.  This is likely a very small set.  When a node type extends the service global type, it adds properties and attributes specific to that particular service model (like your portal url, slice characteristcs, etc.). 

Today, AAI expects the fields in its payloads to be defined by an OXM file, and the relationships between vertexed defined in an edge rules file.  It uses a "superset of all possibilities" approach which I think should evolve to an InternalXModel approach where the specific InternalModel, which has properties and attributes, defines the fields of the instance.  Alternatively, there would need to be instances modeled at the same time as the design time objects and mapping ensues.

AAI would need an interface that permits payloads that have the specific properties and not just the common/global ones in the base object.
AAI stores all the data in the payload and returns it when queried, which includes things like portal url, etc.
The common/global fields can be indexed.  Model specific ones would not have an index at first unless they is also an AAI feature to ask for an index on it or there is a way to specify it in the model.

People I'm expecting to participate in this conversation are as follows:

Fernando Oliveira

Yan Yang

LIN MENG

But all are welcome.


AAIVFCWhat is itBelongs inAction
service-instance-ididunique id of the instanceServiceInstancekeep service-instance-id as the key to the AAI service instance and adapt id to populate it.

nspackageidunique id of the packagePlatformServiceModelAdd providerDetails data type of which this would be a property, add a property of type providerDetails to PlatformServiceModel
service-instance-namenamename of the instanceServiceInstancekeep in AAI service-instance

descriptiondescription of the instanceServiceInstanceFree form human readable string which no software should interpret or do logic on.  Purely to display to a human.
model-invariant-id
invariant id across all versions of the same PlatformServiceModel modelPlatformServiceModelkeep in AAI service-instance API (I think it's really a relationship internally)
model-version-id
unique id of a version of a model in the PlatformServiceModel modelPlatformServiceModelkeep in AAI service-instance API (I think it's really a relationship internally)
service-type
should be  discussed, should just be denormalized filtering data that has a data stewardPlatformServiceModel, could be copied to ServiceInstanceData Governed field which is used in filtering
service-role
should be  discussed, should just be denormalized filtering data that has a data stewardPlatformServiceModel, could be copied to ServiceInstanceData Governed field which is used in filtering
service-instance-location-id
retireretireDiscuss merits of having a customer-premise "table" and establish relationship
bandwidth-total
retireretireretire
property-value
We think this is an errorretireremove
environment-context
extension, not requiredServiceInstanceignore for now, may be renameddefines the use and criticality of a virtual function which is used to ensure hypervisor separation (non-shared hosts) between vf functions of different use or criticality (e.g. Critical_Revenue-Bearing, Useful_Non-Revenue)
workload-context
extension, not requiredServiceInstanceignore for now, may be renameddescribes the purpose. VNF End-to-End testing for the Casablanca release would be VNF-E2E-Casablanca as an example
vnf-type
was this a typo on the slide?  This is not in AAI in ONAP.
I think this is a mistake
created-atcreatetimerefactor, just expose AAI data but as system set, read onlyServiceInstanceexpose, needs to be read onlyCheck with AAI PTL on these fields
updated-atlastuptimerefactor, just expose AAI data but as system set, read onlyServiceInstanceexpose, needs to be read onlyCheck with AAI PTL on these fields
persona-model-id
retire
remove
widget-model-id
retire
remove
widget-model-version
retire
remove
vhn-portal-url
This should not be on the global type but the derived type would have it and it could be stored as a schemaless field on the service-instance vertex
refactor
orchestration-statusstatus

SO has an enumeration of values.  VFC probably does too and odds are they aren't the same.   

VFC: empty, instantiating, terminating,active, failed, inactive, updating, scaling, healing

SO: Inventoried, Assigned, Active


Propose adding a vfc-status field to AAI to capture VFC's status, and revisit this as a community to see if there can be convergence on a state transition for services.  SO uses terminal states and VFC seems to use transitional and terminal states.

LIN MENG will get enumerated values from VFC PTL to see whether they can be mapped into the enumerated values used by SO so that there is one set of enumerated values.

Chesla Wechsler to propose to the architecture subcommittee that we need an orchestration "meeting of the minds" on state transitions, terminal states and transition states and what gets written to AAI.

Update: topic created


nsdIdUnique ID of the network service descriptorPlatformServiceModel, could be copied to ServiceInstanceAdd providerDetails data type of which this would be a property, add a property of type providerDetails to PlatformServiceModel model

sdncontrollerid
ServiceInstance

Do Not Add to AAI

LIN MENG will check what this is with the PTL.  


nslevelpropose calling it instantation-level (so much indirection in the ETSI NFV types….)ServiceInstance

Discuss whether this is a relationship to another entity.

Propose adding non-required instantiation-level field to AAI.  Need ONAP to work on the solution for service scaling.  What release should we propose service scaling be handled?

Need to discuss service level as a class and see how they fit into the overall ONAP architecture and possibly create a vertex type within AAI which would then have a relationship with the service-instance.  This would be an edge, not a field in service-instance.

LIN MENG - would you be willing to get the ETSI definition for the service level and flavor

Perhaps get the table definitions?  Really want ETSI definition too though.

Chesla Wechsler to send email to Alla G regarding whether there will be any use cases which will need to leverage service deployment flavors and instantiation level

At info model level, you can always add instantiation level and deployment flavor to the service instance as Future stereotype, and data modelers know that they don't need to be added.

Update:  Please see thread

No need to worry about flavour_id or nslevel in Dublin per Use Case committee. 


flavouridwhere is the data model definition of this?  Can a flavour be a  object with name/value pairs which is referred to by the service model and is common for all instances created from this service model?ServiceInstance

Discuss whether this is a relationship to another entity

If there is no support today or in Dublin for more than one flavor, propose deferring this to that time.

Regarding instantiation level and flavor in general (scaling), let's learn from the network function first and then see if it can apply to the service.


See above for use case email.

nsdmodelJSON string
Do not add to AAI

LIN MENG will provide an example of an entire row of this table, with nsdmodel, scaleparameters, inputparameters populated.


scaleparamsWhat is this?  Is this just an internal field of VF-C? I don't see it referenced in the etsi.nfv.nodes.NS
Do not add to AAI
resource-version
Used for concurrency enforcement with clients of AAIServiceInstancekeep
input-parametersinputparametersFor SO to pass parameters for closed loop, does this have ONAP wide applicability for closed loop functions?
Do not add to AAI
selflink
The purpose of this field is to give a URL to the source of truth of the service-instance.

Chesla Wechsler to find out if this is used in the service-instance.

Answer: yes

It can be used to contain the URL to the service topology in SDN-C, for example.



global-customer-idThis is VF-C's denormalization of customer data into the service instance.  AAI captures this in the customer vertex type. The customer has a relationship to a service subscription which has a relationship to the service-instance and therefore this data is avaialble but needs to be derived.
Use the customer.global-customer-id field.  Do not put into service-instance. 
  • No labels

20 Comments

  1. LIN MENG

    Hi Chesla,

    Thanks a lot for drafting this.

    I suggest we discuss this topic in this week's service IM call.

    How do you think?

    1. Chesla Wechsler

      Yes, and what would be superior is getting early answers to these questions before the call:

      There are a number of items that I need more understanding about:

      • what are nsdmodel, scaleparameters, and inputparameters?
      • flavourid and nslevel seem like they should be relationship to other entities instead of "foreign keys", is that true?

      1. Chuyi Guo

        Hello, Chesla,

             Nsdmodel is the JSON string after parsing,  scaleparameters and inputparameters are user input parameters. Flavourid and nslevel are more like foreign keys which related to one of the multiple deployment flavors and instantiation levels listed in NSD, respectively.

        1. Chesla Wechsler

          Thank you.  Would you have any examples of what an nsdmodel JSON string looks like?  I'm still not clear on what is meant by "JSON string after parsing".  Also, are scaleparameters and inputparameters also a "blob" or formatted JSON string that the consumer and producer know how to parse?

      2. Keong Lim

        Hi Chesla Wechsler,


        FYI the "input-parameters" field of "service-instance" in AAI was added for the CCVPN usecase: see also item AAI-1353-2 on AAI-CCVPN Schema Proposal for Casablanca Release

        It was previously called "customer-requests" field and there is an example of data in the comments on that page.


        Keong


  2. LIN MENG

    What's more, do you mean that we set a datatype for the internal model to represent all the attributes related to provider's information, like descriptorId, descriptorVersion, productName? 

    I think it is a good way to manage such data.

     Could you provide us a more detailed description or example of this datatype? like the semantic and syntactic constraints

    1. Chesla Wechsler

      We should first discuss whether the OnboardingServiceDescriptor data is metadata on the InternalServiceDescriptor or whether it becomes properties.  At the TOSCA orchestration level, I do not believe an orchestrator is supposed to look at metadata for any decision making.  It's truly just "data about the data". 

      If the id of the InternalServiceDescriptor is associated with every ServiceInstance, and the InternalServiceDescriptor has metadata (or properties) that identify the OnboardingServiceDescriptor, it is always possible to join the data together.  So, for example, if you need to find ServiceInstances which were created based on your OnboardingServiceDescriptor, you'd first search the InternalServiceDescriptors to find those which are related to your OnboardingServiceDescriptor, then find all the ServiceInstances created from your matching InternalServiceDescriptor(s).  It might be more efficient to denormalize your data at that point and put the OnboardingServiceDescriptor's descriptor id in the ServiceInstance but that's a design decision.

  3. LIN MENG

    Hi Chesla, I also have few questions to consult you:

    1. What do you mean by saying instance and internal model? What is the difference between instance and internal model in A&AI?

    2. why nspackageid belongs to internal model?

    3. How do you define the boundaries of attributes that can describe in an A&AI service instance but belongs to internal model,eg: model-invariant-id?


    1. Chesla Wechsler

      I tried to clarify this by adding a terminology section and then using those terms throughout, replacing the original instance and internal model. 

      SDC produces what I had been calling internal model (too vague, I agree) but am now calling the InternalServiceDescriptor.  The AAI schema object called service-instance is what I had been calling the instance and am now calling ServiceInstance.

      I assume the nspackageid is the ID of the NetworkService package (which I'm also assuming is NOT the OnboardingServiceDescriptor's id).  I thought you had a requirement to be able to query by the package id.  If that's not the case, then it's not needed on the InternalServiceDescriptor.

      I would like to see a mechanism whereby the InternalServiceDescriptor could be supplemented with the attributes one expects to find on the ServiceInstance.  That would help to correlate instances to their models. 

      I think my revision of terminology may have answered your question 3 at this point as well.  Let me know.

      Note, the model-invariant-id is the current name for the InternalServiceDescriptor's "unchanging across versions of the same model" id.  The model-version-id is the current name for the InternalServiceDescriptor's unique "specific to one version" id.  You can envision them as "join" keys between the instances and the models.  I believe they are passed as service-instance fields to AAI in API calls.  It's possible that, in AAI's private data model, they are really captured as relationships to other vertices within the inventory graph.


  4. LIN MENG

    Hi Chesla, few questions and answers :

    1. I see that you want to use service-type and service-role to replace description. I agree that we need to clarify merits of service-type and service-role. But I also think that we should keep 'description', as it provides a general description of this service using sentences which is much more easier for people better understanding of this service.
    2. what do you mean by establishing a customer premise table?  Are you going to use it to include all the attributes related to customers, eg SLA, bandwidth, reliability, QoS?  I do think that we need to expand service instance model to include such attributes to support all end-to-end service such as CCVPN  and 5G use cases.
    3. Is descriptorVesion and modelVersion the same thing in your opinion? Do you think model-invariant-id and model-version-id should also be modeled in 'ProviderDetails' datatype?
    4. nsdmodel, scaleparameters, inputparameters are all formated jason string. Nsdmodel is a string that includes all attributes name of NSD. Scaleparameters is used to store parameters related to scale aspect and scale level. Inputparameters, I think it can correspond to the current inputparameters in service instance.
    5. I agree that we can use instantiation level to represent NSlevel, they are the same thing in my opinion. flavorID represents nsdfid which identified the deployment flavor within an NSD. flavorid (nsdfid) is a foreign key of NSD table, while nslevel (nsLevelId) is a foreign key of NsDf table.


    1. Chesla Wechsler

      Thanks, Lin Meng:

      1) We can keep description as long as it's defined to be a human readable string for display purposes only and no logic should be built around it.

      2) The current customer+service-subscription structure should be deprecated and pushed to business support systems.  The comment I had about a customer premise table had to do with that one location field which didn't really belong in the service instance.  It could be cared for either by establishing a customer premise table (or vertex type) and having a relationship from the service instance to it, or pushing that to the BSS as well

      3) The descriptorVersion is the onboarding descriptor's version.  The model version is the internal/platform SDC representation's version.  They are two different things.    The provider details is meant to capture the onboarding provider detail, and not the internal/platform info.

      4) Thanks for your examples of these.  Am I interpreting other comments to mean that nsdmodel, scaleparameters, and inputparamers should be kept internally to VFC and not propagated into AAI? (hoping the answer is yes )

      5) If flavorid is foreigh key of the NSD table and nslevelid is the foreignkey of the NSDF table, we need to discuss AAI as a graph DB, the use of these foreign keys, etc.

  5. LIN MENG

    Hi Chesla,

    1. sdncontrollerId  is used for calling controllers by the orchestrator. It is a legacy attribute, which is not in real use now.

    2. example of nsdmodel:
      {

          "vnffgs": [],

          "inputs": {},

          "pnfs": [{

             "pnf_id": "du",

             "networks": [],

             "description": "",

             "properties": {

                 "descriptor_id": "pnf_test_01",

                 "descriptor_invariant_id": "1111",

                 "provider": "ZTE",

                 "version": "1.0",

                 "function_description": "RAN DU Function",

                 "name": "ZTE RAN DU"

             }

          }],

          "description": "RAN Network Service",

          "graph": {

             "du": [],

             "vl_ext_net": ["cu"],

             "cu": [],

             "vl_flat_net": ["cu"]

          },

          "basepath": "/tmp/tmpAgBuW2",

          "vnfs": [{

             "networks": [{

                 "key_name": "ran_ext_net",

                 "vl_id": "vl_ext_net"

             }, {

                 "key_name": "ran_flat_net",

                 "vl_id": "vl_flat_net"

             }],

             "dependencies": [{

                 "key_name": "ran_ext_net",

                 "vl_id": "vl_ext_net"

             }, {

                 "key_name": "ran_flat_net",

                 "vl_id": "vl_flat_net"

             }],

             "vnf_id": "cu",

             "description": "",

             "properties": {

                 "descriptor_id": "zte_ran_cu_0001",

                 "flavour_description": "default",

                 "software_version": "1.0.1",

                 "flavour_id": "1",

                 "descriptor_version": "1.0",

                 "provider": "ZTE",

                 "id": "zte_ran_cu_0001",

                 "vnfm_info": ["gvnfmdriver"],

                 "product_name": "ran"

             }

          }],

          "ns_exposed": {

             "external_cps": [],

             "forward_cps": []

          },

          "fps": [],

          "vls": [{

             "vl_id": "vl_ext_net",

             "description": "",

             "properties": {

                 "connectivity_type": {

                    "layer_protocol": "ipv4"

                 },

                 "vl_profile": {

                    "cidr": "10.0.0.0/24",

                    "max_bit_rate_requirements": {

                        "root": 10000000,

                        "leaf": 10000000

                    },

                    "networkName": "ran_ext_net",

                    "min_bit_rate_requirements": {

                        "root": 10000000,

                        "leaf": 10000000

                    },

                    "dhcpEnabled": false

                 },

                 "version": "1.0.1"

             }

          }, {

             "vl_id": "vl_flat_net",

             "description": "",

              "properties": {

                 "connectivity_type": {

                    "layer_protocol": "ipv4"

                 },

                 "vl_profile": {

                    "cidr": "10.1.0.0/24",

                    "max_bit_rate_requirements": {

                        "root": 10000000,

                        "leaf": 10000000

                    },

                    "networkName": "ran_flat_net",

                    "min_bit_rate_requirements": {

                        "root": 10000000,

                        "leaf": 10000000

                    },

                    "dhcpEnabled": false

                 },

                 "version": "1.0.1"

             }

          }],

          "ns": {

             "type": "onap.ran.ns",

             "requirements": {},

             "properties": {

                 "descriptor_id": "test_01",

                 "designer": "ZTE",

                 "invariant_id": "1zx2323523xc",

                 "name": "ZTE RAN",

                 "verison": "1.0",

                 "version": "1.0.1"

             },

             "capabilities": {},

             "metadata": {

                 "nsd_designer": "ZTE",

                 "nsd_name": "RAN-NS",

                 "nsd_release_date_time": "2018-11-05 12:00:00",

                 "nsd_invariant_id": "1zx2323523xc",

                 "nsd_file_structure_version": "1.0"

             }

          },

          "nested_ns": [],

          "metadata": {

             "nsd_designer": "ZTE",

             "nsd_name": "RAN-NS",

             "nsd_release_date_time": "2018-11-05 12:00:00",

             "nsd_invariant_id": "1zx2323523xc",

             "nsd_file_structure_version": "1.0"

          }

      }

  6. LIN MENG

     example of scaleparameters

    {

        "scaleType": "SCALE_NS",

        "scaleNsData": [{

           "scaleNsByStepsData": [{

               "aspectId": "TIC_EDGE_IMS",

               "numberOfSteps": "1",

               "scalingDirection": "0"

            }]

        }]

    }

  7. LIN MENG

    Didn't get the example inputparameters.

    But according to the conversation with VFV PTL, all these three attributes are used for coding after parsing. So as what you've suggested before, it's better to just keep it in VFC.


    1. Chesla Wechsler

      This is good news.

  8. LIN MENG

    example of Status:

    NS_INST_STATUS = enum(EMPTY='empty', INSTANTIATING='instantiating', TERMINATING='terminating',

                          ACTIVE='active', FAILED='failed', INACTIVE='inactive', UPDATING='updating', SCALING='scaling',

                          HEALING='healing')

  9. Keong Lim

    Added item for discussion on 2018-11-15 AAI Developers Meeting

  10. LIN MENG

    Hi Chesla, 

    does there exist a schema for service component instance in A&AI?

    1. Chesla Wechsler

      There doesn't exist any vertex type for service component instance in AAI.  If I recall, that was an info modeling abstraction at one point but I had thought it was removed as unneeded (per Andy Mayer and Gil Bullard).  If you are trying to figure out how to show that one service instance is composed of other service instances, it's captured just like that, i.e., a relationship between service instances.

      1. LIN MENG

        That's exactly my confusion. Thank you, Chesla.