SlickStack

Blog

  • Overlay vs Underlay in SD-WAN & DC- Easy Guide

    Overlay vs Underlay in SD-WAN & DC- Easy Guide

    The “Overlay vs underlay” discussion is important as overlays are everywhere in networks- in the Datacenters (DCs) and in SD-WAN.

    And there are many tutorials out there explaining overlays and in particular difference between overlay and underlay. However, they are difficult to understand, and more importantly, they do not address the most important point – what problems overlays are trying to solve. What are the limitations in the underlays that triggered a need for the overlays?

    Therefore this blog takes you step by step on the concept of underlay, its limitations, and how overlay solves it.

    I will do so using SD-WAN as a reference, but the concepts are the same in the Datacenter i.e SDN in Datacenter also uses the concept of overlays.

    Difference of Overlay and Underlay networks in summary

    Overlay vs underlay in summary
    An Underlay network is the physical network responsible for the delivery of packets like DWDM, L2, L3, MPLS, or internet, etc. while an overlay is a logical network that uses network virtualization to built connectivity on top of physical infrastructure using tunneling encapsulations such as VXLAN, GRE, IPSec.

    Why overlay networks are important and worth discussing?

    Do you know that traditional routers and switches are hardware-centric and perform packet forwarding based on the destination IP address, therefore network segmentation and multi-tenancy are not possible.

    This creates the following inefficiencies and drawbacks: Network segmentation and network slicing are not possible – duplicate IP address ranges cannot traverse a single IP network natively; Scaling is hard. VPNs can solve these issues albeit with some inefficiencies as they are very transport medium centric and explained below.

    On the other hand, the overlays bring the flexibility that underlay is not able to provide. Overlays have been there for a quite while but with the SD-WAN they have become very popular.

    This blog uses the example of SD-WAN, but the concepts and advantages are exactly the same for the Datacenters, you will just replace the CE router with a virtual machine ( VM) that needs to communicate with Spine switch which is the CE a the HQ in this example. The underlay network is the MPLS here, it can be any routing protocol in Datacenter like OSPF, BGP, etc.

    Let’s start to understand underlay before going to overlay

    Let’s take the example of a common physical infrastructure for example a WAN network, In which a customer has three sites A, B, C with the C as the HQ which are all physical devices. There is a layer 3 IP/MPLS VPN between the 3 sites which is the underlay for this customer.

    This is a Peer-based VPN, which means that the CE ( Customer Edge) peers with PE ( Provider Edge router), exchange routes, and then how the routes are advertised between the PE is the responsibility of the MPLS provider and not the customer who owns CE. Once CE handovers traffic to PE, it forgets on how it is transported inside the Provider network and which route it takes.

    Traditional MPLS connectivity
    Traditional MPLS

    What problems underlays cannot solve?

    While the above shows a simple example of a Layer 3 underlay. Things have changed beyond the use of just “MPLS” for transport. Think of it! internet is everywhere. High-speed data is cheaper than before. Exploiting the use of the internet for carrier transport is just a natural evolution then.

    To understand the concept of overlay, I introduced two more networks. A broadband network and the 4G network. The need is to use these “low cost” transport networks to offload some of the data from the MPLS network ( if not all)

    There are some issues here :

    Traditional underlay
    Traditional underlay

    Issue 1: The Internet cannot be used as an underlay for private traffic

    The first issue is that internet medium natively is insecure so it cannot be used as an underlay for private traffic. To protect it we will need to use security protocols like IPsec. IPsec is a tunneling protocol. Which is an overlay. ( but we wanted to solve the issue with underlay, isn’t it? )

    Issue 2: Transport Dependence is too restrictive

    Let’s for the moment assume that the internet is secure so we kill the first argument against the underlay. The customer wants to divide the applications between the different circuits ( for example YouTube on 4G, A SaaS app on broadband, and email on MPLS). Further, he wants to use the backup of MPLS as broadband. All this is possible but very complex and static which means if the customer wants to change the application’s distribution over the circuits. He needs to change his configurations which is operationally NOT easy. To put it simply the configurations are hardware-specific, which means they are specific to the physical underlay and complex to change.

    Issue 3: Multi-Path forwarding

    The customer wants load balancing by combining underlays of different types.

    However, it is very complex ( if not impossible) to use multiple underlays which are of different types, simultaneously to forward traffic from source to destination.

    Welcome to the Overlay Networks. The software instead of hardware is the solution

    Until now we learned that if we stick with the underlay, it can restrict us in multiple ways. In order to get transport independence, overlays can come to our rescue.

    Overlays are software-based and not dependent on transport. It’s like a virtual network ( virtual links) on top of the physical network. This virtual network needs to have underlay created first.

    The trick is simple. Create an underlay once and forget it. Now create overlays on top of it and since they are software-based. changing the configurations is super easy and friendly. Underlay is a pipe on which overlays run. The intelligence is all in the overlay.

    However, to have overlays in SD-WAN, we will need a special CPE called SD-WAN edge device. These overlay nodes are installed at all the sites.

    overlay vs underlay explained
    overlay vs underlay in SD-WAN

    How Overlays are formed?

    The following example shows a GRE tunnel formed by SD-WAN Edge Device. The edge device adds a GRE tunnel header with a new IP header and masks the inner IP header from the MPLS domain, the MPLS forwards based on the outer IP header.

    Once the packet reaches its destination, the SD-WAN edge removes the outer IP header and the Tunnel header and what we get is the original IP packet. During all this process the overlay is not aware of the underlay.

    The same process can be done for the internet underlay but with the addition of encryption using IPSec. All this can be done seamlessly using the same SD-WAN Edge box.

    The overlay is formed once encapsulation happens at the left SD-WAN box and ends when the header is removed at the destination. The overlay is not aware of the underlay on which it is riding. The underlay here is MPLS but it can be any other type of transport.

    overlay vs underlay architecture

    How Overlay networks solve the issues ( Advantages of Overlays)

    1, the Security issue is solved by using encryption. A Public underlay such as the internet is not trusted. SD-WAN edge solved that issue through the use of IPsec ( This solves issue 1 above)

    2. Transport Independence. The same SD-WAN overlay can seamlessly connect to multiple different media like the internet, MPLS, L2 media, etc. The overlay does not care about transport media as it is using tunnels. With this, it opens the world of innovation and flexibility in the services. The intelligence is now in the software and not in the hardware. The applications can be dynamically forwarded and distributed between the 4G, broadband, and MPLS. There can be multiple ways in which traffic can be protected between different transport media. ( This solves issue 2 above)

    3. Considering overlays are transport agnostic, there is no limit on the number of multi-paths that can be used in overlays to carry traffic from source to destination for the purpose of load balancing. This makes overlays very scalable.

    So in summary overlays wins in all cases and that’s why they have become popular these days.

    Overlay vs Underlay in summary

    ItemsUNDERLAYSOVERLAYS
    DefinitionUnderlays networks are the physical networks responsible for the delivery of packets like DWDM, L2, L3, MPLS, or internet, etc.while overlays are a logical network that uses network
    virtualization to built connectivity on top of the physical network using tunneling encapsulations such as VXLAN, GRE, IPSec.
    EncapsulationDoes not require encapsulationRequires encapsulation such as VXLAN, GRE, etc
    Application
    Segregation    		Very complex to divide applications across different underlaysVery easy to achieve this
    Hardware or softwareHardware-based connectivity.Software-based connectivity
    Multi-path forwardingComplex to set up multipath forwardingInherent support for multipath forwarding
    ScalabilityLimited scalability as hardware-dependentMore scalable as software-based and because of the multi-path capability
    SecurityPhysical underlay such as the internet is not secureSecurity can be easily added using encryption methods such as IPSec.
    Deployment timeLong deployment cycle as hardware-dependentQuicker deployment time. Adding and changing services is very quick

    Reference: https://datatracker.ietf.org/doc/html/rfc4110

  • 5G Latency- You wished you knew it before!

    5G Latency- You wished you knew it before!

    So you want to know about 5G latency?

    And you know that the minimum latency needed for 5G is 1 ms or less.

    What if I tell you that you may be completely misunderstanding how this latency works in “5G”

    For example, tell me the following.

    • Is the latency from the cellphone to the core?
    • Is it from the base station to the application?
    • Is it a round trip or one way?

    Let me tell you, I do see a lot of confusion here. I do find a lot of well-meaning people make an unintentional “mistake”.

    For example, it is very common to use “round trip delay” for all latencies when in fact it is a “one-way delay”.

    If you start with the wrong reference, you end up with the wrong answers. An application hosted in a data center placed with the understanding of round trip time “RTT” will have a different distance from the reference point than one placed with a one-way delay.

    Wrong placement of data center is a wrong CAPEX investment. Above all, it can result in a bad customer experience for the low latency service.

    Understand the “Latency Reference” before the “Latency”

    Do you know that knowledge about 5G latency is important but a more important thing is how the latency is defined itself? or the “Latency Reference”

    I will help you clarify the concept with this blog piece and I will use the main industry references i.e. NGMN and 3GPP.

    More specifically

    This blog piece will clarify the following points

    • Exact reference for latency measurements to clarify the confusion.
    • Latency values for different uRLLC use cases in 5G

    Also perhaps you want to establish Edge Cloud or MEC so you are interested in knowing the correct 5G latency reference and values

    Why it is important to discuss 5G latency in the first place?

    As the 5G moves to an era of new services like low latency uRLLC, latency becomes a critical factor in dimensioning the cellular network. This is also important when designing a cellular network for network slicing.

    Life was quite easier with the initial 5G services like “eMBB” that require faster speed, however, It is no longer the case for latency-prone uRLLC services.

    A common perception is that the most important benefit 5G brings is higher data speed. However, 5G is designed to support other services that do not necessarily need high speed but need low latency.

    What are these 5G terms?

    eMBB vs eMTC vs uRLLC

    eMBB: Enhanced Mobile Broadband-High data rate and high traffic volume- This is the first use case for 5G that supports high bandwidth broadband/download speed.
    mMTC : Massive Machine-Type Communication: Massive number of low cost, low energy devices. A common example is a massive number of IoT devices in a small geographical area. It is characterized by low bandwidth but high density per given area/high connection density.
    uRLLC-Ultra-Reliable Low-Latency Communication: This is characterized by very low latency communication. ( some less than 1 msec). Some examples are Self-Driving car, Robots Control, factory automation, Remote Surgery, virtual reality, etc

    Clarifying “Latency Reference”. Is it One Way or Round Trip

    We will use NGMN and 3GPP as reference for our discussion.

    Let’s start with the NGMN reference as 3GPP is using NGMN for latency references.

    Consider a simplified network stack shown for typical network architecture.

    A source system with seven OSI layers and a destination system with the seven OSI layers. The mobile network includes RAN ( Radio access network) the core network and the application server.

    Correct 5G latency Refernece
    End to End Latency Reference: Modified from NGMN

    The source talks to the destination, for example, “End Point 1” ( like a sensor or it can be an application on the cell phone) talks to the End Point 2, which is the Destination App. This is the location that hosts the server where Destination App resides.

    So according to this paper from NGMN, “End to End latency” is defined as follows:

    “End-to-end latency is defined as the time that takes to transfer a given piece of information from a source endpoint device to a destination endpoint device, measured at the application service access points, from the moment it is transmitted by the source endpoint device to the moment it is successfully received at the destination endpoint device”

    Terms :

    UE: User Equipment-An equipment that allows a user access to the network services. For example a cell phone
    gNodeB: This is the base station in 5G and part of the Radio Access Network. Alternatively, it can be a base station (eNode B) in 4G in this architecture.( in layman terms it is the cell tower)
    UPF: User Plane Function: UPF is an important component of 5G core network. Think of it a gateway through which packet flows to the applications and contribute to user plane latency. An application’s example is youtube or Facebook etc.

    So, when the NGMN or 3GPP uses the word E2E ( End to End) latency, it is the one-way latency. In this diagram it is the latency from Point A to point E. However normally people assume that is the End to End latency. In contrast, E2E latency is from A to E and the reverse, which is E to A.

    But there are other latencies too as shown is the table below. But whenever the standard bodies are referring to the latencies, it is from the source to the end point which includes the application

    Latency References

    Now lets look at another reference. This one is from 3GPP. This one also shows End to End latency and its thresholds.

    5G Latency Requirements ( Latency thresholds in 5G from 3GPP)

    So now lets take an example of latencies from standard bodies. We will refer to the 3GPP TS 22.261, Service Requirments for the 5G. All these latencies are one way. In fact, 3GPP is using NGMN as a reference for these latencies.

    5G latency End to End Values
    End to End latencies 3GPP Ts 22.261

    This standard defines the End to End latency as following

    “End-to-end latency: the time that takes to transfer a given piece of information from a source to a destination, measured at the communication interface, from the moment it is transmitted by the source to the moment it is successfully received at the destination”

    So lets clarify some of the FAQs

    Conclusion: End to End latency is one way and NOT a round trip?

    Usually, NGMN and 3GPP specify End to End (E2E) latency which is “one way”. However in In few cases, it will mention round trip latency but it will clearly specify “round trip”. Here is the definition of end-to-end from 3GPP TS 22.261

    end-to-end latency: the time that takes to transfer a given piece of information from a source to a destination, measured at the communication interface, from the moment it is transmitted by the source to the moment it is successfully received at the destination

    Why it matters to know that it is a one-way or round trip?

    The whole science of placing the application closer to the user is dependent on the latency budget, a wrong decision can lead to the wrong placement of the Data center. Wrong placement will lead to impact the uRLLC services designed for low latency applications.

    Is 1ms ( millisecond) the minimum latency requirement for 5G?

    As opposed to popular belief, 1 ms latency is not required for all services. Some services have relaxed latency requirements. The figures above take from 3GPP TS 22.261 show only 1 service that requires less than 1 ms latency i.e. Real-time control for discrete automation. This includes use cases such as motion control of robots, machine tools, factory automation etc

    How is this latency different than the Fronthaul latency?

    Fronthaul latency is a different latency than the E2E latency budget. The fronthaul latency helps in deciding where to place the DU/BBU rather than application itself

    So that’s it about the latency. It is important to know the limits when you are designing the network for low latency applications , be it Smart Grid, Autonomous Driving, factory automation, self-driving car etc. This will severely affect the quality of service if the network is not properly designed for the required latency. Also it will also mean that the network slicing is not properly dimensioned for latency.

    Tell me in the comments below what do you think about this article or the 5G latency

  • Open RAN tutorial- A Difficult Topic Made Easy

    Open RAN tutorial- A Difficult Topic Made Easy

    Looking for Open RAN tutorial ?

    What is Open RAN/O-RAN and why it matters for mobile operators and vendors?

    In fact, as wireless networks continue to grow, O-RAN is becoming more relevant for Mobile networks.

    For one, disaggregation of RAN has remained non-existent. Thanks to a few big vendors’ monopoly. The RAN has been largely a closed vendor system.

    In fact, Open RAN has taken the Mobile Networks industry by storm and for one reason: It refers to the commoditization and disaggregation of RAN hardware.

    There are a lot of tutorials on Open RAN but they miss the point in explaining what problem Open RAN is trying to solve.

    Secondly, the tutorials do not tell about what is the 3GPP interfaces versus the O-RAN interfaces.

    I will explain this as well as the Open RAN architecture, and all the important terms that you should know.

    And I will do it in an easy to follow manner.

    But hold on , there is another term-OpenRAN (without space between Open and RAN), and I should clarify it first as it is different than Open RAN ( the one with space)

    Open RAN vs OpenRAN

    OpenRAN without space is different than Open RAN with space.

    In fact, these terms confuse the beginners a lot.

    Open RAN, or O-RAN, is the initiative of the O-RAN alliance that aims to define open interfaces of split RAN architecture. The group focuses on the development of open and virtualized interoperable RAN specifications. In this article, we will focus on exactly this topic.

    OpenRAN, on the other hand, is a project by Telecom Infra Project that aims at disintegration in the 2G/3G./4G/5G RAN by having multi-vendor interoperable solutions built on general-purpose hardware (COTS).

    OpenRAN does not define new Open interfaces but speeds up adoption and deployments through the use of existing open interfaces. In that respect, it works closely with the O-RAN Alliance to re-use their interfaces doing no overlapping work.

    Not only O-RAN but it works with the other industry bodies like 3GPP, ONF to facilitate a holistic end-to-end RAN solution. This diagram better summarizes the relation between OpenRAN and O-RAN.

    OpenRAN laison- Ref: https://telecominfraproject.com/openran/

    Let’s switch gear to Open RAN/O-RAN

    So lets discuss the real topic in this article, i.e. Open RAN.

    O-RAN ALLIANCE, founded in February 2018 by AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO and Orange. It has been established as a German entity in August 2018.

    Here is the charter for Open RAN alliance

    • The specification effort => new standards for open and intelligent RAN
    • O-RAN Software Community => open software development for the RAN (in cooperation with the Linux Foundation)
    • Testing and integration effort => supporting O-RAN member companies in testing and integration of their O-RAN implementation

    What Problem Open RAN is trying to solve?

    To answer this question, we should first understand the nature of RAN.

    Isn’t RAN a closed system? In fact, the RAN edge is an example of a perfect vendor lock-in.

    Unfortunately, 3GPP has not defined the interface between the radio unit (RRU) and the BBU as shown in the figure. They have left this to the vendors to implement. Consequently, the interface between RRU and BBU is a closed interface ( also called fronthaul)

    And guess what!

    The mobile operators must buy both RU and from the same vendor.

    Yes,

    Even if the operator wants to mix and match vendors between the RU and BBU, he cannot do it. (The traditional CPRI interface between RU and DU is still a proprietary interface, although agreed by a few big vendors)

    But that’s not all.

    While fronthaul is the major component, there are other components in RAN as well. For example, the X2 interface between eNodeBs is also a closed interface.

    This is even worse.

    How ?

    As you are aware that in NSA ( Not standalone) 5G uses the same core as 4G but works in coordination with 4G access network using X2 interface. If X2 interface is closed, that means that the 4G and 5G vendor needs to be the same, otherwise they will not inter op. O-RAN alliance is working on making all these interfaces open and standardized.

    So the big problem O-RAN is solving is making all these components interoperable so one can mix and match the vendors.

    Traditional RAN
    Traditional RAN

    Is Open RAN the same as C-RAN or Virtual RAN (vRAN)?

    No, it is more

    The debate between Open RAN and Virtual RAN is interesting.

    The following diagram summarizes the differences. And I have written this article on what are the differences. In summary, Open RAN is the type of Virtual RAN that uses Open interfaces between RAN components while C-RAN/vRAN does not. We will now study all these components one by one.

    I will also recommend to go through the article to understand the role of RU, BBU, DU, CU etc.

    O-RAN and virtual RAN compared
    D-RAN vs C-RAN vs vRAN vs O-RAN

    Components of Open RAN/ O-RAN ( Open RAN tutorial)

    Let’s go through the O-RAN architecture. The components are hosted virtually on servers using virtual machines or cloud native technology such as containers.

    O-RAN architecture has many components but here is the list of the important ones ( taken from O-RAN specifications) that can serve a cheat sheet

    Open RAN/O-RAN tutorial
    O-RAN Architecture ( Ref O-RAN Alliance)

    Service Management and Orchestration (SMO)

    Non-RT RIC ( Non Real Time RAN Intelligent Controller)

    Responsible for the FCAPS of O-RAN network functions. This has an important function called Non-RT RIC, which is used for RAN optimization. Non-RT RIC or Non-real time RIC has the goal of supporting intelligent RAN optimization in Non-real-time (that is greater than one second) by providing policy-based guidance using data analytics and leveraging AI capabilities

    Near-RT RIC

    Near-RT RIC enables near-time control and optimization of O-RAN nodes ( O-CU AND O-DU). It uses near real-time control loops (i.e. 10 ms to 1 second). Latency is very critical for the Near-RT to take quick decisions. This is in contrast to the Non-RT RIC. Whereas Non-RT RIC can reside far from the Radio Access Network nodes, The Near-RT RIC has to be closer to the RAN nodes owing to the real-time decision functionality.

    3GPP Interfaces

    3GPP maintains the following interfaces and not O-RAN. Looking closely, the interface from the core network towards the CU and between the CU and DU are the domains of 3GPP. They are already standard and defined by 3GPP. They are already interoperable between the vendors. The O-RAN alliance will not re-work here, as there is no need for that.

    •E1 interface
    •F1-c interface
    •F1-u interface
    •NG-c interface
    •NG-u interface
    •X2-c interface
    •X2-u interface
    •Xn-c interface
    •Xn-u interface
    •Uu interface

    O-RAN interfaces

    O-RAN defines and maintains the following interfaces:

    •A1 interface
    •O1 interface
    •O2 interface
    •E2 interface
    •Open Fronthaul interface

    O-DU

    Open DU (Distributed Unit) terminates multiple interfaces, but most importantly the fronthaul interface.

    O-DU: O-RAN DU is a logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.

    O-DU is the most popular component and source of innovation in O-RAN as the interface between O-DU and O-RU which is traditionally a closed one is being standardized through a standard version of eCPRI ( Open fronthaul) so that any two vendors can inter-work here.

    O-CU-CP and O-CU-UP

    O-CU: O-RAN Central Unit: a logical node hosting RRC, SDAP, and PDCP protocols

    In fact, it has a control plane and user plane as follows:

    O-CU-CP: O-RAN Central Unit–Control Plane: a logical node hosting the RRC and the control-plane part of the PDCP protocol

    O-CU-UP: O-RAN Central Unit–User Plane: a logical node hosting the user-plane part of the PDCP protocol and the SDAP protocol

    O-RU

    O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional split.

    O1 interface

    O1: Interface between management entities in Service Management and Orchestration Framework and O-RAN managed elements, for operation and management, by which FCAPS management, Software management, File management shall be achieved.

    O-Cloud

    Everything is virtual. Isn’t it ? The first question is that where are the virtual functions hosted?

    If they are containers, where are the containers deployed? A general name given to the cloud infrastructure is the O-Cloud. It hosts but not limited to O-DU, O-CU-UP, O-CU-UP. The virtualization of the O-RU is for the final study.

    Benefits of Open RAN

    Reduction in CAPEX

    O-RAN can reduce CAPEX through the use of commodity hardware and software. Low-cost white box hardware can reduce the cost of 4G and 5G deployment. It eliminates the vendor lock-in by having multi-vendor interoperable components in the Radio Access Network. This enables a more competitive supplier ecosystem for service providers that can lead to a reduction in CAPEX spending.

    Improving Network Efficiency and Intelligence

    O-RAN improves network efficiency and performance by leveraging RAN automation. With O-RAN, the status of network resources and performance is continuously monitored and more real-time close loop control loop actions can be taken with less human intervention. O-RAN provides the inherent ability to offer efficient, optimized radio resource management through close loop control and hence can optimize performance and efficiency.

    Intelligence is the core principle of O-RAN. The network must be able to operate on its own and continuously learn in order to provide embedded intelligence through the network life cycle.

    Increase in Network agility

    Thanks to the cloud-native architecture, the software can be easily upgraded without wholesale changes in the network. This also means new services can be rolled out quickly through the introduction of new microservices, thus providing a stepping stone towards agility.

    Challenges to Open RAN

    Nevertheless, Open RAN has some challenges. Having multiple vendors in the RAN is good, but this would lead to an additional onus on the service provider to play the role of the system integrator or outsource it to another party. In both cases, it’s complex to maintain such a heterogenous network or could be costly. Which can lead to OPEX.

    Thats all from my side, There has been a lot of innovation in the Edge and Open RAN is one of them. It is time that you learned about this concept very well.

    Now its time that you tell me if Open RAN has a future or not.

    Referenceshttps://docs.o-ran-sc.org/en/latest/architecture/architecture.html

    O-RAN Use Cases and Deployment Scenarios by O-RAN alliance

  • C-RAN vs Cloud RAN vs vRAN vs O-RAN vs traditional RAN- Guide!

    C-RAN vs Cloud RAN vs vRAN vs O-RAN vs traditional RAN- Guide!

    OK, you have heard enough of these terms perhaps from RAN vendors? C-RAN vs Cloud RAN vs vRAN vs O-RAN in the context of Radio Access Network ( RAN)

    However, these terms are not clear to you because everyone out there explains them in a way that is enough to confuse many. The fact is that they are confusing as the terms are similar and there is not a lot of difference in them.

    That is where this blog can help to explain these technologies related to RAN architecture. It will settle the explanation of these terms, once for all.

    And don’t worry, if you don’t know what is RRU, BBU, CU, DU, fronthaul, mid haul; I will explain all these terms as we go through.

    Radio Access Network has evolved quite a bit, so it’s important for you to be aware of all these new terms.

    Understanding all this will help in understanding a vendor RAN solution.

    C-RAN vs cloud RAN vs vRAN vs O-RAN vs D-RAN (traditional RAN) ? Is it that difficult to understand?

    Not exactly, once you understand D-RAN ( traditional RAN), it is easy to understand the rest of them regarding RAN architecture.

    Lets go step by step to understand D-RAN ( traditional RAN) first and then moving to other types

    The following diagram summarizes the differences but we will explain it in a moment.

    D-RAN vs C-RAN vs vRAN vs O-RAN
    D-RAN vs C-RAN vs vRAN vs O-RAN

    What is D-RAN ( traditional RAN) ?

    D-RAN stands for “Distributed RAN”

    The diagram below shows distributed RAN. The RRU and BBU are co-located at every cell site. Each cell site with all its radio functions are distributed and connected back to the core network through backhaul.

    WHAT IS D-RAN ( Distributed RAN), the traditional RAN
    What is D-RAN ( Distributed RAN)

    What is it ?
    BBU: Baseband unit. Manages the whole base station, including operating/maintenance and signaling processing. It decides the “CAPACITY” of the system.
    RRU: Remote Radio unit interfaces with an antenna on one end and BBU on the other. It connects to BBU through CPRI interface and converts RF signal into data signal and vice versa. Further, it does filtering and amplification of RF signal. In fact, it decides the “COVERAGE” of the system” 
    Antenna: It interfaces a cell phone wirelessly and transmits/receives RF signal. It decides the “SHAPE” of the coverage.
    Reference: ITU-T

    What is C-RAN / Cloud RAN

    C-RAN (Also CRAN) stands for Centralized RAN or Cloud RAN. In fact, I have seen the industry uses these terms interchangeably.

    In C-RAN (Cloud RAN) the BBU moves to a centralized location and the cell site only has the antenna and the RRU. This centralization of BBU functionality (also called BBU pool) results in the name centralized RAN or C-RAN.

    What is C-RAN ( Centralized RAN/ Cloud RAN)
    What is C-RAN ( Centralized RAN/ Cloud RAN) ( Option 1)

    This results in a new interface called fronthaul, which is between the RRU and BBU pool. The benefits of C-RAN includes CAPEX and OPEX reduction as deployment and maintenance cost per cell site are reduced because of BBUs centralization. In addition, it improves spectral efficiency and reduces inter channel interferences, as centralized BBUs can share the resources dynamically among the multiple RRUs. The inter-channel interference is eased because of the joint scheduling and processing.

    In addition, a second option of the centralized RAN architecture has a further split in BBUs into DU and CU. Here, CU is further towards the core network resulting in a new interface called midhaul.

    Option 2: C-RAN with BBU Split
    Option 2: C-RAN with BBU Split

    What is it ?
    Fronthaul     Fronthaul is the link between RRU and BBU (or RRU and DU). It has a strict latency requirements of 100 to 250 µs (one way)
    Midhaul: Midhaul is the link between DU and CU.. Midhaul has relaxed latency requirements, which means we can place CU further closer to the core node.
    DU: Distributed runs the RLC, MAC, and parts of the PHY layer. We normally place DU closer to RRU.
    CU: Centralized Unit handles the RRC and PDCP layers (and SDAP in case of 5G) . One CU can connect to multiple DUs, CU can be co-located with DU or far from DU.

    What is vRAN or Virtual RAN?

    vRAN decouples the software from Hardware by virtualizing Network Functions. It uses virtualization technologies such as NFV or containers to deploy CU and DU over x86 server. (or virtual BBU on a server). This is like running Functions in software.

    So there is no difference between vRAN and C-RAN except that traditionally C-RAN uses proprietary hardware while vRAN uses Network Functions on the server platform. vRAN is infact a type of C-RAN.

    What is Virtual RAN ?
    What is Virtual RAN ?

    Because of vRAN HW/SW decoupling flexibility, we can achieve scalability. This can cause a decrease in hardware costs and application agility as application can be upgraded easily or swapped altogether (which is not easier with traditional hardware).

    However, vRAN puts servers to new limits because of the performance expectation. There has been quite an innovation on enhancing server platform to meet the performance needs of vRAN.

    What is O-RAN or Open RAN?

    Open RAN/O-RAN (from O-RAN alliance) takes vRAN to the next level. While traditionally vRAN is a closed network, as RU, DU and CU, which are all part of the RAN must be bought from the same vendor.

    The O-RAN alliance is working on specifications to open the interface between RRU and DU and further between DU and CU. This means that a customer can mix and match the components from different vendors without being locked to one vendor for all these three components, thus resulting in an open RAN network.

    WHAT IS OPEN RAN ( O-RAN)
    WHAT IS OPEN RAN ( O-RAN)

    These new open components as per O-RAN alliance’s specs are called O-RU, O-DU and O-CU (where O stands for Open) which is actually a modular base station software stack on off-the-shelf server hardware.

    So that’s it about the different between C-RAN , V-RAN and O-RAN. Hopefully, with this you will easily understand a vendor’s solution and also give you an insight on how Radio Access Networks have evolved over the time. Let me know in the comments if the concept is clear to you?

  • What is SASE? The beginner’s tutorial!

    What is SASE? The beginner’s tutorial!

    What is SASE or Secure Access Service Edge ?

    Is it SD-WAN? Is it something related to security? Everyone talks about SASE, very few are clear on the concept and its positioning versus SD-WAN and Security.

    The jargon out there in the literature is enough to confuse many.

    I will try to make it easy for you to understand if you follow along. In the end, you will know and appreciate SASE, its benefit and understand exactly the “SASE and SD-WAN difference“

    When Gartner used this term for the first time in 2019, many took it for granted. Some ruled it out as having something that could impact the networking industry.

    Today SASE has got enough traction with many vendors rolling out solutions under SASE.

    What is SASE? Definitions

    Gartner defines SASE as


    “The secure access service edge is an emerging offering combining comprehensive WAN capabilities with comprehensive network security functions (such as SWG, CASB, FWaaS, and ZTNA) to support the dynamic secure access needs of digital enterprises”


    In simple words by Gartner, SASE is a combination of networking and Security.


    And as described in simple words by a blog at Gartner here


    “SASE combines network security functions (such as SWG ie. Secure Web Gateway, CASB, FWaaS, and ZTNA), with WAN capabilities (i.e., SDWAN) to support the dynamic secure access needs of organizations. These capabilities are delivered primarily aaS and based upon the identity of the entity, real-time context, and security/compliance policies”


    However, I like the MEF definition as it is more simple

    “A service connecting users (machine or human) with their applications in the cloud while providing connectivity performance and security assurance determined by policies set by the Subscriber.”

    What is SASE?


    What Problem SASE is trying to solve?


    As enterprises transition to digital transformation, more and more applications are moving to the cloud. Applications, no longer reside on-premises or in the data centers and more and more workforce is becoming remote and mobile, the cloud and mobility both present challenges to enterprises.

    For example, if the data center is no longer the center of applications? Would it make sense to have all connectivity routed through the data centers for security checks as traditional connectivity would demand?

    When applications are sprawled all over the cloud, what would be the best way to connect users with applications.

    Yes SD-WAN does solve the problem of connectivity by offering users a way to connect to clouds directly bypassing HQ in many cases. However, it is only half the story.

    It is easier said than done! How?

    Less efficient way of traffic through HQ

    It would call for additional security checks most likely at the branch office, itself. Shifting the security nucleus from HQ to the branch offices is not a scalable solution.

    Adding more security appliances ( NGFW, IPS, IDS) at the branch offices is both CAPEX and OPEX intensive. It makes the job of the IT team complex to maintain and troubleshoot.

    Could there be a better way?

    Welcome to the world of SASE!

    SASE offers a way for enterprises to connect to the clouds directly in a secure way without having advanced security appliances on-site, Security is offered by the cloud itself. The SASE provider would offer its PoP closer to the users offering all advanced features as a service for NGFW, CASB, SWG.

    SASE Architecture /SASE Cloud


    With SASE latency matter for the applications, The SASE solution, therefore, offers distributed PoPs with some closer to the users to optimize the latency and user experience. SASE will act as a gateway routing the traffic through SASE gateways to the applications elsewhere in the cloud.


    The architecture of SASE is based on cloud-native principles. A cloud-native architecture enables agility, elasticity and adaptability

    SASE cloud is implemented as a distributed cloud platform. Wherever the edges are, the networking and security features should be available to provide low latency PoP for services.

    SASE providers will establish SASE PoPs closer to the users to provide them access to the application.This will enable edge SD-WAN devices to access applications through the cloud that has Firewall as a service, Secure Web Gateway, Advanced Threat protection, all in one cloud.

    SASE Architecture
    SASE Architecture


    Is SASE only security offering through clouds?

    No!

    Security has always been offered by security vendors as a service in clouds. Zscaler and Palo Alto have been offering such solutions for quite some time.

    There is nothing new here.

    What is offered now is an integrated connectivity/SD-WAN offering mixed with the security offering as one solution by ONE VENDOR.

    Hold on! But SD-WAN has security functions too? What is the difference between SD-WAN and SASE then?
    Now before you come back asking, well SD-WAN already has security functions built-in or they can be added as service chaining on demand, what is new with SASE, then?

    Let me explain.

    As I already explained, SD-WAN strength is “connectivity” and not security. Security was brought in as a feature to help the branch offer secure access without the need for going to HQ.

    While this is a workable solution. It is not the most efficient one.

    It needs a built-up of security appliances at the branch office itself, which is complex and costly. But more importantly, it does not solve the problem of the mobile workforce ( perhaps individuals) that want to connect remotely to applications for example from another country. That sort of traffic would still need to be brought for security checks at the HQ. Which creates additional latency and longer paths.

    To understand the concept. Consider the following diagram, SD-WAN provides connectivity and security functions at a branch office, however, after transitioning to SASE, the only function needed at the branch office is the SD-WAN router, while all security functions are moved to the SASE cloud.

    Traditional network vs SASE
    Traditional Network vs SASE

    SASE says that if resources move to the cloud, the most efficient way to build connectivity is to have direct access to the clouds and hence it makes sense to have security checkpoints in the cloud themselves. That is bringing inspection points close to the applications themselves.

    Therefore SASE is a convergence of networking ( such as SD-WAN) and network security services ( such as SWG, CASB, and FWaaS, multi endpoint protection). with the added benefit of a centralized management plane enabling a single pane of glass.


    Heavy Branch to Cloud-centric Thin branch/SASE models

    Naturally, when major functions move to the cloud, the only thing left at branch office is a simple SD-WAN box that provides connectivity to the cloud. This is called “Thin Branch” and heavy cloud model
    At the site besides SD-WAN, there could be other network functions such as WAN optimization, traffic analysis functionality, etc.

    From Traditional Heavy <span class='ent _Branch'>Branch</span> to Cloud-Centric Thin Branch/SASE Models
    Source Gartner


    Identity Driven

    One of the important concepts in SASE is that it is Identity driven.

    Identity is the most important element in SASE. Every user in SASE has identity, a person, an application service or a device.
    Examples of user identity include such as
    Name of a person
    MAC address of the laptop
    Identifier of IOT Device
    The second important item is the context, which includes
    Location
    Time of the Day
    level of assurance ( NIST, X 509 Certificates, etc)
    With SASE both are important, Identity when attached with the context can provide a dynamic set of security policies that can change as the context changes. This enables a very powerful and rich set of security policies that can be applied to the users of the SASE Cloud.


    Benefits of SASE

    User Experience

    The first and foremost benefit of SASE is the enhanced user experience because of the shorter reach to the destination. Almost all traffic that was supposed to go to the HQ can now be sent to the nearest SASE PoP thus reducing latency and enhancing user experience.

    Cost reduction

    Costs are reduced as SASE eliminates the need for point solutions. Everything is integrated in a single cloud with some networking part at the customer site. The box at customer sites is simplified to the extent,, that it needs just SD-WAN connectivity up to the nearest PoP of SASE. All the heavyweight processing occurs in the cloud. OPEX is reduced as IT teams need to maintain a converged network and security stack managing all features and policies from a single interface


    Mobility


    The biggest advantage for the SASE for business is enabling mobility of the users. With the world changing to the mobile workforce, remote users ( some workforce from can connect to their enterprise/business cloud or application clouds from anywhere in the world without worrying about the security and without the need to dial in their corporate VPNs. Also home has become the office for the workforce today. All they have to do is to connect to the nearest PoP of the SASE provider. SASE simplifies the authentication process by applying appropriate policies for the relevant resources which a user seeks.

    Less Complexity, Less Integration


    With preferably one provider for SD-WAN and security, there will be no need for complex integrations because of service chains. Having multiple security vendors/functions in a service chain requires a lot of integration which results in delays to provide service and CAPEX spending
    So that’s it an introduction about SASE ( Secure Access Service Edge and I hope it is clear now on “what is sase ?”. Go ahead and comment below on what do you think as the future of the SASE.

    One final word. SASE is still not part of the Gartner magic quadrant but I expect that it will become sooner or later considering the market traction for SASE

  • From “Legacy VNF” to “Cloud Native VNF”

    From “Legacy VNF” to “Cloud Native VNF”

    Let’s face it, we all love to have everything cloud native based including cloud Native VNFs. In practice, however, we need to live with the legacy VNFs.

    The legacy VNFs are monolithic with bulky code and operated in some cases as all in one virtual machine. They can be called virtual, but not cloud-based or “cloud-native” to be more specific.

    If you want a quick overview on what is cloud native, you can see my other blog.

    It is important for you to understand a cloud native VNF as the5G Core is cloud native based.

    To understand and appreciate a cloud native VNF, I take you through a journey starting with the bare metal, then a legacy VNF, and finally a cloud native VNF.

    Before I take you through that journey, I would like to point out one simple thing that can help you understand how VNFs normally work. While a VNF can be one VNF to one VM. That is VNF is one component that completely occupies the virtual machine.

    In practice, however, VNF consists of multiple components also called microservices or VNFCs (VNF Component) as ETSI called them. As VNFs can be quite complex such as an EPC in the mobile network, no vendor will make an “All in one” VNF that occupies a single Virtual machine. It will be many small VNFCs that are connected and together give a VNF functionality.

    So lets say our VNF here consists of two VNFCs like following which we will be using in our example.

    VNF and its Components

    Having understood this components of one VNF, let’s now begin our journey.

    Bare Metal

    In bare metal, we run the application/VNF directly on the server. This is the legacy way to run applications. Take a server and install the application. There is no way to slice/partition the server to run more applications/VNFs. However the advantage is that the single application get access to the complete compute, storage and memory resource of the machine.

    So in our case, it is not possible to run our example VNF that has two components as above. What is possible is to run any single component VNF directly on the operating system ( such as Linux) of the bare metal as shown below.

    Bare Metal VNF

    Legacy VNF

    As a legacy VNF runs on the virtual machine, you would need two virtual machines to run this VNF. Additionally, the virtual machine would need a hypervisor to slice the server into multiple logical servers. With two virtual machines available, it is possible to keep each VNFC in a different virtual machine.

    Do take a note, however, that a Virtual machine would need to have a separate Operating system ( OS) called guest OS on top of the host OS. This is an extra burden on a server as you would understand shortly by comparing it with containers

    Legacy VNF

    Cloud Native VNF

    Cloud Native VNFs make use of containers. Thanks to the lightweight size of the containers that do not need a separate guest OS, it is possible to run each VNFC as a different container directly on the host OS. You do not need a hypervisor, but you will need a container engine to enable spinning up the containers.

    As you probably already have guessed that a Cloud Native is a preferred approach to building up VNF applications today as they are lightweight because they host on the same Linux kernal of the host machine without the burden of the need for additional guest operating system.

    But here is a challenge. How do keep different cloud Native VNFs separate from each other? Would you really run containers of one vendor in the same containerized environment as another vendor?

    Thats take us to the more practical approach to running cloud Native VNFs today.

    Cloud Native VNFs “On” VM

    The most practical way followed today is to keep different cloud native VNFs on different VMs. That way you can enjoy the flexibility of running a lot of these containers within one VNF and at the same time isolation between different VNFs ( perhaps of different vendors).

    So a setup like the following will allow you to add a second VNF easily in a second VM on the same server.

    Cloud Native VM on VM

    Cloud Native VNFs Plus VMs

    We run in a practical world.

    There will be legacy VNFs along with cloud Native VNFs for quite some time as we have already deployed a lot of legacy VNFs in the network and before they phase out to a more modern VNF based on cloud native application. A variation of this is to have Cloud Native VNFs run directly on the server in parallel to legacy VNFs in VMs. In this diagram you say a legacy VNF2 running with a cloud native VNF1 on the same server.

    Cloud Native + VM

    What is the future ?

    Future is all about cloud Native VNFs. There will be a time when legacy VNFs will be phased out. Then there will be a stage with containers are developed and mature enough to provide enough isolation to start running Cloud native VNFs of different vendors on the same Linux OS. That will be the time when perhaps there will be no need to have a virtual machine and a world that can live without virtual machines forever. When this happens. We are not sure at the moment.

    Do you agree ?

  • Your Quick OpenStack Cheat Sheet!

    Your Quick OpenStack Cheat Sheet!

    For a while I thought to write about an OpenStack cheat sheet showing OpenStack components, so you can refer to it as an easy to use handy reference.

    If you are using NFV, you are using OpenStack for sure. OpenStack sits at the VIM layer inside NFV MANO and is the most important piece to manage the cloud infrastructure. For a quick refresher on NFV, click here, NFV Cheat Sheet.

    Openstack is very complex. You hear a lot of terms like Cinder, Glance, Nova, Horizon, etc. They are quite confusing to know and remember. So here I made a small OpenStack cheat sheet as a diagram/infographic which you can keep as a reference. Just match the block colors with the colors of lines and you will easily know the role of each component/block and how they interact with the other blocks.

    How about sticking a copy of the diagram on your desktop for easy reference !

    What is OpenStack?

    “OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed and provisioned through APIs with common authentication mechanisms”. “https://www.openstack.org/software/“

    So here is the cheat sheet/infographic about Openstack services.

    Do take a note however that there are many more services in openStack, here are the most important core ones that you must know

    OpenStack Cheat sheet for Core Services-Simplified from openstack.org

    Description of OpenStack Cheat sheet

    Horizon ( Dashboard)

    This allows users to work on OpenStack using web GUI instead of CLI. This provides a user-friendly dashboard. This is part of common services

    Ceilometer ( Telemetry)

    The ceilometer is a component of the Telemetry project. Its data can be used to provide customer billing, resource tracking, and alarming capabilities across all OpenStack core components.

    Keystone ( Identity)

    keystone is the simplest service in OpenStack. it is a core service and provides authentication and authorization of tenants in OpenStack.

    Nova ( Compute)

    Nova is the original core component of openstack and considered one of the most complicated components in openstack. It providess compute service in openstack.

    It has various components:

    Nova components ( Ref: Openstack.org)

    Nova-Compute

    The nova-compute is responsible for creating and termination of VM instances via hypervisor APIs ( for example Libvirt KVM, VMWare API for VMware)

    Nova Conductor

    The Nova conductor provides database access to compute nodes. The logic is to have all the database access pass through Nova conductor instead of compute nodes accessing DB directly thus reducing the risks in case of compute node gets compromised.

    Nova-api

    The nova-api component accepts and responds to the end user and computes API calls.

    Nova-Scheduler

    Compute uses the nova-scheduler service to determine how to dispatch compute requests. For example, the nova-scheduler service determines on which host a VM should launch.

    Neutron ( Networking)

    Neutron is a service that provides networking service to other components of OpenStack

    Storage

    There are various type of storages in openstack. It is important to understand the difference between them

    Cinder (Block Storage)

    Cinder provides block storage in OpenStack. It provides raw volumes that can be used as a hard disk in virtual machines. It is called block storage because a large amount of data is chopped into blocks and stored with a unique identifier is attached which allows the data to be retrieved quickly and efficiently.

    Use Cases:

    • Databases-Block storage is common in databased and other mission-critical applications that demand high performance
    • Volume snapshot management
    • Attaching or detaching volumes from instances etc
    • Creating and deleting of a snapshot of the volume.

    Swift (Object Storage)

    Swift provides an object-based storage service and accessible through Rest APIs. It can easily scale, making it a great choice for public cloud storage.

    It has static nature and writing objects is a slow process, so does not work well with traditional databases. ( for which cinder works well). S3 from Amazon is a good example of object base storage.

    Glance (Image Registry)

    Glance also provides storage but acts only as an image registry. It keeps track of virtual machines images, metadata such as the kernel, disk images, disk format, etc. This is available to OpenStack users through REST APIs.

    Heat- Orchestration

    Heat manages and automate/orchestrates entire life cycle of infrastructure that includes servers, IPs, volumes, security groups, users etc.

    So thats it about the core services in OpenStack; let me know in the comments if you have any comments on this piece and if this cheat sheet helped you or not.

  • What is Kubernetes? Confused? Kubernetes and its Architecture Explained in Plain English

    What is Kubernetes? Confused? Kubernetes and its Architecture Explained in Plain English

    What is Kubernetes ? and how is kubernetes architecture ?

    To start with, Kubernetes, also known as “K8s” is an open source container orchestration platform that automates the deployment, management, load balancing, and scaling of container based applications ( also called containerized applications).

    Secondly, Kubernetes is a leader in container orchestration as this survey shows. In fact, It can orchestrate thousands of containers using open source code. And since  it is open source, a K8s cluster  can run almost anywhere including public cloud providers ( e.g. all major cloud providers like Amazon Web services, Azure)

    Indeed Kubernetes is an enabler for Platform as a service (PaaS) that creates hardware layer abstraction for development teams.

    Why do you need to know about the Kubernetes?

    Today, majority of  applications are developed as cloud native, i.e. they run as microservices/containers. Due to their lightweight size, they have become popular. 5G core, for example, is completely cloud native based. As Kubernetes is popular container orchestration platform, so it is important to know about this platform.

    The best way to understand and appreciate Kubernetes is to understand its architecture. 

    The Best way to understand “what is Kubernetes” is to understand its architecture.

    So as you are looking to know about “what is Kubernetes”, i suggest that understanding its architecture can clarify it.

    However, the info out there makes Kubernetes architecture hard to understand.

    In this step by step guide, I will make it very easy for you to understand the Kubernetes architecture clearly.

    I will make Kubernetes easy to understand through the ship analogy

    I will draw parallels between Kubernetes and cargo ships. This is an interesting analogy and you would not forget the concepts after that.

    Before understanding the Kubernetes and using the ship analogy, it is good to understand first some basic terms like Pod, cluster, and Node.

    In fact, Kubernetes is architected as a cluster of nodes, and then containers are deployed into pods using  Control Plane. The control plane manages the nodes and the pods.

    Concept of Pod, Cluster, Container, and Node

    Let’s first understand the hierarchy going from small to bigger. 

    Container > Pod > Node > Cluster

    This order will help you remember, smaller to the bigger size. The smaller resides in the bigger.

    Concept of Pod, Node, container

    Container

    This is the level 0.

    Kubernetes.io defines container as following“A container image is a ready-to-run software package, containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings”the container is the smallest unit and sits inside the Pod. However, Kubernetes does not create containers. That is the job of the container runtime, such as Docker ( more at the end)

    Pod

    This is the level 1.

    The container sits in the Pod. A Pod is defined as a logical unit of application. It can contain one or more containers and is deployed on a node. For Kubernetes PoD is the basic unit ( instead of containers) i.e Kubernetes deploy Pods ( which have containers inside) and does not create containers directly. Normally Pod will have a single type of application or it can have multiple applications if they are closely related. Each pod is assigned a unique IP address within the cluster, that enables the application to use ports without conflict. Pod to pod communication is enabled using a dedicated Pod IP address

    Node ( Worker Node)

    This is level 3.

    Pods run inside nodes.

    Nodes can be virtual machines or physical servers. A Node is a worker machine in Kubernetes. Each Node is managed by the Master. ( more about worker node and master node later on) A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster.

    Node is also called worker node in Kubernetes.

    Cluster

    This is level 4.

    At the minimum, the Cluster contains one or a group of nodes and a control plane.  containers do not need to be tied to the specific virtual machine. Containers can run anywhere, on physical, virtual, or cloud but what ties them together is them being part of a cluster.

    Kubernetes clusters are comprised of one master ( more on master later on) and a number of nodes ( also called worker nodes)

    After getting the clarity on the master and worker node, let’s see the reference architecture of Kubernetes and the role of master and worker node.

    But the best way to understand what is inside the master and worker node is to use the ship analogy.

    Lets take the next section of understanding what is kubernetes and kubernetes architecture.

    Kubernetes architecture using ship analogy?

    Kubernetes analogy to ships
    Kubernetes analogy to Ships

    Worker nodes are like cargo ships. Cargo ships take containers from source to destination. In Kubernetes, worker nodes host containers of applications. Master is like control ships. Control ships manage and monitor cargo ships

    Let’s take a look at different components of the control ship/master

    What is inside the master (Control ship)?

    Master components in Kuberentes

    The master runs control plane components. The control plane components make global decisions about the cluster as well as detecting and responding to the cluster events. Usually, control plane components are run on a dedicated machine in a cluster.

    Kube scheduler

    Kube scheduler= Cranes in control ship

    When cargo ships arrive, containers are loaded on them using cranes, , therefore there should be a way to identify where to place the containers, which ships have the capacity, constraints, etc. This is the job of the schedulers. But as Kubernetes run pods ( containers are part of the pods), so we can say that kube scheduler schedules pods on the ships ( on the worker nodes)

    The scheduler takes into account the resource needs of the pods, such as CPU or memory, along with the health of the cluster. Based on this, it can schedule pod to the appropriate compute node

    etcd

    etcd= cargo ship profiles

    As containers are loaded and unloaded from ships on daily basis. There should be a database that needs to keep track of all this information on where are those containers and at what time they are uploaded. etcd is a database that stores this information ( It is like a source of truth) This is analogous to a “cargo ship profiles” that has details of all such information.

    kube api server

    api server = The department in control ship that manages communication

    There are multiple offices onboard a ship. As well there are external stakeholders. Who manages the communications within internal and between the internal and external entities? kube-api server serve exactly that purpose

    kube controller manager

    Kube-controller-manager = captain of the master node

    Kube controller manager

    In Kubernetes, the kube controller manager runs a different kind of controllers that control different functions like ( it is like the captain of the master node)

    1. Node controller- responds when nodes go down
    2. Replication controller-responsible for maintaining the correct number of pods
    3. End point controller-Populates the endpoint objects like joins, services, and pods.

    In ship analogy, kube controller manager is managing different offices in dock like operation office ( the team that responds if any issue with the worker node), replication office (the team responsible for maintaining correct number of pods)

    What’s inside the worker node (Cargo ship)?

    Kubernetes architecture
    Kubernetes architecture

    kubelet

    Kubelet =captain of the worker ship

    This is an agent that runs on each node of the cluster. It listens to instructions from kube-api-server and manages the Pods and the containers running on the machine.

    kube proxy

    kube proxy= manages communication between worker ships

    kube proxy manages communication between different containers deployed across different nodes. For example, a packet core may have multiple different services, one service deployed on one node, while another on another node that needs to talk to one another, the kube-proxy facilitates this kind of communication

    In terms of ship analogy, kube proxy manages communication between different worker nodes.

    container runtime

    You need to install a container runtime into each node in the cluster so that Pods can run there. 

    Container runtime is installed in each node in the cluster so that pods can run there. Docker is one of the popular container runtime but there are others such as the Open container initiative.

    So thats it, I hope it is clear now on what is Kubernetes and Kubernetes architecture. Please leave a comment below and let me know your thoughts on whether it is now easy for you to understand Kubernetes ?

    References:

    slideshare-demystifying-the-nuts-bolts-of-kubernetes-architecture

    https://opensource.com/article/20/6/container-orchestration

    https://kubernetes.io/docs/concepts/overview/components/

  • What is Cloud Native? Understand the Easy way !

    What is Cloud Native? Understand the Easy way !

    What is Cloud Native ?

    Answering this question is important as everyone talks about Cloud Native but very few are aware of all the attributes of Cloud Native applications and architecture.

    For example, many associate cloud native to the use of the containers only. which is not correct. As there are other attributes that also an important part of cloud native software architecture, so just the use of containers does not qualify an application to be cloud native.

    Then there is a common misconception that containers and microservices are one and the same thing. which is not true.

    Hence, this article aims to clarify all these concepts related to cloud native in a simple and easy manner.

    It is important to know these attributes as all the future IT and Telco applications that are supposed to run in cloud are being evolved to cloud native software architecture.

    When it comes to the Telco industry, it is a big paradigm shift. NFV was originally developed with VNF in mind which is one large piece of monolithic software on a virtual machine, whereby the latest trend is the transition to cloud native CNFs which are lightweight, agile, and containerized. Therefore it is important to know about cloud native in general.

    And who else is better to look for definition of cloud native than the CNCF body ( Cloud Native Computing Foundation).

    Here I have made the text bold which are the necessary components of cloud native ( as per CNCF) and moving forward we define them one by one.

    Cloud Native Definition according to CNCF

    “Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid   clouds.   Containers, service meshes, microservices,   immutable infrastructure, and declarative APIs exemplify this approach. These   techniques   enable   loosely coupled systems that   are   resilient, manageable, and observable. Combined with robust automation, they allow engineers  to  make  high-impact  changes frequently  and  predictably  with minimal toil“

    I made the important attributes are made bold here and converted them to seven major attributes for easy reference so that you know , what is cloud Native

    what is cloud native? cloud native attributes
    Fig: Cloud Native attributes

    What is Cloud Native? The Seven Attributes

    1. Containers

    Virtual Machines are good. But containers are better.

    How?

    VMs let you isolate applications from each other on the same server without the need to buy a server for each application. However this comes with one caveat- each VM uses a lot of system resources.

    This is because it makes a virtual copy of everything including the operating system. Think of it as running one Linux instance ( Operating system for VM) on another Linux instance ( host operating system).

    And when one starts adding VMs in cloud, the solution becomes expensive.

    On the other hand, multiple containers can share the same host operating system ( Linux kernel). This makes containers lightweight, portable and fast to start up. This makes them very stuitable to be deployed in cloud and hence the name cloud native.

    One famous and most popular container example is Docker.

    2. Microservices

    A microservice is a way to build applications as small pieces of software.

    Today’s applications are big monolithic pieces of software For example think of it as an EPC (Evolve packet core) made as one big monolithic application. It is difficult to upgrade the software of such an application considering the software pieces are tied together as one big piece and with so many moving parts, it is a complex task to evolve and upgrade the software of such application by the developers.

    On the other hand microservices work as small applications ( each called a microservice) that are loosely coupled. This creates a pluggable application architecture. each microservice communicate with each other through REST APIs.

    Advantages:

    Each microservice can evolve independently, has autonomous life cycle. There is no need to wait for quarterly releases to be deployed. upgrades can be rolled out quickly. Each microservice can scale on its own without waiting for the other services to scale. This is the true essence of being a cloud based application.

    Are microservices and containers one and the same thing ?

    Not exactly.

    You don’t need a container to run a microservice. Instead, you may run each microservice in a separate virtual machine. But would that be an efficient solution ?

    No !

    Each VM has assoicated overhead of an indpendent operating system. This makes it inefficient and very heavy to run many microservices in multiple VMs.

    On the other hand a container is much suitable to run a microservice i.e one microservice per container.

    That is the reason that when we say a microservice, we usually mean the containers and vice versa.

    3. Orchestration

    Docker create images and run containers.

    However when talk about hundred and thousands of containers, we need a good management tool.

    This is done with a special program called container orchestrator or simply an orchestration tool.

    No environment can be truly cloud native without an efficient orchestration tool. Of late, Kubernetes has become a def-facto standard for containers orchestration.

    Orchestration tools deploy, operate and scale hundreds and thousands of containers and thus responsible for life cycle management of containers.

    4. Continuous Integration/Continuous Delivery ( CI/CD)

    CI/CD ( also sometimes refered as Devops) is an essential part cloud native architecture.

    The whole concept of microservices is having software agility and CI/CD can achieve that objective efficiently.

    CI/CD is set of tools and practices that support accelerating software development cycles. CI/CD tools automate stages of the software release cycle. Small incremental changes are made to applications.

    Then there is a process of continuously integrating and testing these changes in small increments.

    As each microservice can be evolved and upgraded separately than other microservices, there is a less risk of rolling out upgrades to the network continuously. This is called continuous integration and continuous delivery of new code and hence brings software agility.

    5. Declarative APIs

    Microservices communicate through APIs. There are two kind of APIs

    • Imperative APIs
    • Declarative APIs

    Imperative APIs tell the system on the exact steps of how to perform an operation. Declerative APIs just leave an intent or wish on what it is expecting from the system and leaves it to the system on how to perform it.

    A good example would be if I tell someone to cut the grass in the garden and then tell him the exact steps, tools etc on how to cut the grass ( imperative API)

    VS

    I just tell him to cut the grass and leave it to him to follow his way ( Declarative API)

    The modern applications work with declarative APIs and that is the recommended approach in cloud native architecture. The advantage with the declarative APIs is that one microservice does not need to understand the details of the operation it wants from a second microservice. This makes the integration quick , easier and developer friendly.

    6.Immutable Infrastructure

    Mutable is defined as anything that’s capable of being changed. Traditionally servers are mutable, as they are continually updated, their configurations are tweaked.

    However here is a question, in a cloud like environment, do you really need mutable infrastructure, as this means there will be a challenge to keep the configurations updated and more importantly consistent across clusters.

    On the contrary, a better way is to just kill the server and bring up a new server when there is a need to upgrade the server. Which by the way, can be done faster these days. This gave birth to the concept of immutable infrastructure. This refers to servers or VMs which are never modified after deployment. Instead of updating the server, we just replace it with a new version. For any updates or modifications, you will build up a new server from a common image and then decommission the old server.

    The biggest benefit of immutable infrastructure is consistent and configuration across all environments ( dev, test, production). Deployments are simpler and predictable and testing the infrastructure is much easier. This greatly simplifies the operation and maintenance of infrastructure in the cloud environment.

    7.Service Mesh

    This is the last attribute of a cloud native environment.

    With hundreds of microservices deployed, there is an increase in service to service communication. Service meshes manage this complex web of service communication in a fast and reliable way.

    To understand the concept of service mesh, consider the following example

    service mesh
    a

    A user comes to buy something on an eCommerce website. He visits the catalog of products, adds a product to cart, proceeds to checkout. At that stage, he is given the option to upsell, which may take him back to the cart. There is a lot of communication between different services here.

    This was a simple example. In practice, there are a huge number of microservices. A better approach is to have a service mesh, which can manage service to service communication avoiding as service to talk to any other service directly.

    service mesh, cloud native

    Conclusion-What is Cloud Native?

    So that’s it, these were the seven attributes of cloud-native according to CNCF and hopefully, it should clarify “what is cloud Native”.

    Now let me know in the comments section, if you have any questions or think I missed something important that should be an attribute for cloud Native.

  • MEC in NFV : How does MEC fit in NFV architecture?

    MEC in NFV : How does MEC fit in NFV architecture?

    After understanding MEC architecture in my last blog, it is logical to to see the action of MEC in NFV architecture !

    However, here is a question, why you need a separate MEC architecture ? Why not re-use NFV architecture.

    When NFV can run itself any application, isn’t MEC one of the applications? I got quite a few questions on this, so I thought why not write a dedicated article on this one. This article will clearly position MEC vs NFV and conclude with some takeaways for you.

    If you are new to NFV and MEC architecture and haven’t read about my last article you can read them here. NFV architecture here and MEC architecture here.We discussed the MEC architecture in our last blog ( link above) . I have now labelled each component with a number code so you can recognize them once we move them to NFV.

    lets add to this to NFV Architecture which is below ( The famous ETSI Architecture)

    MEC in NFV

    Lets start moving the items from MEC to NFV.

    You probably have guessed it correct, a lot of MEC architecture components are just VNFs which can be easily moved to NFV as VNFs.

    MEC Components that become VNFs

    I have now elaborated it through a diagram in which I have shown which components from MEC can be mapped to NFV architecture as VNFs. I have shown all of them with red arrows. ( items 1,2,3,4,6)

    They are

    • All MEC Apps
    • MEC platform
    • “MEC Platform Element Management” and “MEC App Rules & Reqmts Management”
    • Other MEC Platforms
    • Data Plane of MEC Platform

    After moving these components as VNFs, it would logical to ask is there anything I can re-use from NFV so that I can remove from MEC architecture.

    Components that are not needed in MEC architecture as NFV already have them

    Well, MEC has a virtualization stack ( the Virtualization Infrastructure manager(VIM) and Virtualization infrastructure); So does NFV- VIM and NFVI Correct ?

    So why would you need a duplication here.

    So we can easily remove them from MEC as NFV can handle them. As shown in the diagram below item 3a and item 5 are mapped respectively to NFVI and VIM respectively.

    So far so good !

    With this mapping we can see now new components added to NFV with the codes so you can track.

    MEC in NFV
    MEC in NFV

    What about MEC VNFs life cycle management ?

    Remember! the VNFM role?

    The VNFM does the life cycle management of VNFs ( creation, deletion, maintenance)Now that MEC functions are converted into VNFs, we would naturally need corresponding VNFMs. This is done by two VNFMs as following.

    1. VNFM to manage life cycle of MEC Apps. ( item 4b)
    2. VNFM to mange life cycle of MEC Platfrom ( new item)

    Just to elarborate more. The item 4 above in MEC is decomposed in 4a and 4b as following.

    • MEC platform Element Management and MEC App rules & requirements management” becomes a VNF labeled 4a
    • “MEC App life cycle management” is mapped to VNFM as item 4b

    Lets move ahead !

    Multi Access Edge Orchetrator

    With all other items mapped correctly, we are left with one major component which is MEC Orchestrator.

    This component ( item 7) is mapped ” as-it-is” and re-named to Multi Access Edge Orchestrator. This is now a new component in NFV. Likewise items 8,9,10 are mapped “as-they-are” in NFV as new components.

    Conclusion: Does NFV cover everything MEC offers ?

    Perhaps Not.

    While MEC architecture can be completely mapped to NFV. What NFV cannot provide is the MEC orchestration part. Neither can NFV provide the CFS portal, Device App, Use App LCM proxy.

    Among them MEC orchestration is the most important component that is missing in NFV.

    If you look at the original diagram of MEC at the top. This sums up to the top layer which is “MEC System level” which is the missing part in NFV ( of course OSS stays the same). Also mapping MEC in NFV architecture results in some new reference points ( refer to the legend in above diagram), the new reference points are colored as maroun.

    So thats it from my side; hope this makes the situation more clear on how MEC fits inside NFV architecture.

    Now its turn to drop me a line, if you have some questions here !

    Reference: ETSI GS MEC 003 – V2.1.1 – Multi-access Edge Computing