Saturday, 10 October 2020

Economic Benefits of Virtualizing the CCAP Core with a Microservices Based Architecture

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Architecture

Service providers are going through a digitalization journey. And one aspect of that journey is the virtualization of their service delivery infrastructure. At Cisco, we are making that transition easier for our customers by creating a common virtualization platform across mobile 5G, cable vCCAP, and Telco vBNG. This helps operators reduce their cost to virtualize the infrastructure and enable them to rapidly tap into new revenue opportunities.

When it comes to virtualization for cable, we did not virtualize the legacy CCAP, we re-architected the platform from the ground up to come up with a microservices-based architecture. That is what became our Cloud-native Broadband Router(cnBR). Why? That was the only way to get to ours and our customers’ end goal which is a hybrid, Multi-cloud, and Multi-Access Edge Compute(MEC) based cable broadband platform. cnBR has four major types of microservices: Data Plane(DP), Control Plane(CP), Real-Time(RT), and Management Plane(MP) that we can deploy at any location in the network or the cloud. cnBR’s microservices-based architecture enables webscale operations such as auto-healing, autoscaling, load balancing, and fault-tolerance at the infrastructure layer.

Evolution

With cnBR’s microservices-based architecture, you can start with a simple on-prem appliance like architecture that is familiar to your operations and IT organization. And as you gain familiarity, you can evolve into a hybrid and multi-cloud world by moving some of the microservices to public cloud platforms. The move of some of the microservices to public cloud platforms such as GCP, Azure, and AWS will reduce operational burden, extend reach, and augment capacity. Figure 1 shows the phased deployment evolution of the cnBR architecture:

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 1: Evolution of cnBR Architecture

Phase 1: Centralized on-Prem and cloud-native appliance – In this phase, you will start with all the microservices running in the hub or Datacenter.

Phase 2: Multi-Access Edge Compute(MEC) – Here, you will slowly move some of the microservices closer to the edge in an Edge compute platform or a node that has a compute board to enable a MEC architecture. This will focus on shifting the data plane(DP) and real-time(RT) microservice to MEC platform.

Phase 3: Hybrid Cloud – This phase moves the management plane(MP) and control plane(CP) microservices to a private or public cloud and keeps data plane(DP) & Real-Time(RT) microservices at the edge

Phase 4: Multi-cloud – This phase provides flexibility in enabling the management and control plane microservices to run in any public cloud environments with minimal friction.

 Why Migrate to a Microservices based Architecture?

With microservices-based architecture, you can improve:

– Time to market: you can get features in weeks vs months, 

– Agility:  you enable hitless and maintenance windowless upgrades, 

– Scale: you gain seamless and on-demand auto-scaling which gives you unprecedented cluster level redundancy and scale,

– Cost: you can lower TCO with reduced footprint and facilities cost.

Why Cisco’s cnBR?

The virtualization of the access infrastructure is one way to add more capacity. To better understand how operators can virtualize and reap immediate business benefits with cnBR, we looked at CAPEX and standard operational costs like space, power & cooling while increasing the scale of the microservices-based architecture. We also did the same scaling and cost analysis of a legacy appliance-based CCAP solution so we can compare the savings. What we found is a compelling business value of going to a microservices-based architecture. These are additional benefits to the service/feature velocity and operational efficiency enabled by agile webscale operations of microservices-based architecure.

The analysis included scenarios where bandwidth per service group is increased from 1 Gbps to 5 Gbps in the downstream while the upstream is increased from 100 Mbps to 500 Mbps. The average Capex Savings was 29%, average OPEX savings were 42% and the average space(RU) savings were 73%. Figure 2 highlights the savings as the bandwidth scales up.

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 2 . Business benefits of cnBR as system bandwidth scales up

To help do your own analysis, we have created an easy to use vCCAP economics calculator. You can do your own analysis based on your current network configuration and long-range plan(LRP). Figure 3 highlights the type of summary output you can get from the vCCAP Economics Tool.

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 3. Summary of Capex, Opex comparison between cnBR and traditional CCAP

Friday, 9 October 2020

Resiliency and the Path to Automation 

Cisco Prep, Cisco Learning, Cisco Guides, Cisco Tutorial and Material, Cisco Prep

Look anywhere and you’ll find conversations about autonomous operations. Everyone is weighing in on how to balance the benefits from these new technologies with the perceived impact on society and our collective future, particularly in our Covid reality. What I can tell you – from an industrial IoT perspective – is that we are seeing autonomous operations having a very positive effect.

Across industries, we’re seeing autonomous operations deliver increased business resiliency, better jobs, improved working conditions, increased efficiency, and a higher quality of work/life balance across many industries.

◉ Autonomous trains: Since the first driverless trains in the late ‘90s, more and more passenger train lines are being built and converted to automated lines, delivering additional safety for passengers, operational flexibility and reduced operating costs. Driverless trains can increase throughput by increasing the frequency of trains on a metro line and at the same time, they deliver a track record for safety that human drivers are unable to match.

◉ Warehouses and distribution centers: Entirely autonomous loading systems are now taking and fulfilling orders from the supply chain. Forklifts and pickers fetch the product, deliver to the pallet, wrap for shipping, and transport to the shipping dock.

◉ O&G exploration: Once workers get a drill rig close to the target drill area, the rig can take over by itself – saving workers from a job that not only is dangerous but can take days. The autonomous drill can also quickly make on-the-fly changes, like adjusting the angle of the drill, to increase yield and efficiency.

◉ Auto manufacturing: Here manufacturers are weaving autonomous operations into their industrial automation efforts – like using RFID on to keep track of car bodies as they move across the production line and Automated Mobile Robots (AMRs) to safely move material across the factories.

◉ Amusement rides: Today the most advanced and desired rides in amusement parks are the so-called “dark rides”, where visitors hop on fully autonomous vehicles speeding up through a completely dark warehouse and where the experience is provided though immersive displays, VR googles, and incredible accelerations. The entire outdoor “amusement network” is connected by wireless access points on the vehicles and the infrastructure, all powered by rugged IoT switches and routers.

Cisco Prep, Cisco Learning, Cisco Guides, Cisco Tutorial and Material, Cisco Prep

Behind each level of automation is a communication and connectivity challenge across industries.  Autonomous operations require vast quantities of real-time video and data that legacy networks simply can’t handle – and often the operations are in harsh, remote, and dangerous locations. Trains are constantly in motion across remote geographies and inside tunnels, presenting unique connectivity challenges. All this automation translates into the need for high bandwidth, high security, and high reliability.

The Foundation for Autonomous Operations – A Secure and Reliable Network


The secret power behind autonomous operations?

It starts with Cisco’s secure and reliable network for IIoT that powers the entire system and connects everything – device to vehicle to data to Cloud – making sure your autonomous operations have the right data to make the right decision at the right time. Autonomous operations rely on that perishable data at the edge that is only valuable at that moment. After an incident, it does little value to know the vehicle should have turned.

Likewise, autonomous operations are only successful if the entire system is secure. If the network were to be hacked, perpetrators could take over the autonomous operations. Imagine the mining truck being rerouted to follow the wrong path causing an accident. You have to trust your network to trust your business to autonomous operations.

The recipe for your success?

We know that automation comes with challenges as we’re right there alongside our customers in their environments. No other company has the breadth of experience inside IT/communications and industrial settings across voice, data, and video to bring IT and operations together.

Every day we work with our customers to accelerate their success by:

◉ Bringing their IT/OT ecosystems together – so that IT can leverage all that they already know about Cisco networking and OT can get projects going quickly and securely

◉ Building a strong network of industrial partners who know the ins and outs of these industrial operations – and we’re just getting started

◉ Delivering more validated designs, like our new Distribution Automation – jointly validated with Schweitzer Engineering Laboratories – that highlights advantages from new innovations to the Cisco Resilient Mesh

Next up – Take a Deep Dive into Autonomous Mining

Over the next few blogs, I’m going to take you deeper into some automation use cases – first with mining and then with ports. While it may not be your exact industry, I’ll encourage you to keep reading as there are a lot of similar challenges across these operational settings.

Thursday, 8 October 2020

MDS 9000 Series Switch Architecture Part 1: Superior CRC Error Handling

In this blog series, we’ve discussed many unique advantages of the Cisco MDS 9000 series switches. We explored NVMe/FC support, proven investment protection, the superior security provided by anti-counterfeit technology, and the industry’s unique SAN Analytics solution. Now, let’s look at another important aspect: the Cisco MDS 9000 Series switch architecture and what makes it unique.

Switching Architectures Explained

As most of us know, there are two different types of switching architectures: Store-and-Forward and Cut-Through. In Store-and-Forward architecture, an interface receives the full-frame (header information + data + CRC + checksum, etc.) before putting it back on the wire for egress. While in Cut-Through architecture, the switch will only wait till it receives the destination WWN to put it on the wire, without waiting for other portions of the frame (data + CRC + other control parameters) to be delivered.

In both mechanisms, a CRC error check, also called Cyclic Redundancy Check, is applied. But the difference is in the next stage – action. What actions are taken when the CRC error is identified?

CRC Error Handling in Cut-Through Architecture: Identify, Report, Forward (Ugh!)

In Cut-through Technology, if a packet has a CRC error, it will increase the CRC error reporting counter and put the corrupt packet back on the wire, and move on. Thus, the switch can only report the error and put it back on the wire without taking any further action. The packet that arose with the CRC error will have to be sent again anyway from the source across the entire path. The result? Degraded performance—twice. The first is due to a bad packet, and the second is a result of resending the original bad packet.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep
Cut-Through technology: Corrupt packets reported and forwarded.

Ultimately, the destination server and storage Host Bus Adapter (HBA) works extra hard to detect and drop the bad packet. In the ethernet world, this may not be a major issue. But in the Fibre Channel network, we have finite pools of buffer credits. Every packet that has to be retransmitted will need buffer credits. This can create performance issues, buffer credit starvation, and spend vital CPU cycles of the switches across the network. The impact includes high TCAM usage, increased latency, and a multitude of additional issues. In other words, the whole network can be impacted and brought to a halt.

CRC Error Handling in Store-and-Forward Architecture: Identify, Report, Drop (Yay!)

In Store-and-Forward technology, if the switch interface finds any CRC errors, it will identify and drop the packet on the spot. Why? Because here, the switch receives the full-frame (header + data + CRC checksum information, etc.) before putting it on the wire for egress. It will also signal the source to resend the corrupt packet. This saves resources, including memory, CPU, bandwidth, and buffer credit across the network, plus the additional resource consumption on the server or storage devices. As a result, the performance impact is minimal.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep
Store-and-Forward technology: Corrupt packets reported and dropped.

We implemented Forward Error Correction (FEC) in MDS 32G FC as a standard requirement. It can do a similar job, but with some limitation. FEC can only correct up to 11 bits out of 2,112 bits of FC frame. This is useful but in extremely limited cases. Note that the smallest portion of the FC frame (start-of-frame OR end-of-frame) is 4 bytes or 32 bits. So, what if errors are more than 11 bits or about 0.6 percent? FEC will not be able to help. Therefore, CRC error checking and deploying the correct architecture is highly important.

Wednesday, 7 October 2020

Get Ready to Crack Cisco CCNP Enterprise 300-430 Certification Exam

 Cisco ENWLSI Exam Description:

The Implementing Cisco Enterprise Wireless Networks v1.0 (ENWLSI 300-430) exam is a 90-minute exam associated with the CCNP Enterprise and Cisco Certified Specialist - Enterprise Wireless Implementation certifications. This exam certifies a candidate's knowledge of wireless network implementation including FlexConnect, QoS, Multicast, advanced location services, security for client connectivity, monitoring and device hardening. The course, Implementing Cisco Enterprise Wireless Networks, helps candidates to prepare for this exam.

Cisco 300-430 Certification Exam Overview:

Exam Name: Implementing Cisco Enterprise Wireless Networks
Exam Number: 300-430 ENWLSI
Exam Price: $300 USD
Duration: 90 minutes
Number of Questions: 55-65
Passing Score: Variable (750-850 / 1000 Approx.)
Exam Registration: PEARSON VUE

Related Articles:

Tuesday, 6 October 2020

Using “WhatsOp” for Network Change Management

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

I often find myself passionately talking with my customers about programmability and how it unlocks hidden potential to do anything we can think of – even make a cup of coffee (if you purchase an API enabled coffee machine that is :-).

Some get it right away. Others can’t think of ideas for what they would like to do differently, and that reminds me of Henry Ford’s famous quote:

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

The WhatsOp use case


I understood I needed to provide a few examples of the potential use-cases in order to make it real. So, my quest began. At some point I stumbled upon Gabi Zapodeanu’s DevNet Create 2018 workshop – that was a perfect example of the use-case I was looking for.

WhatsOp is a very “visible” use-case in terms of user experience. It leverages several different programmability tools available on Cisco’s platform — Embedded Event Manager, Guestshell, Python, REST APIs, Webex Teams.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

How I demonstrate WhatsOp


Change management is a use-case my customer faces on a daily basis in their production networks. Many of them have a policy that defines what changes are allowed throughout the day and what changes should be done only during off-hours. For example, assigning an access port to a vlan does not require any approvals, while changes to the routing table do.

With WhatsOp, every change (or selected changes) will notify selected network administrators and ask for their approval. The network administrators will be able to approve the change, or roll-back the change – through their smartphone, thanks to Webex Teams.

Experience the potential of programmability


My intention in demonstrating WhatOp is to expose the potential of programmability. We could restrict the commands privileged users are allowed to enter using ISE as TACACS, we could leverage Prime Infrastructure to archive and compare configuration revisions. However, integrating the functionality together and making it accessible from any device (that can access Webex Teams) would be challenging. Getting the functionality to work even without connectivity to the central management systems would be very challenging.

Don’t take the WhatsOp use-case as-is. Think about modifying it to address a unique problem your organization might be facing right now – how cool would that be?

If you have an interesting use-case – let me know! I’m always looking for new challenges to solve. For now, let me encourage you to try WhatOp yourself to experience the potential of programmability. Check out these resources:

◉ Webex Teams SDK which makes life much easier and the code cleaner working with the Webex Teams API.

◉ pyATS, which is super powerful for manipulations, parsing, differences and verification of network devices. The only reason we’re NOT using pyATS for configuration differences, is because the program needs to run in Guestshell, and we wanted to make it as lean as possible.

◉ Check out the repo on GitHub.

◉ Watch my demonstration video


Breaking it down:


How did it work?

1. Detecting the change: every change we have on a Cisco device triggers a log message, such as:
Aug 16 2020 07:05:12.521 UTC: %SYS-5-CONFIG_I: Configured from console by obrigg on vty0 (10.56.56.143)

We use EEM (Embedded Event Manager) built-in IOS-XE/NX-OS to wait for this log entry and kick off the Python program.

!
event manager applet config_change
 event syslog pattern "SYS-5-CONFIG_I" maxrun 240
 action 0 cli command "enable"
 action 1 cli command "guestshell run python3 /bootflash/guest-

share/WhatsOp/config_change.py"
 action 2 cli command "exit"
 action 3 cli command "exit"
!

2. Running the Python program: We’re using Guestshell to run our program on the device itself. Guestshell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python for automated control and management of Cisco devices. This container shell provides a secure environment, decoupled from the host device, in which users can install scripts or software packages and run them.

3. What’s happening in Python:

a. The program starts with gathering information from the device: The user has performed the latest change and The running configuration (a copy is saved on bootflash:).

def save_config():
    # save running configuration, use local time to create new config file
name
    run = cli('show run')
    output = run[run.find('!'):len(run)]
    timestr = time.strftime('%Y%m%d-%H%M%S')
    filename = '/bootflash/guest-share/CONFIG_FILES/' + timestr + '_shrun'
    f = open(filename, 'w')
    f.write(output)
    f.close
    f = open('/bootflash/guest-share/CONFIG_FILES/current_config_name', 'w')
    f.write(filename)
    f.close
    return filename

syslog_input = cli('show logging | in %SYS-5-CONFIG_I')
syslog_lines = syslog_input.split('\n')
lines_no = len(syslog_lines)-2
user_info = syslog_lines[lines_no]
user = user_info.split()[user_info.split().index('by')+1]

old_cfg_fn = '/bootflash/guest-share/CONFIG_FILES/base-config' 
new_cfg_fn = save_config()

f = open(old_cfg_fn)
old_cfg = f.readlines()
f.close

f = open(new_cfg_fn)
new_cfg = f.readlines()
f.close

b. Then the program compares the running config, with the last approved configuration (saved on bootflash: as well).

def compare_configs(cfg1, cfg2):
    # compare two config files
    d = difflib.unified_diff(cfg1, cfg2)
    diffstr = ''
    for line in d:
        if line.find('Current configuration') == -1:
            if line.find('Last configuration change') == -1:
                if (line.find('+++') == -1) and (line.find('---') == -1):
                    if (line.find('-!') == -1) and (line.find('+!') == -1):
                        if line.startswith('+'):
                            diffstr = diffstr + '\n' + line
                        elif line.startswith('-'):
                            diffstr = diffstr + '\n' + line
    return diffstr

c. In case there are no changes (perhaps the user changed a setting and changed it back right after) – nothing will happen. However, if the program finds a difference between the running configuration and the last approved configuration – things will become more interesting.

d. The program will use the Cisco Webex Teams API to create a new space and add the preconfigured network administrators in that space. The program will alert the space about the changes that were made, and ask the admins for an approval or decline.

if diff != '':
    # find the device hostname using RESTCONF
    device_name = cli('show run | inc hostname ').split()[1]
    print('Hostname: ' + device_name)
    # Initialize Webex Teams API
    api = WebexTeamsAPI(access_token=WEBEX_TEAMS_ACCESS_TOKEN, proxies=PROXY)
    bot = api.people.me()
    # Create a new space
    room = api.rooms.create(WEBEX_TEAMS_ROOM)
    # Add members to the space
    for WEBEX_TEAMS_MEMBER in WEBEX_TEAMS_MEMBERS:
        api.memberships.create(room.id,personEmail=WEBEX_TEAMS_MEMBER)
    # Send initial message
    api.messages.create(roomId=room.id, markdown=f"Hello <@all>,  \n# Configuration change detected!**  \nDevice hostname: **{device_name}**, detected the following changes made by user: **{user}**.")
    api.messages.create(roomId=room.id, text=diff)
    api.messages.create(roomId=room.id, markdown=f"Do you approve these changes?  \nMention me using **@{bot.nickName}** and enter '**y**' or '**n**'.")
    counter = 6  # wait for approval = 10 seconds * counter, in this case 10 sec x 6 = 60 seconds
    last_message = ""
    # start approval process
    while (last_message != "Bye Bye") and (last_message != f"{bot.nickName} n") and (last_message != f"{bot.nickName} y"):
        time.sleep(10)
        messages = api.messages.list(room.id, mentionedPeople=bot.id)
        for message in messages:
            last_message = message.text
            break

e. If the changes are approved – the running config will be marked as the last approved configuration. If the changes are not approved (declined or timed out) – the program will perform a roll-back to the last approved configuration.

        if last_message == f'{bot.nickName} n':
            cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')
            approval_result = '- - -  \n<@all>,  \nConfiguration changes **not approved**, Configuration rollback to baseline'
            print('Configuration roll back completed')

        elif last_message == f'{bot.nickName} y':
            print('Configuration change approved')
            # save new baseline running configuration
            output = cli('show run')
            filename = '/bootflash/guest-share/CONFIG_FILES/base-config'
            f = open(filename, "w")
            f.write(output)
            f.close
            print('Saved new baseline configuration')
            approval_result = '- - -  \n<@all>,  \nConfiguration changes **approved**, Saved new baseline configuration'

        else:
            print("No valid response")
            counter = counter -1
            api.messages.create(roomId=room.id, markdown=f'- - -  \n<@all>, I did not receive a valid responce. **{str(counter)} attempts left**.  \nDo you approve these changes?  \nMention me using **@{bot.nickName}** and enter "**y**" or "**n**".')
            if counter == 0:
                last_message = "Bye Bye"
                cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')
                approval_result = '<@all>,  \nApproval request **timeout**, Configuration rollback to baseline'
                print('Configuration roll back completed')

    api.messages.create(roomId=room.id, markdown=approval_result)

f. Once it’s done, the Webex Teams space will be deleted in order to prevent flooding the admins with spaces.

    api.messages.create(roomId=room.id, markdown='This room will be deleted in 30 seconds')
    time.sleep(30)
    api.rooms.delete(room.id)

Saturday, 3 October 2020

Cisco’s Magic Glue Binds the Pieces of the OvRAN Puzzle

Open Virtualized Radio Access Network i.e. “O-vRAN” has been a buzzword in the industry for quite some time now. To date, many renowned mobile industry analysts and researchers have conducted surveys on O-vRAN and revealed about the strong momentum of Mobile Network Operators (MNO) towards Commercial Off the Shelf (COTS) hardware, Software Defined Networks (SDN), and Virtualization. More and more MNOs are adopting or planning to modernize their Radio Access Networks (RAN) with Open vRAN architecture.

Cisco Prep, Cisco Tutorial and Material, Cisco Certification, Cisco Exam Prep, Cisco Guides

The decision to choose O-vRAN path by MNOs is a no-brainer. An operator survey by Senza Fili in 2019 tells that the key drivers behind the Open vRAN adoption are a reduction in Total Cost of Ownership (TCO) due to the increased vendor competition and deployment flexibilities that open architecture offers. Also, by decomposing, disaggregating, and virtualizing RAN components, MNOs are transforming their networks to future proof 5G ready networks.

Cisco’s Journey in O-vRAN


Cisco Prep, Cisco Tutorial and Material, Cisco Certification, Cisco Exam Prep, Cisco Guides

Cisco’s Contribution to Open vRAN Standards


Cisco an early advocate of Open Virtualized RAN, had launched “Open vRAN Ecosystem” way back in February 2018 at MWC Barcelona. With this launch, Cisco started its Open vRAN journey with like-minded partners e.g. Altiostar, Mavenir, Phazr, Tech Mahindra to name a few. The focus was to create an ecosystem that is designed to accelerate the viability and adoption of Open vRAN solution. Since then Cisco is working on architecting and building solutions, demos and trials with MNOs and helping to define open interfaces and management.

Early 2018, xRAN Forum defined the use of IETF’s NETCONF / YANG standard for programmatically configuring and managing its lower layer split RAN architecture. Cisco took a lead role working with operators and ecosystem partners, in helping the xRAN Forum define the use of NETCONF/YANG by the 5G Radio Unit. This laid the foundation for cross-domain orchestration of the RAN with other domains that had already adopted NETCONF / YANG.

Cisco’s Value Proposition


Cisco has a significant role in the Open Virtualized RAN ecosystem in the areas of automation, virtualization, software integration, infrastructure and lead integrator of the solution components. Cisco becomes the technology glue to bring together these modules thereby arriving at an end to end solution.

Cisco’s Magic Glue Binds the Pieces of the OvRAN Puzzle

◉ Choice of virtualization & NFV

◉ Automation & Orchestration

◉ Systems integration

◉ Industry leading infrastructure

◉ Multiple choice of fronthaul, midhaul & backhaul solutions

◉ Most widely deployed mobile core solutions

Industry Trials, Demonstrations and Pilots


The UK government, in March 2018 funded testbed for the prestigious project “5G RuralFirst” to help the country take a leading position in 5G. The challenge was to provide secure and reliable mobile connectivity to the rural area and support rural communities and industries like agriculture, broadcasting, and utilities. Cisco led this project and supported with its 5G Core Network and Cloud service while Parallel Wireless was the part of the ecosystem with its multi-technology Open RAN solution.

In September 2018 MWC Americas at LA, Cisco demonstrated industry-first 5G SA data call using Phazr’s virtualized RAN and Cisco’s Cloud Native 5G Core. The solution also included MEC and Synamedia. (Earlier Cisco’s Service Provider Video Software Solution). In the same event, Cisco showcased a pre-certified, pre-integrated, ready to deploy end to end open vRAN system. Tech Mahindra, Altiostar and Cisco led this solution and proved that the open multivendor vRAN solutions were possible.

Recently in June 2020, Cisco and Telenor joined hands to strengthen the focus on areas like 5G, Open vRAN, and distributed Cloud to support critical infrastructure transitions for Telcos. The companies are continuing the exploration of new 5G architectures and have started an Open vRAN trial at Telenor headquarters in Norway to further investigate using a virtualized, open infrastructure to improve cost efficiency for service rollouts. A new round of financing of the joint venture, Working Group 2 (WG2) was also announced. WG2 offers a carrier-grade, cloud-native mobile core solution that enables rapid service innovation MNOs, MVNOs, and enterprises. Using open APIs and cross-network interoperability, WG2 radically transforms the ability of mobile operators to innovate quickly.

Real-World Deployments and Recognitions


While we had many demonstrations and trials of the Open vRAN solution at prominent events across the globe, the most rewarding for Cisco was the commercial deployment for Rakuten Japan in February 2019. The first-ever network that is fully virtualized from RAN to Core, leveraging mobile edge computing with end to end automation for both network and services. Cisco played a very critical role in this exciting journey alongside Rakuten and was well appreciated by the MNO emphasizing the crucial role of common and distributed telco cloud platform used to host many virtualized applications including Altiostar’s virtualized RAN applications vCU and vDU. End to end automation solution with Zero Touch Provisioning (ZTP) enabled instantiation of vRAN to fully operationalize a cell site in a matter of minutes with no manual intervention, helping Rakuen to scale the network in the future at a very faster rate.

In November 2018, Cisco was recognized for its 5G leadership by winning the Fierce Innovations Award for “NextGen Deployment Wireless” for its fully virtualized deployment and E2E automation with Rakuten. This was the 3rd industry award for Cisco 5G software-defined network in 2019. The first two given to Rakuten were the Light Reading Leading Lights awards for “Most Innovative Telco Cloud Strategy by an operator” and “Most Innovative Automation Strategy by an Operator.”

The Open vRAN wave is certainly building now. More and more MNOs are thinking about getting rid of legacy architectures and embrace Open vRAN.

Bharti Airtel, India’s leading MNO decided to take this path and in April this year announced its Open vRAN deployment with Cisco and Altiostar. Bharti became the first Indian Mobile Network Operator to deploy vRAN based 4G Network that is open that is seamlessly upgradeable to 5G.

Etisalat, one of the world’s leading telecom groups, announced the successful launch of Open vRAN early this year to become the first operator to adopt the technology in the Middle East. The success of this deployment was possible with the collaboration of Etisalat, Cisco, Altiostar and NEC.

Similarly, for one of its kind projects in the aviation industry, Gogo, a supplier of broadband connectivity products and services for Aviation, last year announced Cisco, Airspan, and First RF as its partners to supply elements for its air-to-ground (ATG) 5G network for use on business aviation aircraft and commercial regional jets operating within the United States and Canada.

Collaboration with WWT and Altiostar


World Wide Technology (WWT) is a technology solution provider that provides innovative technology and supply chain solutions to large public and private organizations. WWT, from their Advanced Technology Center brings integration and deployment capabilities for operators. Recently, in April 2020, World Wide Technology (WWT) announced a collaboration with Cisco and Altiostar to develop an Open vRAN blueprint and validation lab. WWT will be taking a lead role to integrate, validate, and deliver multi-vendor solutions Thus, Service Providers will be able to see the Open vRAN solution in operation, get their hands on it, and test features that they require helping faster validation and deployment.

Source: cisco.com

Thursday, 1 October 2020

Universal Release Criteria 2.0–A Disruptive Quality Management Framework

Quality cannot be an afterthought! It takes strategic planning for meticulous implementation. The more time we invest in proactive thinking, tooling, Shift Left approaches, quality governance, and a process-driven culture, the more money and time we can save across the life of the product. Cisco’s Universal Release Criteria (URC 2.0) represents one such disruptive quality management framework that has been developed and adopted. The following criteria will help define a comprehensive set of quality goals, metric standardization, and process governance across the full development lifecycle from product development requirements to releases. The IOS-XE product fully adopted, implemented, and proved the URC 2.0 development process very effective.

Having worked in the software industry for more than two decades, I have gained experience in all aspects of the software development life cycle, process, metrics, and measurement. As a programmer, I designed and developed complex systems. I led the software development strategy and process for CI/CD pipelines, modernized it, and automated it. Also, I led the quality journey for various types of software releases for businesses to grow to scale. Given my background, I feel qualified to share my thoughts on URC development processes that helped us transform traditional development processes to more modern, automated, and streamlined counterparts.

Limited vision in quality goals and unchecked negative behaviors directly impact product quality. Resistance to upgrade requests from customers, lack of scaled environments to test deployments, and delays in early adoption really plague projects. Short-sighted quality goals impact deployments in the following manner:

  • There is excessive focus on backlog issues with inadequate focus and management of incoming defects.
  • Critical defects are prioritized exclusively.
  • Inadequate or negligible attention is paid to proactive defect prevention.

URC 2.0 is the brainchild of cross-functional quality specialists with representatives from operations, development, testing, quality, and supply-chain organizations. The main objective of this process innovation is to “address defects found in a release” that “will have to be fixed in the same release” by bringing “no technical debt” forward. Initially, this simple rule placed tremendous pressure on teams, but within a couple of years, everyone willingly embraced this cultural shift!  The results of URC 2.0 can be summarized as follows:

  • Provides a failproof framework for release quality management.
  • Outlines comprehensive release quality criteria for product development.
  • Transforms the departmental culture within software and hardware teams.
  • Prevents defects and reduces escape conditions during the product development lifecycle.
  • Fosters trickle-down innovation, enhances development practices, and furthers tools automation.

Shift Left techniques enjoy the benefits that come from URC’s quality algorithm innovations and the processes such as the following:

  • Manages the incoming defect process using escape analytics and Raleigh’s curve.
  • Enhances the algorithm to help address incoming, backlog, and bug disposal trends.
  • Prioritizes age-based bug fixes to address high-risk defects.
  • Simplifies operational management of the bug backlog.
  • Reduces last-minute code churn.
  • Operationalizes escape reduction.
  • Targets addressing of security vulnerabilities at the right level.

The URC 2.0 Framework

The URC framework is based on four basic tenets of quality management:

  • Prevention
  • Identification
  • Evaluation
  • Removal

A set of metrics is identified for each tenet to measure and drive quality. The objective of each phase and corresponding metrics are described in the diagram below.

Cisco Exam Prep, Cisco Tutorial and Material, Cisco Learning, Cisco Prep, Cisco Guides
URC 2.0 Execution Framework and Metrics

To measure the effectiveness of activities in each framework, use a set of metrics to achieve very specific objectives per category. From an execution viewpoint, all URC 2.0 metrics can be grouped into categories: defects, bug evaluation, late code churn, security, testing, and parity. This grouping with associated goals are published and evangelized throughout the release cycles. Executives are briefed to ask the right questions to prevent the release of inferior code quality to customers. This discipline raises the bar for teams, encourages them to work hard to meet goals, and helps them proactively address challenges. In this way, teams are able to confidently stand behind the quality of their release offerings. Here are some categories to help address code improvement goals:

Cisco Exam Prep, Cisco Tutorial and Material, Cisco Learning, Cisco Prep, Cisco Guides
URC 2.0 Framework Strategies for Success

Important URC Framework Criteria


To enhance tracking clarity, the URC 2.0 framework provides the following critical and grouped elements.

  • Track Defects–Address incoming and legacy issues based on severity and resolve issues within the same
  • Use Metrics–Focus on execution quality and pass rate. Adhere to strict goals and periodically measure
  • Ensure Release Defect Parity–Ensure that all fixes from prior releases are incorporated into the current release.
  • Security Vulnerabilities–Address all known issues before general release availability.
  • Control Late Code Churn–Set aggressive mean time to repair goals for all internally and externally found
The URC framework defines some critical terms for all releases: URC window and URC backlog.
  • URC Window–The time between the “URC Freeze” date of the prior release and the “URC Freeze” date of the current release is considered the window of opportunity to make a difference.
  • URC Backlog–When implementing URC 2.0 for the first time, address defects that fall into these major categories:
    • All defects that are applicable to the current release, irrespective of where or when they were found.
    • All URC defect fixes that must be carried forward from the previous release to maintain functional parity amongst releases.
    • Pick a start date from the previous window to begin your URC window for the current release. This will help serve as a reference point to address critical defects.
  • URC Freeze–Select a date when you stop working on your URC backlog. Ideally, this date must be after the completion of feature test for the release. The frozen URC backlog must be addressed and brought down to zero within three weeks of the freeze. This date must coincide with the critical defect cut-off date for the release. No bug fixes, immaterial of their severity, should be added to the current release after this critical defect cut-off date.
  • Final Code Validation–Conduct final testing and release readiness checks before the release is shipped to

Proof of URC 2.0 Success


Witness the “defect mountain Shift Left”. It illustrates the success of adopting the URC 2.0 framework. It also clearly demonstrates Cisco’s emphasis on software quality before general release and serves as the best representation of all the hard work.

Cisco Exam Prep, Cisco Tutorial and Material, Cisco Learning, Cisco Prep, Cisco Guides
URC 2.0 Benefits IOS-XE (EM)

The unique and rewarding digitization and release quality journey makes a significant difference for our developers, customers, and to our business. It ensures our ability to deliver features and functionality with speed and at scale. With the combination of our DevSecOps digital transformation (captured in my blog, “How do you gauge software quality before deployment?”) and the URC 2.0 Framework, we will be able to elevate the quality of our software offerings! Customers will enjoy receiving software that is error-free and impactful right off the bat!