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 (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





ONAP Normative Types
Data Types 
data_types:
  onap.datatypes.AddressData:
    # = tosca.datatypes.nfv.AddressData
Capability Types 
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 
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 
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.Linkable
        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)
        relationships: 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 number of CPs
Relationship Types 
# 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
Interface Types 
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






Sample VNF
"Local" Node Types 
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 not use the mechanism of 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]
Example VNF Topology 
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
          
  container_1:
    type: onap.node.Container
    capabilities:
      host:
    requirements:
      - cpu:
      - memory:
      - storage:
      - io:
      - nic:
      
  container_2:
    type: onap.node.Container
    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
  • how do CP and VL express their requirements for infrastructure-level resources: bitrate, perhaps NIC and IO (not sure iwe can use the HPA capability types here, this would be an abuse..)



  • No labels

1 Comment

  1. maopeng zhang

    Hi Anatoly

         About QOS policy, could you give more explains about how to use it and what's the flow?  Thanks.