Making private 5G interconnect easy to configure, simple to operate, and widely adopted

1. Introduction

This is the follow up blog to an earlier post titled “scaling the adoption of private cellular networks” where the challenges of how to scale interconnect between private 3GPP networks are described. Compared to the current inter-network signaling that serves around 800 public cellular operators, there are forecasts of a 1000 fold increase in the number of private cellular networks. Critically, each private network may experience perhaps a thousandth of the signaling load of a conventional public carrier network.

The full potential of 5G will only be harnessed if the scalable deployment of private 5G solutions can be simplified. The 5G DRIVE (Diversified oRAN Integration & Vendor Evaluation) project led by Virgin Media O2 and part-funded by the UK Government’s Department for Culture Media and Sport (DCMS), Cisco and co-partners is targeted at defining the use of the new 5G Security Edge Protection Proxy (SEPP) roaming interface to connect public and private 5G networks. How best to integrate private 3GPP Non-Public Networks with established public cellular networks, affordably, securely and at scale is a problem that Cisco is invested in solving.

In this post we share details of a recent demonstration Cisco gave to UK DCMS and other 5G DRIVE partners. The demonstration highlights an approach that may facilitate the simplification of 5G roaming interconnect with private wireless networks.

2. Evolution of inter-carrier signaling

The first cellular networks were interconnected using the same SS7 based signaling used on the public switched telephone network. The 2G cellular standard defines enhancements to SS7 messages. These enhancements support concepts of mobility as well as the newly introduced short message service. The introduction of 4G/LTE saw the introduction of IP based Diameter signaling between carrier networks. However, the structure of the SS7-defined exchanges was preserved to facilitate the interworking with earlier systems. Importantly, these Diameter-based systems are responsible for transporting the inter-carrier roaming signaling and not the roaming data used by the end-users. This roaming data can either be tunneled back to the home network or routed locally by the visited access network.

Now, 5G sees the most significant change in how to carry signaling between networks since the inception of cellular. 5G defines a “service based architecture” (SBA) that avoids strict signaling hierarchies. Instead, SBA allows signaling consumers to communicate with different signaling producers. SBA defines the use of RESTful APIs transported using HTTP2 defined methods like GET, POST and PATCH. These APIs are more familiar to web developers compared to the telco-focused SS7 and Diameter.

As described in the earlier post, the GSM Association is responsible for the services and solutions that underpin public roaming systems. This enables subscribers to experience seamless roaming across the world. As expected, GSMA is currently enhancing these services and solutions to be able to interconnect 5G Systems and enable users to seamlessly roam onto 5G public cellular systems using SBA-defined interfaces.

Just like in earlier Gs, the roaming signaling defined in 5G architecture is bidirectional. HTTP2 Request messages originate from both the visited network and the home network. These are then responded to by the other party, as illustrated below. The signaling transits the IPX network which is a private IP backbone used between public cellular operators. The IPX is isolated from the public Internet with security rules defined to prevent unauthorized access to/from it.

The figure above illustrates that each operator is responsible for their own perimeter security including configuration of firewalls and border gateways. GSMA defines procedures for exchanging IP address information for all operator nodes that connect to the IPX in its permanent reference document (PRD) IR.21. Operators configure firewall rules using this information to ensure that only signaling connections originating from registered IP addresses are permitted. The figure below illustrates how this firewall configuration is essential for the visited access network to permit inbound signaling flows from the home network.

3. Securing 5G roaming signaling

The 5G System introduces the Security Edge Protection Proxy (SEPP). The SEPP sits at the perimeter of the 5G public cellular network and is the focus of the 5G DRIVE project.

The N32 interface is defined by 3GPP for use between two SEPPs to ensure the HTTP2 messages can be securely exchanged. First, N32 control signaling is exchanged to establish N32 forwarding. The N32 forwarding operates by taking the HTTP2 Request or Response messages that need to be exchanged between operators and encoding the HTTP2 header frames and data frames in JSON. This JSON is transported in another set of HTTP2 messages which are exchanged between the two SEPPS. 3GPP defines two options for securing signaling between SEPPs. Either TLS protects the communication of these HTTP2 messages using the transport layer, or JSON Web Encryption (JWE) protects the communication at the application layer.

4. Private network challenges

Unlike GSMA, which defines the operation of roaming signaling and the IP backbone between public cellular operators, there is no equivalent system between private 5G networks. This is one of the reasons why 3GPP has defined two separate approaches to deploying private networks, a standalone approach that simply interconnects credential holders with access networks and a public network integrated approach that integrates the private network with the systems of a public cellular operator.

Interestingly, credential holders and private Wi-Fi access networks are increasingly using OpenRoaming (www.openroaming.org) to interconnect. OpenRoaming is a federation of identity providers and access providers targeted at lowering the barriers to adoption of roaming between Wi-Fi credential holders and Wi-Fi hotspot providers. Cisco was responsible for incubating the OpenRoaming system before transferring the operation of the federation to the Wireless Broadband Alliance (www.wballiance.com).

Prior to OpenRoaming, using Wi-Fi while on the go was a hassle. Most of the time, the Wi-Fi operator requires users to accept specific end-user terms and conditions using an intrusive browser pop-up. There were some deployments that delivered a more seamless experience using SIM-based authentication by interconnecting with mobile operators, but the access network configuration was complicated and agreements time consuming. The private enterprise’s InfoSec policies typically prohibit inbound sockets from unknown hosts on the Internet. This means each inbound roaming relationship requires a specific firewall configuration to permit signaling to transition across the enterprise’s perimeter. Without such configuration, the inbound signaling originated by the credential holder will be dropped by the firewall, as illustrated below.

Instead of sharing IP addresses, the OpenRoaming federation makes extensive use of DNS to enable the visited access providers to dynamically discover signaling systems operated by different credential holders. WBA’s Public Key Infrastructure (PKI) issues certificates to OpenRoaming providers. The roaming signaling endpoints authenticate and authorize each other using these certificates. The visited access network establishes a single TLS-secured outbound socket towards the credential holder. All signaling between the providers uses this single socket.

OpenRoaming’s use of DNS and a single secure outbound socket means that the enterprise can configure a single firewall rule for all OpenRoaming signaling originating from their own systems. This significantly simplifies and streamlines the procedures required to enable roaming onto the enterprise’s wireless network.

5. Scaling signaling on the internet

As part of our 5G DRIVE participation, Cisco revisited how “server-initiated signaling” is supported on today’s Internet. The aim was to understand whether future roaming systems can be enhanced with similar capabilities.

The challenge of how to support server push based signaling is well understood. The Internet has seen the deployment of a number of different solutions. 5G signaling is based on HTTP2 and this includes a capability termed Server Sent Events (SSE). SSE is used to send web server initiated events to the client over an already established socket. SSE is designed to reduce the number of client requests and deliver faster web page load times. However, SSE is unsuitable for supporting the reverse direction 5G roaming signaling as this necessitates full bidirectional signaling.

Prior to HTTP2 SSE, other solutions for server initiated signaling focused on polling-based solutions. With short polling, the client continuously sends HTTP requests to enable any server-initiated signaling to be returned to the client. As a consequence, short polling solutions place a significant load on the server which limits their scalability. To reduce this impact, alternative long-polling solutions have been developed. Using long polling, the client opens an HTTP request which then remains open until a server initiated message needs to be returned. As soon as the client receives the server initiated message in the HTTP response, it immediately opens another HTTP request. As with HTTP2 SSE, polling solutions are useful for sending individual events back to the client but are poorly suited when the server sent information is expected to be responded to by the client.

Some perceive the use of polling solutions by web applications as an abuse of the HTTP protocol. Consequently, the WebSockets protocol was specified to enable full two-way communications between clients and servers. The WebSocket connection starts off as an HTTP connection. The client includes an HTTP Upgrade header in the request to change the protocol from HTTP to WebSocket. The HTTP request header also includes a subprotocol field. This is used to indicate the upper layer application intended to be exchanged using the WebSocket.

6. Adapting N32 transport for adoption by private networks

As described above, the existing HTTP2-based SEPP solution takes the HTTP2 Request and Response messages that need to be exchanged between operators and encodes the HTTP2 header frames and data frames in JSON. This approach is adapted to enable a WebSocket-based SEPP to transport the same JSON encoded information. Because WebSocket transport is designed to support bi-directional communications, a single WebSocket is used to transport signaling generated from the visited network and that generated from the home network.

The 3GPP-defined N32 interface between SEPPs is split into a setup phase using control signaling and a forwarding phase. However, the current HTTP2-based system assumes fully decoupled signaling between those exchanges when the SEPP-initiator is in the visited access network and those when the SEPP-initiator is in the home network. This means that bidirectional forwarding requires separate N32 control exchanges. The HTTP2-SEPP uses a HTTP2 POST to a specific “/exchange-capability” path as part of the N32 control exchange.

In contrast, WebSockets enable bi-directional communications over a single socket. This means the visited access network is able to trigger the establishment of bidirectional forwarding. The WebSocket-SEPP signals a specific sub-protocol indicating that N32 service is being requested. In the demonstration, “n32proxy.openroaming.org” was used as an example sub-protocol. Following setup of the WebSocket, the WebSocket SEPP in the visited network sends a JSON object over the WebSocket requesting to establish the N32 forwarding service. The information exchanged in this setup message closely matches that defined in 3GPP N32c messages, including identities, public land mobile network (PLMN) information and security parameters.

After forwarding is established, the conventional HTTP2 SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are then transported using HTTP2. The WebSocket SEPP maps the headers and data fields from received HTTP requests and responses into JSON objects that are transported using the WebSocket message syntax.

The WebSocket solution enables private networks to configure simplified firewall rules. All outbound and inbound signaling exchanges between the private 5G access network and the remote credential holder are transported on a single socket. The credential holder’s WebSocket SEPP rewrites the authority of any callBackUris it receives from the visited access network using a SEPP fully qualified domain name (FQDN) suffix. For example, a 5G Access Management Function (AMF) located in a visited network may signal a deregistration callback URI to the home network of:

http://24.208.229.196:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

The WebSocket SEPP located in the home network rewrites the URI to a value that will always resolve to the IP address of the SEPP in the home network, e.g.,

http://24.208.229.196.sepp.operator.com:7777/namf-callback/v1/imsi-234600000055531/dereg-notify

This means that any HTTP requests originating in the credential holder’s network will use the rewritten URI in their HTTP2 Request messages. This ensures that all messages will be routed via the SEPP and the bidirectional N32 forwarding service towards the visited access network.

7. Demonstration of 3GPP roaming interfaces transported over WebSocket

Cisco has built a proof of concept based on the WebSocket approach described above and demonstrated the system to UK DCMS and other 5G DRIVE partners. We adopted a similar approach to how OpenRoaming enables scale by using a cloud federation as the authority to connect access network providers with identity providers. Private 5G systems can then benefit from the same simplification and streamlining of procedures that have accelerated interconnection between private Wi-Fi networks and different credential holders.

A fictitious cellular carrier is assumed to have joined a roaming federation, has been issued a certificate by the federation to use in securing signaling with other federation members and has configured their DNS records to enable their signaling systems to be discoverable from the public Internet. In the demonstration, the signaling systems of this fictitious cellular network are hosted by a cloud provider. A SIM card was provisioned in the 5G User Data Repository (UDR) of the fictitious cellular carrier, identified with a corresponding Mobile Country Code of 234 and a Mobile Network Code of 60. The demonstration focuses on the use case of a subscriber from the fictitious cellular carrier roaming onto the private 5G network operated by “Acme-Industrial” who has similarly joined the roaming federation. Acme-Industrial has configured its local private 5G network to support N32 signaling over WebSockets and operates a firewall that only permits outbound sockets to the Internet.

A UE with the SIM card attempts to register on the local private 5G network. There are a number of ways that the registration can be triggered. In one approach, the federation specifies the use of a Group Identity for Network Selection (GIN) that is broadcast from the private network. As part of the registration, the UE provides its identity to the network. The private 5G network performs a dynamic discovery to identify the home network using the 5G UE identifier.

The private 5G network contacts the UE’s home network through an API-Gateway, establishing a websocket connection.  Then, to keep things efficient and simple, we automated the implementation of logic for the WebSocket-based N32 forwarding using the cloud provider’s function-as-a-service. Finally, the 5G Core Services for the Authentication Server Function (AUSF), Unified Data Management (UDM) and User Data Repository (UDR) are hosted on cloud service’s compute platform.

The proof of concept demonstrates signaling associated with a typical roaming scenario. The different phases are described together with signaling logs from the demo.

◉ A private 5G access network is setup and awaits inbound roamers.

◉ The firewall rules in the private 5G network permit outbound signaling originating from the WebSocket-based SEPP function.

◉ An inbound roaming UE attempts to register with the private network.

◉ The private network recovers the home PLMN from the UE identifier and uses DNS to discover the WebSocket signaling peer.

2022.09.06 18:32:48: [INFO] Waiting for SUPI or SUCI from in-bound roaming UE 

2022.09.06 18:33:41: [INFO] In-bound SUPIorSUCI detected: suci-0-234-60-0000-0-0-0000055531

◉ The WebSocket SEPP establishes a bi-directional N32forwarding service for the home PLMN.

2022.09.06 18:33:41: >>>> {"n32Service": "subscribeRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US", "plmnIdList": ["23460"], "3GppSbiTargetRootApiRootSupported": "False", "jwsCipherSuiteList": ["ES256", "none"]} 

2022.09.06 18:33:41: <<<< {"n32Service": "subscribeAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB", "3GppSbiTargetRootApiRootSupported": "False", "plmnIdList": ["23460"], "jwsCipherSuite": "none"} 

2022.09.06 18:33:41: [INFO] WebSocket forwarding established and serving suci-0-234-60-0000-0-0-0000055531

◉ The UE registers onto the private network using standard 5G service-based architecture and signalling. The WebSocket transports bi-directional signalling exchanges between the private access network and the home network.

2022.09.06 18:33:43: >>>> {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/nausf-auth/v1/ue-authentications", ":scheme": "http", ":authority": "172.31.14.141:7777"}, "headers": {"accept": "application/3gppHal+json:application/problem+json", "content-type": "application/json"}, "payload": {"supiOrSuci": "suci-0-234-60-0000-0-0-0000055531", "servingNetworkName": "5G:mnc060.mcc234.3gppnetwork.org"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 

2022.09.06 18:33:43: <<<< {"n32Service": "http2Message", "messageId": "2785087321A", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "201"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:33:43 GMT", "content-length": "318", "location": "http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1", "content-type": "application/3gppHal+json"}, "payload": "{\n\t\"authType\":\t\"5G_AKA\",\n\t\"5gAuthData\":\t{\n\t\t\"rand\":\t\"50d05393a459af7786bb96b38f4ebf12\",\n\t\t\"hxresStar\":\t\"4d332c90989aa127a9c86a96a8978379\",\n\t\t\"autn\":\t\"7ee4c1f4ee8f8000c459a0a203065874\"\n\t},\n\t\"_links\":\t{\n\t\t\"5g-aka\":\t{\n\t\t\t\"href\":\t\"http://172.31.14.141:7777/nausf-auth/v1/ue-authentications/1/5g-aka-confirmation\"\n\t\t}\n\t}\n}"}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

◉ The UE uses the resources of the private 5G network.

◉ The home network triggers a de-registration of the UE. This will typically be due to the UE registering on another network, which could be when it returns to coverage of its home network or registers on another federated private 5G network. As we didn’t have a second access network in the demonstration, we triggered a deregistration by withdrawing the subscription of the UE in the UDR. The WebSocket SEPP in the home network translates the network initiated HTTP2 Request to de-register the UE into JSON. The JSON is transported to the private network using the already established WebSocket.

2022.09.06 18:37:53: <<<< {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedReq": {"requestLine": {":method": "POST", ":path": "/namf-callback/v1/imsi-234600000055531/dereg-notify", ":scheme": "http"}, "headers": {"content-type": "application/json","accept": "application/json,application/problem+json", "host": "192.168.128.145:7777"}, "payload": {"deregReason": "SUBSCRIPTION_WITHDRAWN", "accessType": "3GPP_ACCESS"}}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}}

◉ The WebSocket SEPP in the private 5G network recovers the JSON and re-creates the HTTP2 Request to de-registers the UE. The HTTP2 message is forwarded on to the private 5G Network’s Access and Mobility Management Function (AMF) which processes the message and deregisters the UE. The AMF then signals back to the UDR that the UE has been successfully deregistered.

2022.09.06 18:37:53: >>>> {"n32Service": "http2Message", "messageId": "4043366907D", "n32MessageSigned": {"payload": {"reformattedRsp": {"statusLine": {":status": "204"}, "headers": {"server": "Open5GS v2.4.9", "date": "Tue, 06 Sep 2022 17:37:53 GMT"}, "payload": ""}}, "protected": "eyJhbGciOiJub25lIiwiYjY0IjpmYWxzZSzigJxjcml0IjpbImI2NCJdfQ==", "signature": ""}} 

2022.09.06 18:37:53: [INFO] suci-0-234-60-0000-0-0-0000055531 successfully deregistered

◉ The home PLMN no longer serves any UEs in the visited network. The private network automatically triggers the deactivation of the WebSocket-based N32forwarding service towards the home PLMN.

2022.09.06 18:37:53: [INFO] terminating WebSocket forwarding for mnc60.mcc234 

2022.09.06 18:37:53: >>>> {"n32Service": "terminateRequest", "accessProvider": "ACME-INDUSTRIAL.CISCO:US"} 

2022.09.06 18:37:53: <<<< {"n32Service": "terminateAccept", "identityProvider": "MNC60MCC234.3GPPBROKER.GB"}

8. Reducing complexity and increasing scale

Cisco is investing in taking the complexity out of private 5G with its 5G-as-a-service offer. With WBA already reporting that over 1 million private wireless hotspots have embraced OpenRoaming, it is clear that simplifying roaming systems can lead to the transformation of roaming, from serving 100s of public cellular operators towards supporting millions of private 5G networks. Importantly, the WBA Board has committed to expanding the use of OpenRoaming to address alternative wireless technologies used in private networks. As part of this expansion, WBA has exchanged liaison statements with 3GPP regarding facilitating the adoption of roaming onto 3GPP Non Public Networks.

Re-using the newly introduced SEPP functionality to enable new deployments of roaming between public and private networks is a focus of the 5G Drive project. The proof of concept demonstrated by Cisco points to how established public cellular roaming interfaces can be adapted to facilitate adoption between private 5G networks and credential holders.

Cisco looks forward to working with others in WBA and 3GPP to help specify new capabilities that ensure that roaming between private and public cellular networks becomes as easy to configure, as simple to operate, and as widely adopted as traditional Wi-Fi-based OpenRoaming.

Source: cisco.com

Continue reading

Delivering Energy Savings and Sustainability with Cisco and HCL

Deploying sustainable manufacturing practices is tremendously important to most manufacturers in response to a variety of drivers, including stakeholder demands, regulatory mandates, climate concerns, and cost reduction. To make progress, action must take place on the factory floor to address concerns like these:

◉ Is a piece of heavy equipment running inefficiently because it has been run past its recommended hours and needs servicing?

◉ Has a piece of equipment been left running while unattended or not in use?

◉ What is the energy consumption across various industrial control systems, HVAC, and lighting on the plant floor?

Identifying potential areas of energy waste on the factory floor in a timely manner requires access to the underlying data, data analytics that derive insights from that data, and a dashboard that provides a single view of notifications and status on KPIs. After all, as the saying goes, “You can’t manage what you can’t measure.”

In response, Cisco — a leader in industrial, IOT networking — and HCLTech (HCL) — a leader in energy management solutions — have joined forces to develop an end-to-end digital sustainability solution leveraging existing products, including HCL’s Net-Zero Intelligent Operations platform (NIO), Cisco IOT gateways powered by the Cisco IOx application hosting environment, and IOx-enabled Cisco network devices. That solution won the 2022 Cisco Global Digital Sustainability Award.

HCL Net Zero Intelligent Operations (NIO) Platform

NIO is a Greenhouse Gas (GHG) emission management solution that helps companies become more sustainable and cost and energy efficient to reduce their carbon emissions and contribute to their net zero goals. NIO presents real-time energy consumption insights and analytics using baselined parameters from all critical energy consumption points originating, for example, in workspaces and on factory floors. This includes calculating, reporting, and identifying emission optimization potential for devices drawing power in a factory or building.

Of course, to provide these insights requires real time access to data from various sources. NIO is a vendor agnostic platform that tightly integrates with the edge data management layer through APIs.

Figure 1: Data Management Layer

Data management layer with the HCL ZIP application and Cisco IoT gateways

As shown in Figure 1, the edge data management portion of the Cisco and HCL solution includes the HCL ZIP application hosting environment–running on Cisco IOT gateways that run the Cisco IOx application hosting environment–which communicates with the NIO platform running either in the cloud or on-premises servers.

The HCL ZIP application collects data from different power meters and directly from energy consuming devices like robots and various Computer Numerical Control (CNC) machines such as lathes, routers, grinders and laser cutters or PLC’s. That data is pushed to the NIO platform, which applies analytics and provides insight to the business to help it achieve its sustainability goals.

The HCL ZIP application gains access to this data by running in the Cisco IOx application environment, which combines Cisco IOS and the Linux OS for highly secure networking. IoT applications such as HCL ZIP gain secure connectivity and reliable integration with third-party devices and sensors. In turn, the IOx application environment runs on Cisco all-in-one IoT gateways that provide simple, essential connectivity to various third-party edge devices.

The IoT Gateways are managed centrally through a simple, easy-to-use cloud management tool–the Cisco IoT Operations Dashboard. Using this dashboard, customers can remotely deploy, monitor, and troubleshoot the gateways and applications running on them. The dashboard provides customer insights into network usage and carries out updates remotely without sending anyone onsite. For example, customers can receive automatic alerts when a device on the network goes down so that immediate action can be taken. All of this is done remotely and at scale.

Example use cases

Condition-based maintenance

Many factories have energy meters installed but no power budget management or real time view of how the machines and robots are consuming power. As a simple example, feed motor load can be identified from current monitoring, which can tell if a machine is malfunctioning in either of the following ways:

◉ Consuming power but not producing product (underloading)

◉ Consuming more power than required (overloading)

This information can help inform sustainability goals around energy wasting and carbon emissions.

Improved operational efficiency

In another example, a manufacturer can compare energy consumption across multiple assembly lines or machine usage over a period of time. This practice can help identify optimal working conditions by regulating environmental conditions in systems like HVAC, air ventilators, furnaces, and chillers. This use case can improve plant operational efficiency and save on energy and carbon emission, once again helping a business inform and meet its sustainability goals.

Source: cisco.com

Continue reading

EVPN Myth Buster Series – To lead or follow, where does Cisco stand?

Innovation is one of many characteristics defining industry leadership. Becoming an industry leader requires a company to innovate and find new ways to solve customer problems. Industry leadership is not something that can be created overnight. It takes more than a software release or a list of supported features to cement yourself as a technology thought leader in the networking industry. Over the past several decades, Cisco has demonstrated its leadership in networking by leading technology innovations that meet and exceed customers’ needs and then enabling the adoption of these technologies across organizations driving standardization. This has also led to robust collaborations and interoperability among different vendors for the benefit of the industry as a whole – please refer to Figure 1 Number of RFCs authors per affiliation for the top 30 companies at IETF over the past three decades.

Some examples of such technologies are L3VPN, MPLS, and EVPN. Cisco innovators such as Eric Rosen, Yakov Rekhter, and George Swallow incubated MPLS and L3VPN technologies and then led the standardization effort at the IETF. Furthermore, Cisco innovator, Ali Sajassi incubated EVPN technology and then led the standardization effort at the IETF. A well-adopted standard is like a team sport, and it requires not only participation but also contributions from every member of the team – i.e., from every vendor and provider involved.

Figure 1. Number of RFC authors per affiliation for the top 30 companies at IETF over the past three decades

In the past decade, Cisco has introduced EVPN technology to the networking industry at large and has led the standardization efforts for all the initial RFCs for this technology with the help of several vendors and service providers. Although there are vendors who are true partners and contributors to this technology and its standardization, there are “others” who are neither participants nor contributors but just users of it. One can easily find out who is who by looking at the IETF statistics for EVPN.

These “other” vendors have made claims to be pioneers of cloud networking fabrics driving a standards-based approach, even though they are openly adopting and implementing Cisco-authored RFCs and drafts into their software. These “other” vendors attempt to create the perception of open standards as their core pillar. Cisco has been a long-time innovator with a proven track record of developing IETF drafts to facilitate the implementation of new technologies that are widely adopted by these other vendors (“others”) in the networking industry. Being an industry leader requires Cisco to continue evolving and driving standards to make networks work better – please refer to Figure 2. Chart showing the number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation:

Figure 2. Number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation

IETF

For most of us, it is widely known the IETF is the premier Internet standards organization. Citing the IETF Standards page:

“Improving existing standards and creating, implementing, and deploying new standards is an ongoing effort. The IETF’s mission is to produce high-quality, relevant technical documents that describe these voluntary standards. IETF working groups are the primary mechanism for the development of IETF specifications and guidelines.”

As EVPN-VXLAN becomes the de facto standard for IP fabrics, Cisco continues to enhance and publish IETF drafts based on the protocols and architectures addressing new requirements and use cases. When Cisco develops the standards and drafts, there is an implementation in mind for the system and its parts, while “others” will choose to follow and implement the RFCs and the drafts without a full understanding of the use cases.

These other vendors will create and leverage feature matrices to fill their gaps and respond to RFPs, citing our documents and acting as if they would know better. Cisco can confidently claim to lead while “others” only follow, while Cisco invents and “others” only adopt.

Figure 3. VXLAN EVPN Industry Contribution

Cisco continues to extend its leadership in promoting open standards, interoperability, and multi-vendor solutions for Cloud Networking technologies.

This series of blogs aimed to provide a deeper understanding of EVPN VXLAN and additions to the IETF drafts implemented for today’s customer deployments.

History of Ethernet VPN (EVPN)

For many years, the need for extending Layer-2 efficiently was a burdensome task. Before the availability of Layer-2 VPNs, sorts of LANE (LAN Emulation) were used to transport Ethernet across distances, or we just plugged two Ethernet domains together via CWDM or DWDM. All these approaches had their pros and cons, but some common challenges remained, the virtualization of the Layer-2 service across a common infrastructure. When MPLS-based Layer-2 VPN rose to prominence, the presence of true Layer-2 VPNs became available, and with this the better use of the underlying transport infrastructure. With VPLS (Virtual Private LAN Service) multipoint-to-multipoint Layer-2 VPNs became affordable and addressed many new use cases. Even though VPLS brought many advantages, the pseudo-wire maintenance, transport dependency, and lack of comprehensive embedded access node redundancy still made it challenging to deploy. While all of this was the truth over a decade ago, around 2012 we embarked on a new chapter of Layer-2 VPNs with the advent of Ethernet VPN in short EVPN. In its essence, EVPN addressed the challenges the more traditional L2VPNs incurred and innovated new schemes in layer-2 address learning to become one of the most successful VPN technologies.

The journey of EVPN as a standard started back in 2010 when Ali Sajassi introduced and presented the very first draft of EVPN (initially called Routed VPLS, draft-sajassi-l2vpn-rvpls-bgp-00.txt, to IETF (Internet Engineering Task Force) in March of 2010. This draft was later merged with another draft by Rahul Aggarwal (from Juniper), draft-raggarwa-mac-vpn-00.txt, because of their synergy, and a new draft was born in October 2010 –  draft-raggarwa-sajassi-l2vpn-evpn-00.txt. This draft became a working group document in February 2012 and became a standard RFC 7432 in February 2015. This is the defacto base RFC for the basic EVPN behavior and its modes and subsequent EVPN RFC builds on top of the groundwork of this RFC.

Around the same time as the main EVPN draft introduction, Cisco introduced other EVPN related drafts such as draft-sajassi-raggarwa-l2vpn-evpn-req-00.txt and draft-sajassi-l2vpn-pbb-evpn-00.txt in October 2010 and March 2011 respectively which became standard in February 2014 and September 2015 respectively.

After the publications of initial EVPN drafts that later became RFCs 7432, 7209, and 7623, in 2013, Cisco published another set of EVPN drafts for Virtualization/VxLAN and for inter-subnet forwarding (L2 and L3 forwarding) that gave EVPN its versatility as it stands today. These drafts later became the standard RFCs 8365 and 9135.

Figure 4. IETF EVPN Timeline

With the based EVPN using MPLS encapsulation celebrated its success in the Service Provider market, for the Data Center an IP-based encapsulation was more suitable. With this, in 2013 the EVPN draft for “overlays” (draft-sd-l2vpn-evpn-overlay) was published, which included the encapsulation of VXLAN and became RFC 8365 in 2018. In order to address the various use cases for the Data Center, a couple of related drafts were filed around the same time. The definition of how to do inter-subnet routing (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding), how we advertise a IP Prefix route in EVPN (draft-rabadan-l2vpn-evpn-prefix-advertisement) or how to interconnect multiple EVPN “overlay” domains with a Data Center Interconnect (draft-rabadan-l2vpn-dci-evpn-overlay). All these drafts from 2013 now being RFCs and define the standard in how EVPN is being used within and between Data Centers.

Figure 5. EVPN RFC for VXLAN and DCI

The realms of standards are often a cabala. Opening this up and sharing some of the histories with the most significant milestones is as important as defining the standards themselves. For more than a decade, Cisco has actively driven the standardization of EVPN and shared this innovation with the networking industry. With over 50 publications to the IETF, Cisco leads the EVPN standardization and is proud of the collaboration with its partnering authors. With the proliferation of EVPN across all of Cisco’s Operating Systems (IOS-XE, IOS-XR, NX-OS) being fully interoperable, the flexibility of the right operational model across deployments in Campus, WAN, Data Center, or Service Provider domains is unmatched.

Source: cisco.com

Continue reading

Simplify the Adoption of Sustainable Technologies in the Workplace with Cisco DNA Center

Supporting sustainable technologies on a campus network is great for the planet and can substantially lower the cost of workplace operations. But adding hundreds of new IoT devices to a campus network can be a heavy lift for IT teams. Let’s take a look at the many innovations that Cisco has made to address sustainable technology, so that supporting a cleaner planet does not become a burden on IT teams.

For organizations, environmental sustainability is the practice of operating without producing a negative impact on the environment. Certainly, you’ve been hearing a lot about environmental sustainability and how IT can help to reduce your organization’s carbon footprint. When it comes to reducing the environmental impact of offices, factories, and warehouses, IT has a very big role to play. Gartner estimates that “By 2025, 75% of CIOs will be responsible for sustainable technology outcomes and 25% of CIOs will have compensation linked to their sustainable technology impact.” (Gartner Top Strategic Technology Trends for 2023: Sustainable Technology, ID G00774132)

Most IT departments will begin their sustainability work by verifying that IT technologies are being sourced from companies with “Net Zero” policies and programs. Cisco has documented all the steps we’ve taken to create a more sustainable solution for your network. Your next step will be to lower your environmental footprint by deploying new sensor technologies within your campus networks for initiatives such as energy efficiency, water usage, recycling, and site optimization. These technologies will be helpful in your sustainability objectives, but they can become a major source of complexity and time drain for IT teams. So, let’s look at some of the more popular technologies and the recent innovations in Cisco networking solutions that can make deploying them much easier.

Sustainable Technology is Coming to your Campus

The reason I can guarantee that you will soon be deploying sustainable technology is that there are substantial financial rewards for lowering your usage of electricity and material goods. Investments in sustainability are good for the planet and good for your bottom line. Sustainable technology, which is a category of smart building technologies, is a framework of networking solutions that enable businesses to achieve their sustainability goals. These goals usually include a reduction in environmental impact (power, water, recycling, and waste disposal), and optimization of office space and physical assets. Typical devices are automatic window shades that close in direct sunlight, water usage sensors, and of course UPoE+ LED lighting powered by Cisco Catalyst 9000 PoE ports and monitored by Cisco DNA Center. These are popular choices because PoE LED lighting can yield large savings quickly without a complex electrical installation, and water usage sensors are an easy way to detect water leaks – which is the most common and most expensive of office accidents.  The industry for smart building technology is diverse, and you will certainly find an IoT device or sensor for just about any project.

Figure 1: Architectures for smart buildings

The diagram in Figure 1 above, shows the many categories of smart building technologies, as well as the infrastructure and applications that manage and operate the solution. Cisco has a great webpage on our portfolio for smart buildings where you read more about the solution. Many of these technologies are complements or expansions to projects that your team already supports, but the impact of sustainable technology on your network will be substantial. There will surely be hundreds of new sensors, meters, and control devices on your campus network. Most of these will require PoE and many will require local application servers. There are three categories of Cisco DNA Center innovations that facilitate supporting these devices: (1) connecting and securing, (2) powering, and (3) software management.

Connecting and Securing New IoT Devices 

I’m sure you’ve heard about Cisco DNA Center AI-Endpoint Analytics. This feature is in the Policy section of Cisco DNA Center, and it automatically identifies all new endpoints that connect to the network using a cloud-based device manufacturers database. Endpoints are then added to the inventory dashboard and checks and authentications are made using deep packet inspection (DPI) and machine learning to authenticate that the device is what it says it is. Each device is given a “Trust Score” between 1 (suspicious) and 10 (trustworthy) and you can view a list of the verifications that each device has passed. During the lifecycle of devices, Cisco DNA Center will continue to monitor device behavior and any anomalies (such as sudden changes in communication protocols) will be flagged for attention. Additionally, Cisco DNA Center can be configured to automatically isolate devices that demonstrate behavior anomalies.

Besides security and posture information, endpoint inventory includes the manufacturer, model, OS type, software version, and other management information. You can even register the device with the manufacturer within Cisco DNA Center, and if a software upgrade is available, you will be advised right inside the dashboard. The comprehensive dashboard gives you everything you need to connect, secure, and manage the many new IoT devices on your network.

Figure 2: AI endpoint analytics aggregates network data to identify endpoints.

Powering IoT Devices and Managing PoE Capacity

As more PoE devices connect to your network, understanding power usage and availability per branch office and per switch will become critical. The PoE Analytics dashboard in Cisco DNA Center gives you quick and easy visibility of your PoE usage everywhere. You can see the status of PoE consumption across your organization: by branch, building, individual switch, or even by type of device. You can view the total power budget available in any switch, as well as what is allocated, remaining, and load. You can verify the actual amount of power being drawn from each device—this is critical since many IoT devices pull more power than their manual indicates. During the lifecycle of these devices, PoE Analytics monitors spikes in power and pushes alerts for any anomaly to the main Cisco DNA Center Assurance dashboard. Any Cisco DNA Center alert can be exported to your ServiceNow (ITSM) or PagerDuty, and PoE alerts are good candidates for immediate attention. The PoE Analytics dashboard in Cisco DNA Center enables you to plan and manage the power of your IoT devices anywhere in your network.

Figure 3: PoE Analytics facilitates managing power for IoT devices

Edge Compute for Device Software

Another challenge you will likely encounter is the performance of the server software that controls these IoT devices. In many cases, this software is located in the cloud, and the time spent managing it will be minimal. However, some of the more complex sensors may recommend that the server software be installed on-premises for improved performance. This requires either a server in your wiring closet or small Raspberry Pi devices distributed around the campus.

Instead of deploying additional hardware on-site, Cisco DNA Center can help you run these IoT applications on your Catalyst 9000 switches. Cisco Application Hosting on Catalyst 9000 series of switches extend the cloud application to the edge of the network enabling data processing closer to the source for much-improved performance of low-power IoT devices. The app hosting framework inside Catalyst 9000 switches enables off-the-shelf Docker apps, running as separate Linux processes, so they do not affect the switch’s IOS XE performance or security. Installing the application has been streamlined with Cisco DNA Center’s App Hosting Automation dashboard. Simply drag and drop the application into the dashboard and it loads into the Cisco DNA Center’s app hosting library. Then choose the switches where you want the application installed and push them out.

Figure 4: Using Cisco DNA Center to install apps on your Catalyst 9000 switches

Deploying smart building technology to meet your company goals for sustainability and cost optimization will be a big trend in 2023. Training your staff on Cisco DNA Center will enable you to manage this new technology while maximizing your IT staff’s productivity.

Source: cisco.com

Continue reading

Preparing for 2023 and what lies in store for Endpoint Security

A new year is almost upon us and as we look back on our accomplishments in 2022, we also look forward to helping our customers become more security resilient and be better prepared for 2023. As part of this forward-looking process, and with the help of Gartner Peer Insights, we surveyed 100 Security and IT professionals to understand their level of security maturity and obtain their perspective on the future.

The results of the survey, called “Gartner Peer Insights – Future of Endpoint Security” can be found here in Infographic form.

Key insights from the Survey:

◉ Many organizations are employing EDR and XDR capabilities, but few have reached full maturity.

◉ Organizations are looking for integrated platforms that support hybrid workforces while simplifying vendor management.

◉ In anticipation of the ever-increasing threat landscape, organizations are looking to highly integrated and automated endpoint security solutions.

◉ Organizations want future-proof endpoint security solutions that bolster their security resilience.

Insight Example

Regarding the first key insight, approximately two-thirds of the organizations surveyed have implemented EDR and XDR capabilities. These two capabilities are critical to detecting and eliminating threats, either before a breach has occurred or before a breach has had an opportunity to create damage.

Figure 1: Deployed endpoint security capabilities

Insight Example

Another key insight is related to endpoint vendor selection. In the survey, it’s noted that the top criterion organizations are looking for when selecting an endpoint security solution is the ability to support a hybrid workforce. This isn’t surprising given the events that have occurred over the last few years and the mix of remote workers expanding to working from home. Many organizations feel that the hybrid workforce is here to stay, in varying levels of remote workforce vs. on-premises workforce. The obvious implications directly related to the endpoint solutions are flexibility (e.g., deployment options), scalability, efficacy, resilience, and manageability, as a few examples.

Figure 2: Top Motivations when considering endpoint security

Source: cisco.com

Continue reading

Application Resource Management in Healthcare

Four Ways Healthcare Providers Have Benefited from Intersight Workload Optimizer

IT operations teams are like doctors. Doctors practice preventive medicine to help patients keep their health on track. When a patient’s health goes off track, the doctor minimizes symptoms through medication and rest, and they perform assessments to identify the root cause of the ailment.

In a similar way, IT operations teams keep their organizations’ mission-critical applications on track by providing computing, networking, and storage resources. Sometimes an application demonstrates symptoms indicating there’s something wrong (such as sluggish performance). If the root cause is serious enough and goes unaddressed, it can lead to downtime and impact the end user experience.

Treating the symptoms of poor application performance

Too often IT teams spend most of their time addressing the symptoms of underperforming applications or resuscitating them when they go offline. They’re alerted when there’s an issue, but they can’t easily pinpoint the root cause. This means the symptoms get treated to keep applications running, but the underlying cause or causes go untreated, which can lead to recurring application performance issues and costly staff time spent addressing them.

How to stay ahead of application resource issues

Application resource management solutions like Cisco Intersight Workload Optimizer (IWO) provide vital capabilities to help IT teams prevent application resource issues from occurring while optimizing costs to control their budgets.

Here are four examples where Cisco healthcare customers used application resource management to maintain the health of their organizations’ applications in fiscally responsible ways.

1) Ensuring mission-critical application performance

A healthcare services provider was experiencing performance issues with mission-critical applications. They couldn’t identify where in the stack the issues were originating from, so they used AppDynamics and IWO to gain deep visibility from their applications through their underlying computing infrastructure, particularly into hundreds of virtual machines. The visibility showed them when application performance began to stretch VM workloads and how to optimize their virtual environment to ensure continuous resources for optimal application performance. In addition to providing continuous up-time for their mission-critical applications, the customer has used IWO to optimize workloads in the public cloud and reduce public cloud spend by 40%.

2) Maintaining application performance at a lower cost

1) In order to provide continuous application uptime, a healthcare provider in the midwestern United States uses on-premises infrastructure and hosting services through a public cloud provider. However, the costs for on-premises infrastructure and cloud resources were rising rapidly and not sustainable. Using IWO’s “what-if” scenario planning, Cisco worked with the client’s IT group to demonstrate how they could right-size new server purchases and identify the most cost-effective cloud resources to meet their budget requirements. As a result, the healthcare provider can continue to deliver computing resources to provide experiences their application users expect while delivering tangible cost savings.

2) A healthcare provider in the southeastern United States and Cisco UCS customer needed to improve overall infrastructure availability, specifically by getting better insight into the real-time status of VMs and other computing resources. With a restricted IT budget, they also needed to extend the life of existing systems to reduce their CapEx expenses. Using IWO, the healthcare provider identified an opportunity to reduce the number of hosts by 50% while maintaining the same levels of utilization and avoiding unnecessary CapEx investments. At the same time, the healthcare provider used IWO to ensure workload configurations comply with its policies, which has helped the customer improve its HIPAA compliance posture.

3) Conducting an EHR cloud migration analysis

This healthcare provider needed to refresh its Epic hyperspace environment for its primary electronic health record (EHR) system. Their IT team was considering moving to the EHR provider’s cloud-based IaaS solution. The Cisco team used IWO to conduct a detailed total cost of ownership (TCO)/return on investment (ROI) analysis. The study showed the ability to maintain desired application performance with fewer servers (and less cost) than the EHR provider prescribed. The analysis revealed the healthcare provider would save $500,000 per month over three years, or $18 million, by using an on-premises UCS solution instead of the hosted solution. The healthcare provider also went on to use IWO to continue optimizing its virtual environment for ongoing application resource management and cost containment.

Keep your applications in shape through application resource management

As a healthcare provider, your patients, caregivers, and others rely on your applications. With solutions like IWO at your disposal, you have the power to adopt best practices in application resource management and ensure uptime to deliver the experiences your users expect while gaining cost-containment capabilities. Rise above treating the symptoms of an ailing infrastructure; exercise proactive application resource management with Cisco Intersight Workload Optimizer to keep your applications and infrastructure in outstanding shape.

Source: cisco.com

Continue reading

How does ketchup and mustard relate to Cloud Monitoring for Catalyst and DNA Center?

My two sons have very different tastes in many things like activities, clothes, brands, food, and, more than anything, condiments! At home, we have these endless battles on whether ketchup is better than mustard or mustard than ketchup. The message to my kids is that there’s no such thing as a universal better option. There are many reasons why one would choose one over the other: food sensitivities, ingredients, nutritional value, and taste to name a few. My older son likes everything sweet and he doesn’t care too much about sugar content so ketchup is the best option for him. My younger son doesn’t like to mix sweet and savory food and also is more mindful of the nutritional value. For this reason, mustard is best for my younger son.

All this to say that, at Cisco, we strongly believe in giving choices to customers so that everyone can have the solution that works best for them. And this is also true when it comes to managing your Cisco Catalyst infrastructure. One option would be Cisco DNA Center for which I’ve written numerous blogs. We will discuss the characteristics of the recently introduced new option: Cloud Monitoring for Catalyst with Meraki Dashboard. The purpose of these blogs is to give you enough information to make the best choice for your environment.

Meraki Dashboard can provide cloud-based monitoring for Catalyst devices and it’s a great option for numerous environments. For example, networks with Catalyst fixed configuration switches with no management platform or a legacy management platform that needs to be replaced.  Another great use case would be mixed environments with Catalyst switches and Meraki infrastructure like we see in the picture below:

Figure 1: Use Case Examples of Cloud Monitoring for Catalyst

How do you know if Cloud Monitoring is right for your environment? In the next sections we will explore the following capabilities:

◉ Unified view of Cisco network infrastructure

◉ Device health and troubleshooting

◉ Network client and traffic information

Unified view of Cisco network infrastructure

Cisco Cloud Monitoring for Catalyst is especially interesting for environments with mixed Catalyst and Meraki devices because the Meraki dashboard can provide a unified view of the infrastructure including information like switch Up/Down status, model, version, serial number and firmware. Meraki dashboard also provides a topology view of the unified network:

Figure 2: Unified view of Cisco network infrastructure in topology mode

Device health and troubleshooting

Meraki dashboard provides best-in-class cloud monitoring for Meraki devices and now to Catalyst devices as well.  Network administrators can monitor Catalyst connectivity and health from the dashboard, obtain real-time switch and port health, port-level packet and error counters, and alerts for switch or port issues. Catalyst devices also benefit from live troubleshooting tools, like ping and port cycle,  to help identify and correct problems remotely.

Figure 3: Detailed port visibility and live troubleshooting tools

Network client and traffic information

Another very useful capability of the Meraki dashboard is that it provides visibility into the connected devices across the network and detailed network usage and traffic statistics. Meraki dashboard also provides application visibility including top users in the network and top application traffic over time.

Figure 4: Application Visibility

What else do you need to know?

Besides the features and capabilities, there are a few other things you need to know to decide if this platform is the right operational choice for your environment.

◉ Platform: Meraki Cloud Dashboard – SaaS

◉ Capabilities: Monitoring Only (Meraki Dashboard will not configure the device)

◉ Supported Devices: Catalyst Switches 9200/L,  9300/L/X and 9500

◉ Switch OS: IOS-XE

◉ License: DNA Essentials or DNA Advantage

Cisco Catalyst switches mentioned in the list above can be on-boarded for cloud monitoring while retaining all features and capabilities available in IOS-XE. Having said that, the Meraki dashboard will only provide visibility on those features that are available in the Meraki Dashboard. For example, a Catalyst 9300 switch, can run a container with ThousandEyes Enterprise Agent. This switch can be monitored by the Meraki dashboard for all the capabilities mentioned in this blog. It can also retain the ThousandEyes Enterprise Agent installed. However, the Meraki dashboard will not provide monitoring capabilities on ThousandEyes Enterprise Agent deployed in the switch.

For Cloud Monitoring for Catalyst, the switches retain the IOS-XE operating system and the DNA license. There’s no requirement to convert the license to a Meraki license. The switches will leverage the DNA license and both “Essentials” and “Advantage” licenses are supported.  The difference between both is that traffic analytics is only available with the “Advantage” license. All other features are available with both “Essentials” and “Advantage” licenses.

Figure 5: Essentials and Advantage Licenses

With this blog, I hope to have helped you decide your best choice for your operational platform for Catalyst infrastructure.

Source: cisco.com

Continue reading