You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Description

In CCVPN use case, if a customer wants to set up a VPN from Beijing to London, we can use ONAP to stretch such a VPN service that is cross operator, cross domain and cross layer. Customer can also create a multi-site to multi-site service, as well as delete or add a site on the existing service according to their demands.
We abstract the VPN service topology into three kinds of nodes: Site, SOTN VPN Infra, SD-WAN VPN Infra. The composition of Sites and SOTN VPN Infras can comprise a SOTN VPN Service, the composition of Sites and SD-WAN Infras can comprise a SD-WAN VPN Service, while the combination of these three nodes can make up a SOTN+SD-WAN VPN Service.

All the sites and VPN Infras needs a set of inputs. In Casablanca release, SDC is not capable to support multiple sets of inputs in one service template so that we have to design the sites and VPN infra as a service and use 3 service templates to describe each kinds of node. The CCVPN service is created by mean of separate multiple Service Orders , with one service orderItem for each of the services that makes up the CCVPN connectivity Service.
Such solution, on the one hand, obviously, violates the idea of using one service template to create a CCVPN service. A CCVPN service consists of several site service and VPN service which in fact should be resource; On the other hand, Customers couldn't choose which site or VPN Infra to be included when instantiating a real service because all these resources are regarded as a service.

But if the service template could support multiple instances inputs, we can design all the Site, SOTN and SD-WAN as resources into one service, which would be more reasonable.  

Requirements

  1. Modeling team accepts multiple node template instances in service template (To support multiple sets of inputs in one service template)
    Note: TOSCA service templates specify a set of nodes that need to be created at service deployment time. Some service templates may include multiple nodes that perform the same role. For example, a template that models an SD-WAN service might contain multiple VPN Site nodes, one for each location that accesses the SD-WAN. Rather than having to create a separate service template for each possible number of VPN sites, it would be preferable to have a single service template that allows the number of VPN sites to be specified at deployment time.
      (Anatoly Katzman  Hui Deng  Andy Mayer shitao li
  2. SDC supports multiple node design in TOSCA service template (Ofir Sonsino )
  3. SO support List input interface(Seshu Kumar Mudiganti )

The ideal solution should be that a CCVPN service can be instantiated by using one service template and customers can decide the number of resources when creating a service.
TOSCA working group also pays attention to this problem and they came up with an improved service templates which can satisfy our needs:

Keyname

Required

Type

Constraints

Description

occurrences

no

range of integer

when not specified, defaults to [1,1]

The optional minimum and maximum number of instances that can be created from this node template. If not specified, only one single instance can be created.

instance_count

no

integer

when not specified, defaults to the lower bound of the range specified by the ‘occurrences’ keyname

The requested number of runtime instance of the node template.


Specifying Inputs

The service template in the previous section conveniently ignores the location property of the Site node. As shown earlier, the location property is expected to be provided as an input value. If Site node templates can be instantiated multiple times, then it follows that multiple input values are required to initialize the location property for each of the Site node instances. 

To allow specific input values to be matched with specific node template instances, a new reserved keyword is introduced:

Keyword

Valid Contexts

Description

INDEX

Node Template

A TOSCA orchestrator will interpret this keyword as the runtime index in the list of node instances created from a single Node Template.

 

The following service template shows how the INDEX keyword is used to retrieve specific values from a list of input values in a service template:

tosca_definitions_version: tosca_simple_yaml_1_2

 

description: Template for deploying SD-WAN with a variable number of sites.

 

topology_template:

  inputs:

    numberOfSites:

      type: integer

    locations:(VNF)

      type: list

      entry_schema: Location

  

  node_templates:

    sdwan:

      type: VPN

    site:

      type: VPNSite

      occurrences: [1, UNBOUNDED]

      instance_count: { get_input: numberOfSites }

      properties:

        location: { get_input: [ locations, INDEX ] }

      requirements:

-   vpn: sdwan

see Reference: 

1,   TOSCA Enhancements to Support Multiple Node Template Instances

2,  SOTN VPN Infra Service CSAR File in C release

  • No labels