Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel
borderColorblue
borderStylesolid
titleONAP Normative Types
Code Block
titleData Types
linenumberstrue
collapsetrue
data_types:
  onap.datatypes.AddressData:
    # = tosca.datatypes.nfv.AddressData

Code Block
titleCapability Types
linenumberstrue
collapsetrue
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

Code Block
titlePolicy Types
linenumberstrue
collapsetrue
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:

Code Block
titleNode Types
linenumberstrue
collapsetrue
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] # exactly one occurrence
        relationships: onap.relationships.BindsTo
    - link:
        description: link to a network
        capability: onap.capabilities.LinkableLinkable
        occurrences: [1, 1] 
			# Exactly one occurrence; 
			# either spend it with an internal VL (and this is how this CP becomes internal) 
			# or leave it unsatisfied (and thus make the CP external)
        occurrences: [1, 1]
        relationships: onap.relationships.LinksTorelationships: onap.relationships.LinksTo
			# without a relationship, a TOSCA requirement cannot have properties :( 
  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] 
			# can interconnect an unlimited occurrences: [0, UNBOUNDED]number of CPs

Code Block
titleRelationship Types
linenumberstrue
collapsetrue
# 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


Code Block
titleInterface Types
linenumberstrue
collapsetrue
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
      




...

Panel
borderColorgreen
borderStylesolid
titleSample VNF
Code Block
title"Local" Node Types
linenumberstrue
collapsetrue
node_types:    
  onap.node.samples.SampleVFC1:
    derived_from: onap.nodes.VFC:
    requirements:
      - host:
    capabilities:
	    # For every port attached, define a separate binding capability under its own name
		# -do host:not use the mechanism of capabilities:occurrences
      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]
 
Code Block
titleExample VNF Topology
linenumberstrue
collapsetrue
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]
        

...

  • protocol, role, flow pattern
  • HPA requirements of how do CP and VL express their requirements for infrastructure-level resources: bitrate, other characteristics of perhaps NIC and IO (not sure iwe can use the HPA capability types here, this would be an abuse..)