Overview

The network-element-name-generation (N-ENG) micro-service generates unique names for network elements, such as VNF, VM, VNFC etc., based on policies in the policy manager.

Names are generated based on policy names, which are collections of rules on how names are generated, by assembling various pieces of data. The policies can also have specifications to generate unique names based on sequences, timestamps or UUIDs. They also often contain rules on transforming data elements before assembly and/or after assembly, by operations such as:

  • converting data to uppercase or lowercase
  • taking a sub-string of certain length from a data element

This micro-service interprets such policy rules to generate names. The names generated by this micro-service are persisted in an internal database. The names are also validated for uniqueness against inventory systems (A&AI).

Architecture

The picture below shows a high level architecture of the N-ENG micro-service.


Interface Details

This interface has two different types of operations:

  • assign/generate request to generate names
  • unassign/delete/release request to release a name from the network

Assign/Generate Operation

This is an HTTP POST operation.

Here is a sample request:

{ 
  "elements": [
    {
      "external-key": "VRZQWUKKMAAZZ",
      "policy-instance-name": "JQIN1806SRIOV.Config_MS_1806SRIOV_VPE_AVPN_MoWJson.6.xml",
      "COMPLEX": "TRLAKDG",
      "NF-NAMING-CODE": "ESP",
      "CLOUD_REGION_ID": "A1235Z",
      "NF_CODE": "BMNO",
      "resource-name": "vnf-name",
      "naming-type": "VNF"
    } 
  ]
}

The request contains an array of 'elements', each item of which contains the data to generate a name,

Each item of the 'elements' array has these required fields:

  • external-key – This is the ID/key the caller/client uses to identify a name.
  • policy-instance-name – This is the name of the policy used for name generation.
  • resource-name – The name of the resource to be generated.
  • naming-type – The naming type as defined in the policy.

The request can also have any additional fields (as name-value pairs) that are needed for name generation, as defined by the policy. If the policy specifies that a field is needed, and if the client/caller doesn't pass such a field, the generation will fail. The fields in the sample above that have upper-case names are examples of such fields.

Here is a sample response:

{
  "elements": [
    {
      "resource-value": "trlakdg014esp",
      "resource-name": "vnf-name",
      "external-key": "VRZQWUKKMAAZZ"
    }
  ]
}


The response contains a similar array of 'elements', corresponding to the array in the request. Each array element will have the following fields:

  • external-key – This is the ID/key the caller/client uses to identify a name.
  • resource-name – The name of the type of the resource generated.
  • resource-value – The generated resource name value.

Unassign/Delete/Release Operation

This is an HTTP DELETE operation.

Here is a sample request:

{ 
  "elements": [
    {
      "external-key": "VRZQWUKKMAAZZ"
        } 
  ]
}

The request contains an array of 'elements', each item of which contains the external key that was used to generate the name.

Here is a sample response:

{
  "elements": [
    {
      "resource-value": "trlakdg014esp",
      "resource-name": "vnf-name",
      "external-key": "VRZQWUKKMAAZZ"
    }
  ]
}


The response contains a similar array of 'elements', corresponding to the array in the request. Each array element will have the following fields:

  • external-key – This is the ID/key the caller/client uses to identify a name.
  • resource-name – The name of the type of the resource deleted.
  • resource-value – The deleted resource name value.

Contacts

 Yuriy Malakov, Jiejenny Qin and Biju Thomas.



  • No labels