Browse Prior Art Database

LARGE-SCALE VIRTUAL PRIVATE NETWORK FOR INTERNET OF THINGS AND INDUSTRIAL INTERNET USE CASES

IP.com Disclosure Number: IPCOM000248739D
Publication Date: 2017-Jan-03
Document File: 4 page(s) / 93K

Publishing Venue

The IP.com Prior Art Database

Related People

Manish Kumar: AUTHOR

Abstract

There are two unique characteristics of a virtual private network (VPN) concentrator in certain deployments (e.g., smart grids, Internet of Things (IoT), etc.). First, a use case calls for the concentrator to handle very large scales. Second, the spokes, which are often local concentrators, have very limited networking functions. Despite the second characteristic, for ease of functionality (e.g., management, deployment, etc.), the address assignment is still largely dynamic. As presented herein, an address assignment/management protocol (e.g., Dynamic Host Configuration Protocol (DHCP)) can populate the relevant state (e.g., forwarding, encapsulation, cryptography, etc.) on the concentrator for a very large-scale VPN for such use cases. In an example, DHCP programs the Next Hop Resolution Protocol (NHRP) to create a unicast mapping and, optionally, a multicast mapping and routes for remote devices/networks. This helps leverage many functions of a highly feature-rich (i.e., built over the course of a decade) dynamic multipoint VPN (DMVPN) hub, even though the remote devices (spokes) need not be running DMVPN.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Copyright 2017 Cisco Systems, Inc. 1

LARGE-SCALE VIRTUAL PRIVATE NETWORK FOR INTERNET OF THINGS AND INDUSTRIAL INTERNET USE CASES

AUTHORS: Manish Kumar

CISCO SYSTEMS, INC.

ABSTRACT

There are two unique characteristics of a virtual private network (VPN)

concentrator in certain deployments (e.g., smart grids, Internet of Things (IoT), etc.).

First, a use case calls for the concentrator to handle very large scales. Second, the spokes,

which are often local concentrators, have very limited networking functions. Despite the

second characteristic, for ease of functionality (e.g., management, deployment, etc.), the

address assignment is still largely dynamic. As presented herein, an address

assignment/management protocol (e.g., Dynamic Host Configuration Protocol (DHCP))

can populate the relevant state (e.g., forwarding, encapsulation, cryptography, etc.) on the

concentrator for a very large-scale VPN for such use cases. In an example, DHCP

programs the Next Hop Resolution Protocol (NHRP) to create a unicast mapping and,

optionally, a multicast mapping and routes for remote devices/networks. This helps

leverage many functions of a highly feature-rich (i.e., built over the course of a decade)

dynamic multipoint VPN (DMVPN) hub, even though the remote devices (spokes) need

not be running DMVPN.

DETAILED DESCRIPTION

As fields such as Industrial Internet and Internet of Things (IoT) grow, an

increasing volume of lightweight embedded devices are deployed. These devices are

typically based on very lightweight real-time operating systems (RTOSs) and have very

limited networking functions. In this space, headends are the typical networking

equipment. There is a need for a plausible, very large-scale virtual private network (VPN)

solution for such use cases where the remote side may not even support many basic

networking protocols. One example of such requirements originates from Electric Power

Copyright 2017 Cisco Systems, Inc. 2

Companies (EPCOs), which use embedded devices instead of very lightweight operating

systems. For example, MicroITRON is a popular RTOS in Japan and is used in devices

including cameras, games, and networking equipment.

As smart grid and IoT deployments increase, a particular type of deployment is

becoming rather common. Specifically, field objects (e.g., smart meters) connect to local

concentrators, which in turn terminate on a headend (e.g., a Cisco Systems’ Aggregated

Services Router (ASR) 1000). There are certain common characteristics of these

deployments, including:

• Relatively low traffic but very large-scale traffic at the headend.

• Use of peer-to-peer (P2P) generic routing encapsulation (GRE) tunnels between

the concentrator and the headend.

• The local concentrators are generally light, rugged devices with minimal

functionality.

Given such high scaling at the headend, the manual P2P GRE tunnels on the hub

become unmanageable. Additionally, it leads to very high convergence, fallback, and

reload times for the hub device b...