Secure Access to vCORE

Abstract

The cable distribution system includes a headend connected to a plurality of customer devices through a transmission network including remote fiber nodes, and converting incoming data into analog data suitable for being provided on coaxial cable to the plurality of customer devices. A plurality of vCores instantiated on at least one of the servers are configured within a container to provide services to the plurality of customer devices through the transmission network, each of the vCores including service endpoints that are accessible from within the container, while each of the vCores does not include service endpoints that are directly accessible from a network address outside the container. A gateway instantiated on one of the servers within the container provides access to each of the vCores using the service endpoints over an unencrypted channel, and provides access to the gateway from a network address outside the container over an encrypted channel.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 63 / 177,310, filed April 20, 2021, which is incorporated by reference herein in its entirety. [Background technology]

[0002] The subject matter of this application relates to secure access to a vCore.

[0003] Cable television (CATV) services provide content to a large number of customers (e.g., subscribers) from a central distribution unit, generally referred to as a "headend," which distributes channels of content to its customers through an access network that comprises a hybrid fiber coaxial (HFC) cable plant with associated components (nodes, amplifiers, and taps). However, modern cable television (CATV) service networks not only provide media content, such as television channels and music channels, to customers, but also provide a host of digital communication services, such as Internet services, video on demand, telephone services such as VoIP, home automation / security, etc. These digital communication services, in turn, require communication not only in a downstream direction from the headend to the customers through the HFC, typically forming a branch network, but also in an upstream direction, typically through the HFC network, from the subscribers to the headend.

[0004] To this end, CATV headends have traditionally included a separate cable modem termination system (CMTS) used to provide high-speed data services such as cable Internet, Voice over Internet Protocol, etc., to cable customers, as well as a video headend system used to provide video services such as broadcast video and video on demand (VOD). Typically, the CMTS will include both an Ethernet interface (or other more traditional high-speed data interface) as well as a radio frequency (RF) interface so that traffic coming from the Internet can be routed (or bridged) through the Ethernet interface, through the CMTS, and then onto an RF interface that is connected to the cable company's Hybrid Fiber Coax (HFC) system. Downstream traffic is delivered from the CMTS to cable modems and / or set-top boxes in the customer's home, while upstream traffic is delivered from cable modems and / or set-top boxes in the customer's home to the CMTS. The video headend system in turn provides video to either set-tops, TVs with video decoding cards, or other devices capable of demodulating and decrypting the incoming encrypted video service. Many modern CATV systems combine the functionality of a CMTS with a video distribution system (e.g., EdgeQAM-quadrature amplitude modulation) in a single platform, generally referred to as an integrated CMTS (e.g., an integrated centralized cable access platform (CCAP)), where video services are created and provided to an I-CCAP, which then QAM-modulates the video onto the appropriate frequency. Still other modern CATV systems, generally referred to as a distributed CMTS (e.g., a distributed centralized cable access platform), may include a remote PHY (or R-PHY) that relocates the physical layer (PHY) of a traditional integrated CCAP by pushing it to the fiber node of the network (the R-MAC PHY relocates both the MAC and PHY to the node of the network).Thus, while the core in the CCAP platform performs higher layer processing, the R-PHY devices in the remote nodes convert downstream data transmitted from the core from digital to analog for transmission over radio frequency to cable modems and / or set-top boxes, and convert upstream radio frequency data transmitted from the cable modems and / or set-top boxes from analog to digital format for optical transmission to the core. [Brief description of the drawings]

[0005] For a better understanding of the present invention and to show how it may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which: [Figure 1] Illustrates an integrated cable modem termination system. [Diagram 2] 1 illustrates a distributed cable modem termination system. [Diagram 3] 1 illustrates a layered network processing stack. [Figure 4] Illustrates a server system having a resource allocation manager and a container orchestration system. [Diagram 5] Illustrates a server system having containers and a container orchestration system. [Figure 6] Illustrates a set of vCores and a vCore management interface. [Figure 7] Illustrates a set of vCores and Gateways. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] Referring to FIG. 1, an integrated CMTS system (e.g., an integrated converged cable access platform (CCAP)) 100 may include data 110 that is sent and received over the Internet (or other network), typically in the form of packetized data. The integrated CMTS 100 may also receive downstream video 120, typically in the form of packetized data, from an operator video aggregation system. As an example, broadcast video is typically obtained from a satellite distribution system and pre-processed for distribution to subscribers through a CCAP or video head-end system. The integrated CMTS 100 receives and processes the received data 110 and downstream video 120. The CMTS 130 may transmit the downstream data 140 and downstream video 150 to a customer's cable modem and / or set-top box 160 through an RF distribution network, which may include other devices such as amplifiers and splitters. The CMTS 130 may receive upstream data 170 from the customer's cable modem and / or set-top box 160 through a network, which may include other devices such as amplifiers and splitters. The CMTS 130 may include multiple devices to achieve its desired capabilities.

[0007] Referring to FIG. 2, as a result of increasing bandwidth demands, limited facility space for integrated CMTS, and power consumption considerations, it is desirable to include a distributed cable modem termination system (D-CMTS) 200 (e.g., a distributed centralized cable access platform (CCAP)). Generally, CMTSs focus on data services, while CCAPs also include broadcast video services. The D-CMTS 200 distributes a portion of the functionality of the I-CMTS 100 downstream to a remote location, such as a fiber node, using network packetized data. An exemplary D-CMTS 200 may include a remote PHY architecture, where the remote PHY (R-PHY) is preferably an optical node device located at the junction of fiber and coax. Generally, the R-PHY often includes the PHY layer of a portion of the system. The D-CMTS 200 may include a D-CMTS 230 (e.g., a core) that includes data 210 that is transmitted and received over the Internet (or other network), typically in the form of packetized data. The D-CMTS 200 may also receive downstream video 220, typically in the form of packetized data from an operator video aggregation system. The D-CMTS 230 receives and processes the received data 210 and downstream video 220. The remote fiber node 280 preferably includes a remote PHY device 290. The remote PHY device 290 may transmit the downstream data 240 and downstream video 250 to a customer's cable modem and / or set-top box 260 over a network that may include other devices such as amplifiers and splitters. The remote PHY device 290 may receive upstream data 270 from a customer's cable modem and / or set-top box 260 over a network that may include other devices such as amplifiers and splitters. The remote PHY device 290 may include multiple devices to achieve its desired capabilities.The remote PHY device 290 primarily includes PHY-related circuitry such as a downstream QAM modulator, an upstream QAM demodulator, along with pseudowire logic that connects to the D-CMTS 230 using network packetized data. The remote PHY device 290 and the D-CMTS 230 may include data and / or video interconnects such as downstream data, downstream video, and upstream data 295. Note that in some embodiments, video traffic may go directly to the remote physical device, thereby bypassing the D-CMTS 230. In some cases, the remote PHY and / or remote MAC PHY functionality may be provided at the headend.

[0008] As an example, the remote PHY device 290 may convert downstream DOCSIS (i.e., Data Over Cable Service Interface Specification) data (e.g., DOCSIS 1.0, 1.1, 2.0, 3.0, 3.1, and 4.0, each of which is incorporated herein by reference in their entirety), video data, and out-of-band signals received from the D-CMTS 230 to analog for transmission over RF or analog optics. As an example, the remote PHY device 290 may convert upstream DOCSIS and out-of-band signals received from an analog medium, such as RF or linear optics, to digital for transmission to the D-CMTS 230. As can be seen, depending on the particular configuration, the R-PHY may move all or a portion of the DOCSIS MAC and / or PHY layers to the fiber node.

[0009] An I-CMTS device is typically a custom-built hardware device consisting of a single chassis containing a series of slots, each of which receives a respective line card having a processor, memory, and other computing and networking functions supported thereon. Each of the line cards contains the same hardware configuration, processing power, and software. Each of the line cards performs the functions of the I-CMTS device, including MAC and PHY functions. As the system grows in size to support more customers, additional line cards are included in the system to expand the processing power of the system. Unfortunately, dynamically scaling the number of line cards in real time to meet the demands of a particular network is problematic.

[0010] The computational power of microprocessor-based commercial off-the-shelf (COTS) server platforms is increasing while the cost of such systems is decreasing over time. With such systems, a computing system is optionally virtualized and operated using one or more COTS servers, generally referred to herein as virtual machines. Using container technology running on the COTS servers and / or virtual machines, the COTS servers may run only a single operating system. Each virtualized application may be isolated using software containers, and the virtualized applications may not see or be aware of other virtualized applications running on the same machine. Typically, each COTS server includes one or more Intel / AMD processors (or other processing devices) with associated memory and networking capabilities that run operating system software. Typically, COTS servers include a framework and an operating system, where user applications run on such frameworks and the operating system is abstracted away from the actual operating system. Each virtual machine may be instantiated and operated as one or more software applications running on the COTS server. Multiple software containers may be instantiated and run on the same COTS server and / or the same virtual machine. The COTS servers are typically contained in one or more data centers, each of which is in communication with one another. The COTS servers may be located in different geographic regions to provide geographic redundancy. In some embodiments, a container may contain the same functionality as a virtual machine, or vice versa. In some embodiments, a group of containerized components, generally referred to as a pod, may be in the form of a virtual machine.

[0011] In some embodiments, the COTS server may be a "bare metal" server that typically includes an operating system along with drivers and portions of a container orchestration system. One or more containers are then added to the "bare metal" server while being managed by the container orchestration system. The container orchestration system described herein may similarly function as a virtual machine orchestration system and be referred to as a virtual machine orchestration system, if desired. In some embodiments, the "bare metal" server may be used as a pod that runs on an operating system along with drivers and the container orchestration system. In some embodiments, the virtual machine may be omitted from the COTS server.

[0012] Selected software processes included in the line cards and / or remote PHY devices may include software containers and execute on COTS servers, including both "active" and "backup" software processes, and may execute on "bare metal" servers and / or virtual machines. The functionality provided by such "bare metal" servers and / or virtual machines may include higher level functionality, such as packet processing including routing Internet packet provisioning, Layer 2 Virtual Private Networking operating over pseudowires, and Multi-Protocol Label Switching routing. The functionality provided by such "bare metal" servers and / or virtual machines may include DOCSIS functionality, such as DOCSIS MAC and encapsulation, channel provisioning, service flow management, quality of service and rate limiting, scheduling, and encryption. The functionality provided by such "bare metal" servers and / or virtual machines may include video processing, such as EQAM and MPEG processing.

[0013] Each of the COTS servers and / or virtual machines and / or software containers may include different hardware profiles and / or frameworks. For example, each of the COTS servers and / or “bare metal” servers and / or virtual machines and / or software containers may run on different processor types, different numbers of processing cores per processor, different amounts of memory for each processor type, different amounts of memory per processing core, different encryption capabilities, different amounts of available off-processor memory, different memory bandwidth (DDR) speeds, various types and capabilities of network interfaces, such as Ethernet cards. Thus, different COTS servers and / or “bare metal” servers and / or virtual machines and / or software containers may have different processing capabilities that vary depending on the particular hardware. Each of the COTS servers and / or “bare metal” servers and / or virtual machines and / or software containers may include different software profiles. For example, each of the COTS servers and / or “bare metal” servers and / or virtual machines and / or software containers may include different software operating systems and / or other services that run on them, generally referred to herein as frameworks. In this manner, different COTS servers and / or "bare metal" servers and / or virtual machines and / or software containers may have different software processing capabilities that vary depending on the particular software profile.

[0014] 3, for data processing and forwarding of data over a network, the hardware and / or software architecture may be configured in the form of multiple different planes, each of which performs a different set of functions. In relevant part, the layered architecture may include different planes, such as a management plane 300, a control plane 310, a data plane 320, and a switch fabric 330, which may perform the transmission and reception of packets of data.

[0015] For example, the management plane 300 may be generally thought of as the general software applications that a user interacts with or otherwise executes, and typically configures and manages all layers of the network stack and other parts of the system, providing the management and configuration that they provide.

[0016] For example, the control plane 310 is often a component to the switching function, including system configuration, management, and the exchange of routing table information and forwarding information. Typically, the exchange of routing table information is performed relatively infrequently. The route controllers of the control plane 310 exchange topology information with other switches and build routing tables based on routing protocols. The control plane may also create forwarding tables for the forwarding engines. In general, the control plane may be thought of as the layer that determines where traffic is sent. Control functions tend not to have strict rate constraints because they are not performed for each individual packet that arrives.

[0017] For example, the data plane 320 parses packet headers for switching, managing quality of service, filtering, media access control, encapsulation, and / or queuing. As a general matter, the data plane carries data traffic, which may be the case in a cable distribution network. In general, the data plane may be thought of as a layer that primarily forwards traffic to the next hop through the switch fabric, according to control plane logic, along a path to a selected destination. The data plane tends to be highly rate constrained, since it performs functions for each individual packet that arrives.

[0018] For example, switch fabric 330 provides a network topology that interconnects network nodes through one or more network switches.

[0019] As the system expands to support additional customers, additional COTS servers and / or "bare metal" servers and / or virtual machines and / or software containers are included in the system to expand the overall processing power of the system. To provide processing redundancy, one or more additional COTS servers and / or "bare metal" servers and / or virtual machines and / or software containers may be included and allocated as "backups" to replace "active" processes upon detection of a failure event. The scaling of the data plane 320 on the COTS servers and / or "bare metal" servers and / or virtual machines and / or software containers should be performed in such a manner as to ensure fast enough processing of data packets and sufficient bandwidth for the transmission of the data packets so that data packets are not otherwise lost.

[0020] It is desirable to virtualize portions of the data plane, particularly the remote PHY functions on COTS and / or "bare metal" servers. In this manner, MAC cores for cable distribution systems may run on COTS and / or "bare metal" servers. By reference herein, a virtualized remote PHY MAC core may be referred to as a vCore instance.

[0021] Referring to FIG. 4, it is desirable to incorporate the platform as a service using operating system level virtualization to deliver software in packages, generally referred to as containers 410. Each of the containers is isolated from the others and bundles its own software, libraries, and configuration files. The containers may communicate with each other using defined channels. As a general matter, one or more applications and their dependencies may be packed into a virtual container that can run on a COTS server and / or “bare metal” server and / or virtual machine. This containerization increases the flexibility and portability of running applications on on-premise COTS servers, “bare metal” servers, public cloud COTS servers, private cloud COTS servers, or otherwise. If each container is relatively lightweight, a single COTS server and / or “bare metal” server, and / or virtual machines running on the COTS server and / or “bare metal” server may run multiple containers simultaneously. Additionally, the COTS servers and / or “bare metal” servers, and / or virtual machines and / or containers may be distributed within a cable distribution system.

[0022] The COTS servers and / or "bare metal" servers and / or virtual machines may include a container orchestration system 420 for automating application deployment, scaling, and management of containers 410 across one or more COTS servers and / or "bare metal" servers and / or virtual machines. The computing device that runs the container orchestration system 420 is preferably separate from the computing device that provides the containers for the data plane application. It should be understood that the virtual machines illustrated in FIG. 4 may be omitted, such as COTS B. Application deployment, scaling, and management of containers may include clusters across multiple hosts, such as multiple COTS servers. Container deployment, maintenance, and scaling may be based on characteristics of the underlying system capabilities, such as, for example, different processor types, different numbers of processing cores per processor, different amounts of memory for each processor type, different amounts of memory per processing core, different amounts of available off-processor memory, different memory bandwidth (DDR) speeds, different frameworks, and / or various types and capabilities of network interfaces, such as Ethernet cards. Additionally, container orchestration system 420 may allocate different amounts of underlying system capabilities, such as a particular processor type, a selected number of processors (e.g., one or more), a particular number of processing cores per selected processor, a selected amount of memory for each processor type, a selected amount of memory per processing core, a selected amount of available off-processor memory, a selected framework, and / or a selected amount and / or type of network interfaces, such as Ethernet cards. A corresponding agent for container orchestration system 420 may be included in each COTS server (e.g., COTS A and / or COTS B).

[0023] Container orchestration system 420 may include groupings of containerized components generally referred to as pods 430. A pod may consist of one or more containers coexisting on the same COTS server, and / or "bare metal" server, and / or the same virtual machine, and may share the resources of the same COTS server, and / or "bare metal" server, and / or the same virtual machine. Each pod 430 is preferably assigned a unique pod IP address within the cluster, which allows applications to use ports without risk of conflicts. Within a pod 430, each of the containers may reference each other based on localhost or other addressing services, but containers in one pod preferably do not have a way to directly address another container in another pod, and therefore preferably use a pod IP address or otherwise addressing services.

[0024] A conventional D-CMTS RPHY core may be implemented as a purpose-built appliance that includes both software and hardware to achieve desired performance characteristics, such as ensuring the timing of data packet transmission. Because of their fixed characteristics, purpose-built appliances do not support auto-deployment or auto-scaling. In contrast to purpose-built appliances, vCore instances are preferably implemented in software running on COTS and / or “bare metal” servers on operating systems such as Linux. vCore instances are preferably implemented in a manner that easily facilitates automation techniques such as lifecycle management, elastic scaling, health monitoring, telemetry, and the like. Unfortunately, running vCore instances on COTS and / or “bare metal” servers tends to create several challenges, primarily related to the data plane components. One of the main challenges is to reliably provide data to the network in a timely and effective manner to realize the real-time characteristics of the cable data distribution environment. The cable data distribution environment includes real-time constraints on the timing of data packet delivery that do not exist in typical web-based or database environments.

[0025] Each vCore instance is preferably implemented in a container, and the size (e.g., scale, memory, CPU, allocation, etc.) of each container translates into the amount of server hardware and software resources allocated to the particular vCore instance. The amount of server hardware and software resources allocated to each particular vCore instance is preferably a function of the number of groups and / or numbers of customers (e.g., service groups) for which the vCore instance can facilitate RPHY MAC Core services. For example, a limited amount of server hardware and software resources may be allocated to a particular vCore instance having a limited number of customers and / or groups of customers. For example, a substantial amount of server hardware and software resources may be allocated to a particular vCore instance having a substantial group and / or number of customers. For example, selected server hardware resources are preferably allocated between different vCore instances in a non-overlapping manner such that each vCore instance has a dedicated and predictable amount of server hardware resources. For example, selected software resources are preferably allocated between different vCore instances in a non-overlapping manner such that each vCore instance has a dedicated and predictable amount of software resources.

[0026] For example, the number of CPU cores preferably assigned to each vCore instance (Cc) may be a function of the sum of USSGs (Upstream Service Groups - a group of customer modems and / or set-top boxes) and DSSGs (Downstream Service Groups - a group of customer modems and / or set-top boxes) (DSsg) connected through that vCore instance. This is expressed as: vCore:Cc=f 1 (USsg,DSsg). Other hardware and / or software characteristics may be similarly assigned as desired.

[0027] For example, the network capacity allocated to each vCore instance (Cbw) can be a function of the total USSGs (Upstream Service Groups - a group of customer modems and / or set-top boxes) (USsg) and the total DSSGs (Downstream Service Groups - a group of customer modems and / or set-top boxes) (DSsg) connected to that vCore instance. This means that Cbw=f 2 (USsg,DSsg). Similarly, other hardware and / or software characteristics may be assigned as desired.

[0028] Scaling a vCore instance may refer to the ability to automatically create and deploy vCore instances in containers on COTS servers and / or "bare metal" servers and / or virtual machines that are appropriately sized to serve a particular set of remote physical devices and / or service groups (e.g., a set of cable customers) and / or cable customers. Scaling a vCore instance may also, in some cases, include the ability to automatically modify the hardware and / or software characteristics of existing vCore instances in containers on COTS servers and / or "bare metal" servers and / or virtual machines to be appropriately sized to serve a modified particular set of remote physical devices and / or service groups (e.g., a set of cable customers) and / or cable customers.

[0029] The resource allocation manager 470 may allocate or reallocate an appropriate amount of hardware and software COTS server and / or "bare metal" server resources to each particular vCore instance (e.g., CPU cores, and / or memory, and / or network capacity). The amount of such COTS server and / or "bare metal" server hardware and software resources allocated or reallocated to each vCore instance is a function of its scale and may also be other characteristics such as various other resource allocations. An agent corresponding to the resource allocation manager 470 may be included in each COTS server (e.g., COTS A, COTS B).

[0030] The vCore instance includes data plane software for forwarding data packets and other functions of the data plane. The data plane software may include a set of data plane libraries and network interface controller (NIC) drivers used to manage data packets for the data plane. Preferably, the data plane software runs in user space, as opposed to kernel space as in typical network processing software, and therefore does not use the operating system kernel and container-managed network drivers and plug-ins. For example, the data plane software may include a queue manager, a buffer manager, a memory manager, and / or a packet framework for packet processing. The data plane software may use CPU cores that are separate from the kernel, meaning that no operating system scheduled processes are running on these separate CPU cores. Separating the CPU cores between the data plane software and the operating system software ensures that tasks performed by the operating system software do not prevent the data plane software from processing data packets in a timely manner. Additionally, separating the CPU cores between the data plane software and the operating system software allows the same physical central processing unit to be used by both, albeit with different cores. Additionally, other hardware and / or software capabilities may be similarly isolated, such as, for example, a selected processor (e.g., one or more), a particular number of processing cores per selected processor, a selected amount of memory for each processor type, a selected amount of memory per processing core, a selected amount of available off-processor memory, a selected framework, and / or a selected amount and / or network interfaces, etc.

[0031] Also, each vCore instance desirably has dedicated network bandwidth capabilities separate from other vCore instances and operating system software. To provide dedicated network bandwidth to the vCore instances, a physical network interface card may be virtualized to allow multiple different software applications to utilize the same network interface card, each with a guaranteed amount of available bandwidth. The network interface card is preferably virtualized using Single Root Input Output Virtualization (SR-IOV). SR-IOV splits the physical function (e.g., PF) of a NIC into one or more Virtual Functions (VFs). The capabilities of PFs and VFs generally differ. Generally, PFs support queues, descriptions, offloads, hardware locking, hardware link control, etc. Generally, VFs support queue and descriptor based networking functions.

[0032] Automated creation, deployment, and deletion of vCore instances can be performed by the container orchestration system 420.

[0033] 5, on a COTS and / or “bare metal” server 500, a vCore instance 530 may operate as a remote PHY MAC core for one or more remote physical devices connected via a centralized interconnect network, typically located in the same hub. The vCore instance 530 may include data plane software 532. Each of the vCore instances 530 is generally referred to as a pod. In some cases, multiple vCores may be included in a pod. The COTS server 500 may communicate with the Internet 560, a set of networking switches 570, remote physical devices 580, and customers 590. The COTS and / or “bare metal” servers with the vCore instances operating thereon are typically relatively high performance servers with one or more of the following characteristics:

[0034] Hardware: At least one management NIC 510 is typically connected to a separate management network 512. The management NIC 510 is primarily used for orchestration and management of server applications, which may also manage data tracks.

[0035] Preferably, at least two (for redundancy) Data Plane NICs 514 (i.e., data plane physical network interfaces) are included, along with SR-IOV and PTP (IEEE 1588) 522 for hardware timestamp capabilities of data packets. The Data Plane NICs 514 are used to provide connectivity to remote physical devices and customer modems and / or set-top boxes / consumer premises equipment behind such remote physical devices. Each vCore instance 530 may include a Virtual Function 534 network interface for each of the Data Plane NICs 514.

[0036] In addition, the hardware may include a dedicated device for DES encryption.

[0037] software: Preferably, the operating system of the COTS and / or "bare metal" servers is a LINUX OS such as Ubuntu, Redhat, etc.

[0038] The COTS servers, and / or "bare metal" servers, and / or virtual machines include the container software.

[0039] COTS servers, and / or "bare metal" servers, and / or virtual machines, and / or other servers include at least a portion of the container orchestration system.

[0040] The COTS servers, and / or "bare metal" servers, and / or virtual machines, and / or other servers may include a resource allocation manager (RAM) 520 that manages, at least in part, the server allocation of software and / or hardware resources for vCore instances, including, for example, CPU cores, memory, VFs, MAC addresses, etc. The RAM 520 may also provide server configuration, including OS configuration, driver support, etc., diagnostics and health monitoring. The COTS servers, and / or "bare metal" servers, and / or other servers may include an orchestration application 540 that manages, at least in part, the management of vCores (e.g., containers and / or pods).

[0041] The COTS servers and / or "bare metal" servers and / or other servers may run a PTP application 522 that synchronizes the system clocks of the COTS servers and / or "bare metal" servers and / or virtual machines and / or vCore instances 520 based on a system-wide grandmaster clock. For improved accuracy, the PTP application 522 is preferably based on hardware time stamping and an accurate hardware clock present on the NIC 514. As a general matter, the vCores preferably perform the MAC layer functions.

[0042] Referring to FIG. 6, a simplified illustrative diagram shows that each of the vCores 600 conventionally includes a command line interface 610 for receiving instructions for configuration, diagnostics, control, and management. A command line interface processes commands in the form of lines of text. A command line interface may be provided using a shell to provide interactive access to the functions or services of a corresponding operating system. Multiple vCores, such as 32 vCores, may be installed on a COTS server, and / or a "bare metal" server, and / or a virtual machine, and / or other server 620 (generally referred to herein as a "server"). Each of the vCores 600 on the server 620 includes a respective command line interface 610. The vCore management interface 630 provides access to each of the respective vCores 700, such as opening a respective terminal window, to facilitate access to the respective command line interface 610. As an example, an operator may open a terminal window to access the command line interface on the first vCore and execute commands therein. For example, two-way interactive text-oriented communication may be used for such command execution, such as telnet. At least 32 such terminal windows are opened and 32 sets of commands are executed to provide such configuration, diagnostics, control, and management for each of the vCores. For large systems, there may be many servers, each with a significant number of vCores, and thus potentially thousands of vCores that need to be accessed periodically on an individual basis. This is an expensive task to perform using the management interface 630.

[0043] A vCore is preferably instantiated within each Pod within a Kubernetes infrastructure. Kubernetes is primarily designed for horizontally scaled deployment of microservices, especially load balancing. In a Pod / Kubernetes infrastructure, vCores preferably do not include externally visible endpoints outside of the Pod / Kubernetes infrastructure. In some configurations, such as non-Pod / Kubernetes infrastructures, it is not desirable to include externally visible endpoints in each vCore due to limitations in the number of such externally visible endpoints (e.g., IP addresses within a namespace) available, management of such externally visible endpoints, and security considerations. However, for vCores that provide data plane services within a Pod / Kubernetes infrastructure, it is desirable to have addressable access to the data plane services in each respective vCore. Existing tools for managing CMTSs are not well adapted for managing vCores within a Pod / Kubernetes infrastructure, in part due to the lack of a unique externally addressable interface (a.k.a. an externally addressable IP address) to the Pod / Kubernetes infrastructure. Thus, the Pod / Kubernetes infrastructure in which the vCores are hosted does not include out-of-band management capabilities. Additionally, using bandwidth management to access the pod / Kubernetes infrastructure on which the vCores are hosted through the local network is undesirable as using a terminal window to access a command line interface on the first vCore and then executing commands using unencrypted clear text that would typically be transmitted over the internet to the server would raise substantial security considerations.

[0044] Referring to FIG. 7, it is desirable to include a virtual network interface 700, which is an abstract virtualized representation of a computer network interface, as part of the Gateway 710 to provide access to the vCores of the Pod / Kubernetes infrastructure. Each of the vCores includes an internally accessible service endpoint that is internally accessible to the Pod / Kubernetes infrastructure and is not directly externally accessible to the Pod / Kubernetes infrastructure. As an example, a service endpoint for a vCore may be vCore1.123.Cable-Network.Service-endpoint and another vCore's service endpoint may be vCore2.123.Cable-Network.Service-endpoint. The Gateway 710 using the virtual network interface 700 in combination with a Kubernetes domain name system controller 740 contained within the Pod / Kubernetes infrastructure resolves the location / access of each vCore. In this manner, each vCore is mapped to the Gateway 710 with an internally accessible service endpoint, while each vCore is not mapped to the Pod / Kubernetes infrastructure with an externally accessible service endpoint (e.g., not externally routable). Commands provided from the Gateway to the vCores within the Pod / Kubernetes infrastructure are preferably in plaintext, which is suitable for traditional management tools, and furthermore, by restricting such plaintext from being exchanged from within the Pod / Kubernetes infrastructure, it does not raise security concerns.

[0045] While unencrypted exchanges are permitted between Gateway 710 and vCores within the Pod / Kubernetes infrastructure, Gateway 710 includes one or more externally accessible service endpoints to the Pod / Kubernetes infrastructure (e.g., IP addresses) that allow only encrypted exchanges, such as through a secure socket shell, from Computer 750 across an insecure network (e.g., the Internet). As can be observed, the Gateway within the Pod / Kubernetes infrastructure serves as an aggregation point for internal vCores to be accessed by external computers. The Gateway also allows the use of unencrypted scripts to provide configuration, diagnostics, control, and management of vCores in an efficient manner while access to the Gateway is provided in an encrypted manner. In this way, there may be a single encrypted aggregate command line interface access point covering an entire cluster of vCores, while unencrypted channels are used within the Pod / Kubernetes infrastructure. As an example, a service port for telnet communication may be managed as a pooled resource with a configurable fixed pool size shared across multiple telnet sessions terminating on the same vCore. A service port may be deleted when all sessions that were using the port have terminated.

[0046] The Gateway is preferably configured with configuration, diagnostic, control, and management software used to communicate with the vCores. In this manner, external connections to the Gateway are configured such that any attempt to execute any other command in the restricted shell will immediately terminate the shell / user's session with the Gateway. Authentication of external access to the Gateway may depend on the credentials. As an example, command line access using an external secure socket shell allows access to the vCores by name, access that may be filtered by node name, and access using the full list of available vCores. Access routes from the Gateway may be provided by dynamically created Kubernetes service routes from the Gateway to the vCores. Existing service routes may be (re)used when currently instantiated, uninterrupted when still in use, or otherwise cleaned up. Terminal configuration may be retained such that command extension / extension, history, and help features of the command line interface are retained. Also, for auditing purposes, the Gateway logs the username on login, access time, and username and exit time when terminating an application / service. Additional software may also be included that complements the Gateway, allowing the user to automatically run configuration and diagnostic scripts on the target vCore through the Gateway and return the results.

[0047] Furthermore, each functional block or various features in each of the above-mentioned embodiments may be implemented or performed by a circuit, typically an integrated circuit or multiple integrated circuits. A circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application specific or general-purpose integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, or discrete hardware components, or a combination thereof. A general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each circuit described above may be composed of digital circuits or may be composed of analog circuits. Furthermore, as advances in semiconductor technology emerge that allow integrated circuits to replace multiple integrated circuits at present, integrated circuits according to this technology may also be used.

[0048] It will be understood that the present invention is not limited to the particular embodiments described, and that modifications may be made thereto, as interpreted in accordance with the principles of prevailing law, including the doctrine of equivalents, or any other principle that expands the scope of an enforceable claim beyond its literal scope, without departing from the scope of the invention as defined in the appended claims. Unless the context indicates otherwise, a reference in a claim to the number of instances of an element, whether it is a reference to one instance or to multiple instances, is not intended to preclude a claim, structure, or method having more instances of that element than are recited, although it requires at least the stated number of instances of the element. As used in the claims, the term "comprise" or its derivatives is used in a non-exclusive sense that is not intended to preclude the presence of other elements or steps in the claimed structure or method.

Claims

1. 1. A cable distribution system comprising: (a) a headend connected to a plurality of customer devices through a transmission network including remote fiber nodes, the headend converting received data into analog data suitable for being provided over coaxial cables to the plurality of customer devices, the headend including at least one server each including a respective processor; (b) a plurality of vCores instantiated on one of the at least one server of the headend configured within a container to provide services to the plurality of customer devices over the transport network, each of the vCores including a service endpoint accessible from within the container, while each of the vCores does not include a service endpoint directly accessible from a network address outside the container; (c) a gateway instantiated on the one of the at least one server of the headend within the container that provides access to each of the plurality of vCores using the service endpoint over an unencrypted channel; (d) a cable distribution system, wherein the gateway provides access to the gateway from a network address external to the container via an encrypted channel.

2. 2. The cable distribution system of claim 1, wherein the headend connected to the plurality of customer devices through the transmission network includes a plurality of remote physical nodes that include physical layer processing and provide suitable data to the plurality of customer devices.

3. 2. The cable distribution system of claim 1, wherein each of said vCores includes a respective command line accessible by said gateway from said service endpoint.

4. 2. The cable distribution system of claim 1, wherein each of said plurality of vCores is accessible from said service endpoint by said gateway using Telnet.

5. The cable distribution system of claim 1 , wherein each of the plurality of vCores is instantiated within a respective pod.

6. 2. The cable distribution system of claim 1, wherein each of said plurality of vCores does not include an externally addressable IP address to said container.

7. The cable distribution system of claim 1 , wherein said gateway includes a virtual network interface for providing said access to each of said plurality of vCores using said service endpoints over said unencrypted channel.

8. 2. The cable distribution system of claim 1, wherein the gateway provides the access to each of the plurality of vCores resolved based on a Domain Name System Controller contained within the container.

9. 2. The cable distribution system of claim 1, wherein the gateway does not provide access to the gateway from the network addresses outside the container over an unencrypted channel.

10. 2. The cable distribution system of claim 1, wherein said gateway provides said access to each of said plurality of vCores by name.

11. 2. The cable distribution system of claim 1, wherein said gateway provides said access to each of said plurality of vCores filtered by name.

12. 2. The cable distribution system of claim 1, wherein said gateway provides said access to each of said plurality of vCores using a complete list of said plurality of available vCores.

Images