Service Provider Next Generation Networks and Data Center consideration

SC4T plays a central role as an internal enabler to
overcome challenges such as breaking with outdated organizational
structures, the lack of collaboration in the telecommunications
industry or the “war of talents” against large industry players.
Through innovation, agility and new working concepts, SC4T enables the organization to attract talent and thus become both flexible and resistant to competitors.

The implementation of such a new work concept means internally to give employees freedom for self-development, for example through high performance teams, and externally for a better customer focus. The applied methodology of SC4T has already been successfully implemented in many companies within the framework of projects. In this way, an organization can transform itself from within and meet the requirements of a continuously changing economic environment.
The network infrastructure forms the core asset of every carrier. New technologies and changing market requirements open up new ways to provide the best possible coverage, capacity and quality at the lowest possible cost. SC4T is able to describe ways to achieve efficient, convergent & QoS-based expansion of mobile and fixed network infrastructures.
The range of available access technologies is becoming steadily wider. New technologies enable more capacity and coverage at lower cost. 5G and fiber optic networks set the standard and must be introduced.

The Network

New demand on Digital Transformation requires the construction of area-wide fibre infrastructures and 5G networks. The associated infrastructure expansion is not economically viable for a single carrier and is also ecologically questionable, which is why more and more partnerships, network sharing and heterogeneous networks will emerge in the future.

SC4T is able to explain technologies for access networks, efficient and demand-oriented planning, different possibilities of infrastructure sharing and the advancing disaggregation.

The network infrastructure forms the core asset of every carrier. New technologies and changing market requirements open up new ways to provide the best possible coverage, capacity and quality at the lowest possible cost.

SC4T is able to describe ways to achieve efficient, convergent & QoS-based expansion of mobile and fixed network infrastructures. The possibilities range from new technologies for access networks such as satellites or campus networks, integrated and demand-oriented planning approaches, through the disaggregation of hardware and software in access to the diverse possibilities of cooperation and sharing of infrastructures.

Use multiple physical fixed and mobile access technologies to provide seamless access for all customers!

The range of available access technologies is becoming steadily wider. New technologies enable more capacity and coverage at lower cost. 5G and fiber optic networks set the standard and must be introduced. Complementary technologies can be used to extend the range, e.g. heterogeneous networks or satellites, and to enable private solutions, e.g. 5G campus networks.

“Access Disaggregation, the separation of hardware and software in the access network, enables more flexible and vendor-independent design of the network”

Migrate from integrated vendor specific black boxes with proprietary interfaces to standard white boxes with open interfaces and separation of data and control plane. Disaggregation allows operators to mix and match equipment to enable faster time-to-market and flexible customized networks.

Disaggregation is applicable in the mobile radio network (ORAN) but also in the fixed network (SEBA [SDN-enabled Broadband access]). Access 4.0 provides a concrete example of Fixed Access Disaggregation and works with vEPC for 5G Next Generation networks.

SC4T developed the Best Practice for Telco Operator to address several Migration Projects from Network Access (vRAN or O-RAN) to Edge, MEC, Central and Core Networks with vEPC structure using more than 10000 network devices, two or three Telco Hybrid Cloud in several Data Centers, over 5000 cabinets, Cyber Security structure and over 2500 physical Servers, running VMware and OpenStack with over 50000 Virtual Machine Applications using Kubernets, Docker, and several Vendors like Cisco, Ericsson, Altiostar, Mavenir.

The Services for Telcos

– Supporting Design, Development, Configure, Testing and implementation of OTN Optical Transport Network with WDM/DWDM designing architecture for IP Converged Packet and optical transportation,

– Supporting Design, Development, Configure, Testing and implementation of IP Core, vEPC Architecture,

– Supporting Design, Development, Configure, Testing and implementation of Metro / Regional IP EDGE, RDG, CDN, TIR,

– Supporting Design, Development, Configure, Testing and implementation of Enhanced WIFI,

– Supporting Design, Development, Configure, Testing and implementation of vRAN and O-RAN Radio Access Network ,

– Supporting Design, Development, Configure, Testing and implementation of IP network automation solutions on Cisco NSO platform,

– SC4T Best Practice includes Designing Project and Validation Documents, drawn up according to an omnibus-comprehensive Blueprint:

– Network, Security, Data Center & Routing Audit,

– Telcos IP Core network assessment,

– Migration plan to Telco Cloud on different data centers including VxLAN Multi Hybrid Cloud,

– DETAILED DESIGN REPORT: Segment Routing, EVPN, Traffic Engineering, etc.

– Functionality (QoS, BGPFlowSpec, TWAMP, Telemetry),

– Network and / or control elements (collection network, PCE controller, etc.),

– Automation of procedures and security configuration supplied with the IPSecurity Service Chain solution for the protection of 4G and 5G radio backhauling,

– Design and implementation of Cisco NSO Network Orchestrator services with configuration template,

– Development of automation use cases on the components of the Cisco NSO platform through the Devops development model: iterations and analysis of requirements, development, testing, preparation of packages ready for deployment on operating platforms. Developments include xml templates and YANG templates and Python or Java code for managing the use of templates,

– Segment Routing on IP Core network for migration to TelcCloud with 5G vEPC services,

– Traffic Engineering on IP Core network,

– Integration and validation of vCDN overlay services,

– Support for Virtualization of Route Reflector functions on NFVi platform,

– Support for the definition and implementation of a new interconnection architecture with national peers,

– Support for the design of the MEC 5G structure,

– Support for the design of the Remote Radio Unit structure.

– Support for the design of the disaggregated MultiBase Band unit structure for Radio Open Radio Access Network and vRAN with Cisco, Mavenir and Altiostar,

– Architectural support of connectivity towards control elements (eg Route Reflector) of the POPs of the IP backbone,

– Support for the introduction and evolution of Nexus ACI Data Centers in Telco Clouds for migration to the Next Generation network and integration with VMWARE NSX,

– Support for the redesign of Segment Routing architectures on the Metro / Regional Network,

– Support for the design of TE Segment Routing architectures on Cisco ASR9K and NCS560 / ASR907XR Metro / Regional Network,

– Support for the design of the EVPN Anycast GW Cisco ASR9K and NCS560 / ASR907 XR architectures,

– Support for the validation of QoS architectures,

– Support for the design of PTP / syncE architectures,

– Support for the design and planning of Segment Routing architectures on IP Edge network,

– Support for the design and planning of virtualized Security architectures in Service Chain from O-RAN to IP Core 5G,

– Support for the design and design of access networks and vCPE definition of the Enterprise customers of Telcos, Virtualization of Services and design of configurations for virtualized services in vCPE,

– Support in the definition of Configuration Best Practices and Design Collaboration / Consultation / Review for the platform devices (ASR9k, ASR1k, ISG, WLC, FW, UCS) and the WiFi and wired networks of Telco customers. Definition of integrated platforms for the transport of customers’ wireless networks in the IP Core Telco network,

After having built the Openstack infrastructure on our MacBookPro it’s time now to operate it and illustrate how to define networks, subnets, images and instances. As you might remember we have a the following setup :

Our goal is to create and launch an instance on this infrastructure: this VM will be connected to a VXLAN network with a specific IP address space but will be reachable through an IP address published on the External network. The VM will be able to access the Internet through a virtual router defined in the Openstack infrastructure. In order to properly setup the target environment we will need to define some components as network administrator while some others need to be defined at the user level (the user that will own the VM and run application on it). So let’s define 2 shell scripts to ease switching from the admin to the user role :
stack@ctl:~$ cat admin-openrc
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin export OS_USERNAME=admin
export OS_PASSWORD=stack$
export OS_AUTH_URL=http://ctl:5000/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

stack@ctl:~$ cat demo-openrc
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=myproject
export OS_USERNAME=myuser
export OS_PASSWORD=stack$
export OS_AUTH_URL=http://ctl:5000/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

Now let’s check our infrastructure to verify that the prerequisites are in place. This has to be checked as an admin user, hence:
stack@ctl:~$ . admin-openrc
stack@ctl:~$ openstack endpoint list

The endpoints needed for the different Openstack modules to communicate between them are properly setup.

The network agents and compute services are up and running And Nova is providing the needed resources to launch a VM.
Let’s check if we already have some networks defined

It looks like we have a few networks defined, the “provider” network is the one that is connecting to the external world and this is where the floating ip addresses will be defined. This provider network has been created with the following command:
openstack network create –share –external –provider-physical-network provider —provider-network-type flat provider

The net0x networks are VXLAN networks that were created previously. The related subnets (in Openstack a subnet is essentially an IP address space) are listed below:

Creating the VXLAN where to launch the VM is a 2 step process: at first we will generate the “physical network” and then we’ll associate an IP address space to it. This has to be completed as a user so we will need to source the right credentials:

stack@ctl:~$ . demo-openr

Let’s create the network net05

We have now a new network as outlined by:

We can now associate an IP address space to net05 by creating an Openstack subnet:
stack@ctl:~$ openstack subnet create –network net05 \
> –dns-nameserver 8.8.4.4 –gateway 10.5.5.1 \
> –subnet-range 10.5.5.1/24 subnet05

We now have a subnet associated with the net05 network:

And by listing the subnet we can see the Ip address space associated:

Note that creating a new subnet translates into creating a new namespace in the Linux host, hence the output of the ip nets commands permits to relate the subnet just created to the specific namespace. (id: 6 namespace is composed by qdhcp + Openstack network ID relative to net05)

We can now proceed to launch our VM on net05, but before that we can check the flavor (type of virtual hardware) and images available

We need two additional parameters before creating the VM: the keypair is used to connect to the VM via ssh without the need for a user password and the security group is used to enable ssh and ICMP through the default iptables created at launch time. As this is a network created for a specific user we need to source the right credentials
stack@ctl:~$ . demo-openr

And the create the security group and the key pair
stack@ctl:~$ openstack security group rule create –proto tcp –dst-port 22 default
stack@ctl:~$ openstack security group rule create –proto icmp default
stack@ctl:~$ ssh-keygen -q -N “”
openstack keypair create –public-key ~/.ssh/id_rsa.pub keyA

We can now create and run an instance on this network

Take note of the id (b7030d0e-3a62-4fed-aa03-e55e1aa16540) of this server as we will use it later. We now have an additional VM: VM55 with IP address 10.5.5.213.

Now to enable this VM to access the Internet we need to connect it to a router that will provide connectivity between net05 and the provider network.
So let’s try to see if we have a router for that:

We need to check if r01 has an interface on network net05 and if not we need to add that interface to r01. This can be checked by looking at the details of router r01 through the command
stack@ctl:~$ openstack router show r01
Unfortunately the output of this command is not easy to read, I prefer to look at the associated namespace

So there is no interface on r01 for net05, let’s add one

Router r01 now has an interface on net05, hence we can try to ping the VM from that interface:

Good ! We can ping the VM interface, it’s time now to add a floating IP address to that VM so we can ssh into it from any host on the provider network.

We can now assign this Floating IP address (192.168.1.171) to VM55
stack@ctl:~$ openstack server add floating ip VM55 192.168.1.171
And try to ping this Floating IP address

So we can reach VM55 from CTL interface on the provider network, let’s identify the interface name

We can now ssh into VM55:

As this setup is made of just 1 compute node and 1 controller node, let’s check on compute node to identify VM55, go to /var/lib/nova on the compute node

Let’s check the files in the instance director

We have a number of subdirectory named after the ID of the instance, let’s check it out: the server creation command for VM55 has returned an ID of b7030d0e-3a62-4fed-aa03-e55e1aa16540, which is listed in the command output above. Change to that directory:

It looks like we have the disk image file and the console output log.

VM55 is running on the compute node, it’s a CirrOS image it can be accessed by ssh on the floating IP 192.168.1.171; from its perspective VM55 believes it is connected to net05 (10.5.5.0/25) with the IP address 10.5.5.213. As a final step let’s check if VM55 can ping google.com: