Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 7
Next »
Points to Highlight:
- Integration between the ONAP and TOSCA Specs models: based on the tosca.capabilities.network.Linkable and tosca.capabilities.network.Bindable capability types, and, perhaps, substitution of the tosca.nodes.Network nodes
- The connectivity is modeled on the "application" level only (VFC), not on the "infrastructure" level ("VDU"/Container)
- VFC --< ← CP → >-- VL --< ← CP → VFC ← CP →
- Same node type to model both internal and external CPs
- QoS modeled as TOSCA policies (targeting VLs)
- Address assignment as TOSCA policies (tergeting CPs)
- CP Address is an attribute, not a property
data_types:
onap.datatypes.AddressData:
# = tosca.datatypes.nfv.AddressData
capability_types:
tosca.capabilities.network.Linkable:
# a capability type from the TOSCA Specs
tosca.capabilities.network.Bindable:
# a capability type from the TOSCA Specs
##### ONAP derivations - to provide information required by the IM
onap.capabilities.Linkable:
derived_from: tosca.capabilities.network.Linkable
description: an ability of a network to have traffic through a CP
onap.capabilities.Bindable:
derived_from: tosca.capabilities.network.Bindable
description: an indication that the owner node can communicate through a CP
policy_types:
onap.policy.AddressAssignment:
description: governs address assignment to CPs
derived_from: tosca.policies.Root
properties:
automatic_assignment:
type: boolean
required: false
address_type:
type: string
required: false
constraints:
- valid_values: [IPv4, IPv6, Mac]
# create derived types to carry extra info, like is_floating_ip, pool size/id, etc.
onap.policies.QualityOfService:
description: specifies a bunch of QoS parameters
derived_from: tosca.policies.Root
properties:
max_latency:
latency_variation:
packet_loss_ratio:
node_types:
onap.nodes.CP:
derived_from: onap.nodes.Resource
description: a connection point
requirements:
- binding:
description: binding with a VFC
capability: onap.capabilities.Bindable
occurrences: [1, 1]
relationships: onap.relationships.BindsTo
- link:
description: link to a network
capability: onap.capabilities.Linkable
occurrences: [1, 1]
relationships: onap.relationships.LinksTo
attributes:
address:
type: onap.datatypes.AddressData
description: the address received after assignment
onap.nodes.VL:
derived_from: onap.nodes.Resource
description: a virtual link
capabilities:
link:
type: onap.capabilities.Linkable
occurrences: [0, UNBOUNDED]
# We need to be able to assign properties to requirements.
# The TOSCA way to do it - by the requirement+relationship combination.
relationship_types:
onap.relationships.LinksTo:
# very similar to the NFV VirtualLinksTo
description: an association between a CP and a VL
derived_from: tosca.relationships.DependsOn # to participate in lifecycles
interfaces:
Configure:
type: onap.interfaces.relationship.LinksTo.Configure
properties:
role:
description: the role of the port on the network (e.g., Root, Leaf, Peer)
type: string
protocol:
description: the protocol implemented by the port(e.g., Ethernet, TCP)
type: string
interfaces:
onap.interfaces.relationship.LinksTo.Configure:
# do we need an ONAP extension of the standard TOSCA tosca.interfaces.relationship.Configure??
derived_from: tosca.interfaces.relationship.Configure
onap.interfaces.relationship.BindsTo.Configure:
# do we need an ONAP extension of the standard TOSCA tosca.interfaces.relationship.Configure??
derived_from: tosca.interfaces.relationship.Configure
node_types:
onap.node.samples.SampleVFC1:
derived_from: onap.nodes.VFC:
requirements:
- host:
capabilities:
binding_1:
type: onap.capabilities.Bindable
occurrences: [1, 1]
binding_2:
type: onap.capabilities.Bindable
occurrences: [1, 1]
onap.node.samples.SampleVFC2:
derived_from: onap.nodes.VFC:
requirements:
- host:
capabilities:
binding_1:
type: onap.capabilities.Bindable
occurrences: [1, 1]
node_templates:
vfc_1:
type: onap.node.samples.SampleVFC1
requirements:
- host:
node: vdu_1
capability: host
capabilities:
binding_1:
binding_2:
vfc_2:
type: onap.node.samples.SampleVFC1
requirements:
- host:
node: vdu_2
capability: host
capabilities:
binding_1:
binding_2:
cp_1:
type: onap.nodes.CP
requirements:
- binding:
node: vfc_1
capability: binding_1
- link: # a requirement for an external VL => this is an external CP
node_filter:
cp_2:
type: onap.nodes.CP
requirements:
- binding:
node: vfc_1
capability: binding_2
- link: # linked to the internal VL => this is an internal CP
node: vl_1
capability: link
cp_3:
type: onap.nodes.CP
requirements:
- binding:
node: vfc_2
capability: binding_1
- link: # linked to the internal VL
node: vl_1
capability: link
vl_1:
type: onap.nodes.VL
capabilities:
- link:
# The capabilities of this VL are not exposed through
# the substitution mapping => this is an internal VL
vdu_1:
type: onap.node.VDU
capabilities:
host:
requirements:
- cpu:
- memory:
- storage:
- io:
- nic:
vdu_2:
type: onap.node.VDU
capabilities:
host:
requirements:
- cpu:
- memory:
- storage:
- io:
- nic:
policies:
cp_address_assignment_1:
type: onap.policies.AddressAssignment
properties:
automatic_assignment: true
address_type: IPv4
targets: cp2, cp3
qos_1:
type: onap.policies.QualityOfService
properties:
max_latency: 100 ms
latency_jitter: 10 ms
packet_loss_ratio: 0.01
targets: vl_1
subtitution_mapping:
type: #.... the node type of this VNF
requirements:
- ext_link_1:
mapping: [cp_1, link]
Open Issues:
- protocol, role, flow pattern
- HPA requirements of CP and VL: bitrate, other characteristics of NIC and IO