AWS TNB concepts

This topic describes essential concepts to help you start using AWS TNB.

Lifecycle of a network function

AWS TNB helps you throughout the lifecycle of your network functions. The network function lifecycle includes the following stages and activities:

Planning

1. Plan your network by identifying the network functions to deploy.

2. Put the network function software images in a container image repository.

3. Create the CSAR packages to deploy or upgrade.

4. Use AWS TNB to upload the CSAR package that defines your network function (for example, CU AMF, and UPF), and integrate with a continuous integration and continuous delivery (CI/CD) pipeline that can help you create new versions of your CSAR package as new network function software images, or customer scripts, are available.

Configuration

1. Identify the information required for the deployment, such as compute type, network function version, IP information, and names of resources.

2. Use the information to create your network service descriptor (NSD).

3. Ingest NSDs that define your network functions and the resources required for the network function to instantiate.

Instantiation

1. Create the infrastructure required by the network functions.

2. Instantiate (or provision) the network function as defined in its NSD and start carrying traffic.

3. Validate the assets.

Production

During the lifecycle of the network function, you'll complete production operations, such as:

• Update the network function configuration, for example, update a value in the deployed network function.

• Replace or decommission the network function.

Use standardized interfaces

AWS TNB integrates with European Telecommunications Standards Institute (ETSI) compliant service orchestrators allowing you to simplify the deployment of your network services. Service orchestrators can use AWS TNB SDKs, the CLI, or the APIs to initiate operations, such as instantiating or upgrading an network function to a new version.

AWS TNB supports the following specifications.

Specification	Release	Description
ETSI SOL001	v3.6.1	Defines standards for allowing TOSCA-based network function descriptors.
ETSI SOL002	v3.6.1	Defines models around network function management.
ETSI SOL003	v3.6.1	Defines standards for network function lifecycle management.
ETSI SOL004	v3.6.1	Defines CSAR standards for network function packages.
ETSI SOL005	v3.6.1	Defines standards for network service package and network service lifecycle management.
ETSI SOL007	v3.5.1	Defines standards for allowing TOSCA-based network service descriptors.

Network function packages for AWS TNB

With AWS TNB, you can store network function packages that comply with ETSI SOL001/SOL004 into a functions catalog. Then, you can upload Cloud Service Archive (CSAR) packages that contain artifacts describing your network function.

• Network function descriptor – Defines metadata for package onboarding and network function management

• Software Images – References network function Container Images. Amazon Elastic Container Registry (Amazon ECR) can act as your network function images repository.

• Additional Files – Use to manage the network function; for example, scripts and Helm charts.

The CSAR is a package defined by the OASIS TOSCA standard and includes a network/service descriptor that complies with the OASIS TOSCA YAML specification. For information about the required YAML specification, see TOSCA reference for AWS TNB.

The following is an example network function descriptor.

tosca_definitions_version: tnb_simple_yaml_1_0

topology_template:

  node_templates:

    SampleNF:
      type: tosca.nodes.AWS.VNF
      properties:
        descriptor_id: "SampleNF-descriptor-id"
        descriptor_version: "2.0.0"
        descriptor_name: "NF 1.0.0"
        provider: "SampleNF"
      requirements:
        helm: HelmChart

    HelmChart:
      type: tosca.nodes.AWS.Artifacts.Helm
      properties:
        implementation: "./SampleNF"

Network function service descriptors for AWS TNB

AWS TNB stores network service descriptors (NSDs) about the network functions that you want to deploy and how you want to deploy them into the catalog. You can upload your YAML NSD file, as described by ETSI SOL007 to include the:

• NF that you want to deploy

• Networking instructions

• Compute instructions

• Lifecycle hooks (custom scripts)

AWS TNB supports ETSI standards for the modeling of resources, such as network, service, and function, in the TOSCA language. AWS TNB makes it more efficient for you to use AWS services by modeling them in a way that your ETSI-compliant service orchestrator can understand.

The following is a snippet of an NSD showing how to model AWS services. The network function will be deployed on an Amazon EKS cluster with Kubernetes version 1.27. The subnets for the applications are Subnet01 and Subnet02. You can then define the NodeGroups for your applications with an Amazon Machine Image (AMI), instance type, and autoscaling configuration.

tosca_definitions_version: tnb_simple_yaml_1_0

SampleNFEKS:
  type: tosca.nodes.AWS.Compute.EKS
  properties:
    version: "1.27"
    access: "ALL"
    cluster_role: "arn:aws:iam::${AWS::TNB::AccountId}:role/SampleClusterRole"
  capabilities:
    multus:
      properties:
        enabled: true
  requirements:
    subnets:
      - Subnet01
      - Subnet02

SampleNFEKSNode01:
  type: tosca.nodes.AWS.Compute.EKSManagedNode
  properties:
    node_role: "arn:aws:iam::${AWS::TNB::AccountId}:role/SampleNodeRole"
  capabilities:
    compute:
      properties:
        ami_type: "AL2_x86_64"
        instance_types:
          - "t3.xlarge"
        key_pair: "SampleKeyPair"
    scaling:
      properties:
        desired_size: 3
        min_size: 2
        max_size: 6
  requirements:
    cluster: SampleNFEKS
    subnets:
      - Subnet01
    network_interfaces:
      - ENI01
      - ENI02

Management and operations for AWS TNB

With AWS TNB, you can manage your network using standardized management operations in accordance with ETSI SOL003 and SOL005. You can use the AWS TNB APIs to perform lifecycle operations such as:

• Instantiating your network functions.

• Terminating your network functions.

• Updating your network functions to override Helm deployments.

• Managing versions of your network functions packages.

• Managing versions of your NSDs.

• Retrieving information about your deployed network functions.

Network service descriptors for AWS TNB

A network service descriptor (NSD) is a .yaml file in a network package that uses the TOSCA standard to describe the network functions that you want to deploy, and the AWS infrastructure that you want to deploy the network functions on. To define your NSD and configure your underlying resources and network lifecycle operations, you must understand the NSD TOSCA Schema supported by AWS TNB.

Your NSD file is divided into the following parts:

1. TOSCA definition version – This is the first line of your NSD YAML file and contains the version information, shown in the following example.

   tosca_definitions_version: tnb_simple_yaml_1_0

2. VNFD – The NSD contains the definition of the network function on which to perform lifecycle operations. Each network function must be identified by the following values:

   • A unique ID for descriptor_id. The ID must match the ID in the network function CSAR package.

   • A unique name for namespace. The name must be associated with a unique ID to more easily reference throughout your NSD YAML file, shown in the following example.

   vnfds:
     - descriptor_id: "61465757-cb8f-44d8-92c2-b69ca0de025b"
       namespace: "amf"

3. Topology template – Defines the resources to be deployed, the network function deployment, and any customized scripts, such as lifecycle hooks. This is shown in the following example.

   topology_template:
   
     node_templates:
   
       SampleNS:
         type: tosca.nodes.AWS.NS
         properties:
           descriptor_id: "<Sample Identifier>"
           descriptor_version: "<Sample nversion>"
           descriptor_name: "<Sample name>"

4. Additional nodes – Each modeled resource has sections for properties and requirements. The properties describe optional or mandatory attributes for a resource, such as the version. The requirements describe dependencies that must be provided as arguments. For example, to create an Amazon EKS Node Group Resource, it must be created within an Amazon EKS Cluster. This is shown in the following example.

   SampleEKSNode:
     type: tosca.nodes.AWS.Compute.EKSManagedNode
     properties:
       node_role: "arn:aws:iam::${AWS::TNB::AccountId}:role/SampleRole"
     capabilities:
       compute:
         properties:
           ami_type: "AL2_x86_64"
           instance_types:
             - "t3.xlarge"
           key_pair: "SampleKeyPair"
       scaling:
         properties:
           desired_size: 1
           min_size: 1
           max_size: 1
     requirements:
       cluster: SampleEKS
       subnets:
         - SampleSubnet
       network_interfaces:
         - SampleENI01
         - SampleENI02