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:
But all are welcome.
AAI | VFC | What is it | Belongs in | Action | |
service-instance-id | id | unique id of the instance | ServiceInstance | keep service-instance-id as the key to the AAI service instance and adapt id to populate it. | |
nspackageid | unique id of the package | PlatformServiceModel | Add providerDetails data type of which this would be a property, add a property of type providerDetails to PlatformServiceModel | ||
service-instance-name | name | name of the instance | ServiceInstance | keep in AAI service-instance | |
description | description of the instance | ServiceInstance | Free 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 model | PlatformServiceModel | keep 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 model | PlatformServiceModel | keep 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 steward | PlatformServiceModel, could be copied to ServiceInstance | Data Governed field which is used in filtering | ||
service-role | should be discussed, should just be denormalized filtering data that has a data steward | PlatformServiceModel, could be copied to ServiceInstance | Data Governed field which is used in filtering | ||
service-instance-location-id | retire | retire | Discuss merits of having a customer-premise "table" and establish relationship | ||
bandwidth-total | retire | retire | retire | ||
property-value | We think this is an error | retire | remove | ||
environment-context | extension, not required | ServiceInstance | ignore for now, may be renamed | defines 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 required | ServiceInstance | ignore for now, may be renamed | describes 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-at | createtime | refactor, just expose AAI data but as system set, read only | ServiceInstance | expose, needs to be read only | Check with AAI PTL on these fields |
updated-at | lastuptime | refactor, just expose AAI data but as system set, read only | ServiceInstance | expose, needs to be read only | Check 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-status | status | 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 | |
nsdId | Unique ID of the network service descriptor | PlatformServiceModel, could be copied to ServiceInstance | Add 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. | ||
nslevel | propose 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. | |
flavourid | where 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. | |
nsdmodel | JSON string | Do not add to AAI | LIN MENG will provide an example of an entire row of this table, with nsdmodel, scaleparameters, inputparameters populated. | ||
scaleparams | What 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 AAI | ServiceInstance | keep | ||
input-parameters | inputparameters | For 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-id | This 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. |
20 Comments
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?
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:
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.
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?
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
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
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.
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?
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.
LIN MENG
Hi Chesla, few questions and answers :
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.
LIN MENG
Hi Chesla,
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"
}
}
LIN MENG
example of scaleparameters
{
"scaleType": "SCALE_NS",
"scaleNsData": [{
"scaleNsByStepsData": [{
"aspectId": "TIC_EDGE_IMS",
"numberOfSteps": "1",
"scalingDirection": "0"
}]
}]
}
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.
Chesla Wechsler
This is good news.
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')
Keong Lim
Added item for discussion on 2018-11-15 AAI Developers Meeting
LIN MENG
Hi Chesla,
does there exist a schema for service component instance in A&AI?
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.
LIN MENG
That's exactly my confusion. Thank you, Chesla.