CP & VL

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..)