AWS TNB concepts
This topic describes essential concepts to help you start using AWS TNB.
Contents
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
-
-
Plan your network by identifying the network functions to deploy.
-
Put the network function software images in a container image repository.
-
Create the CSAR packages to deploy or upgrade.
-
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
-
-
Identify the information required for the deployment, such as compute type, network function version, IP information, and names of resources.
-
Use the information to create your network service descriptor (NSD).
-
Ingest NSDs that define your network functions and the resources required for the network function to instantiate.
-
- Instantiation
-
-
Create the infrastructure required by the network functions.
-
Instantiate (or provision) the network function as defined in its NSD and start carrying traffic.
-
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.
-
Update the network instance with a new network package and parameter values. For example, update the Amazon EKS
version
parameter in the network package.
-
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 |
Defines standards for allowing TOSCA-based network function descriptors. |
|
ETSI SOL002 |
Defines models around network function management. |
|
ETSI SOL003 |
Defines standards for network function lifecycle management. |
|
ETSI SOL004 |
Defines CSAR standards for network function packages. |
|
ETSI SOL005 |
Defines standards for network service package and network service lifecycle management. |
|
ETSI SOL007 |
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 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 (vnfd.yaml
),
as described by ETSI SOL007 to include the following information:
-
Network function 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.
-
Updating an instantiated or updated network instance with a new network package and parameter values.
-
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:
-
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
-
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"
-
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>"
-
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