IP network QOS implemented by application category detection and session association

Abstract

The present solution provides a Quality of Service (QoS) enablement involving automatic detection of application categories that produce IP traffic in an IP network with multi-stage processing of selected packets based on a dynamic "Shallow Packet Inspection" procedure. The detected application categories may be classified to meet specific QoS requirements, such as low latency, high throughput, and low packet loss. A source device may dynamically tag the packet in an upstream direction based on detected application session attributes, allowing for appropriate QoS queue mapping and transmission. Similarly, downstream packets may be correlated and associated with corresponding upstream packets, ensuring consistent QoS tags and downstream queue mappings for efficient downstream transmissions on destination devices.

Description

Technical Field

[0001] This disclosure generally relates to systems and methods for IP network Quality of Service (QoS) technologies, and more particularly to IP network QoS enabling. Background Technology

[0002] Quality of Service (QoS) in IP networks can be implemented in various networks, such as Wi-Fi, DOCSIS, DSL / PON, and core IP networks involving various network devices such as modems, gateways, and set-top boxes. Summary of the Invention

[0003] In IP networks, traditional methods of QoS enabling typically employ static network configuration and / or fixed packet labeling by applications that generate various IP services. Examples of such Internet Protocol (IP) networks include Wi-Fi networks, Cable Data Service Interface Specification (DOCSIS) access networks, Digital Subscriber Line (DSL), Passive Optical Network (PON), DSL / PON access networks, and core IP networks. Network devices on these networks may include wired / DLS / PON modems and residential gateways, IP set-top boxes (STBs), and more.

[0004] This disclosure provides a novel alternative to conventional methods for QoS enabling, with several contributions and advantages. This solution allows source devices (e.g., SoCs) to automatically detect the category of applications generating IP traffic across IP networks. Detection can be based on multi-stage processing of a set of selected packets associated with an application session. Compared to the typical static “deep packet inspection (DPI)” in conventional QoS systems, the processing of selected packets can rely on a dynamic “shallow packet inspection” process, and is therefore faster and more computationally efficient. Application categories can be classified for specific QoS requirements, such as low latency, high throughput, and low packet loss.

[0005] The results of application category detection can be used by the source device to dynamically label (e.g., with DSCP) packets upstream based on the detected application session attributes. The detected application session attributes include application category, session start / end, bandwidth variations, inter-packet interval statistics, etc. Session attributes can be dynamically mapped to packet tags that convey corresponding QoS requirements.

[0006] The source device can map dynamic tags in upstream packets to appropriate QoS queues for upstream transmission. For downstream packets, the source device can associate and correlate downstream packets with corresponding upstream packets, and apply the corresponding QoS to the receive QoS queue. On the destination device (e.g., SoC) side, tagged upstream packets can be associated and correlated with corresponding downstream packets. Associated downstream packets can be tagged with tags consistent with (e.g., the same) as upstream packets. The destination device can map dynamic tags in downstream packets to appropriate QoS queues for downstream transmission. Attached Figure Description

[0007] These and other aspects and features of this embodiment will become apparent to those skilled in the art after reading the following description of specific embodiments in conjunction with the accompanying drawings.

[0008] Figure 1 This is an example block diagram of the SGS architecture according to an embodiment of this solution.

[0009] Figure 2 This is an example block diagram of the Netify architecture according to an embodiment of this solution.

[0010] Figure 3 This is an example block diagram of a system according to an embodiment of this solution.

[0011] Figure 4 This describes the instance detection process according to an embodiment of this solution.

[0012] Figure 5 This describes an example of an application protocol detection layer according to an embodiment of this solution.

[0013] Figure 6 This describes an example of an application protocol detection process according to an embodiment of this solution.

[0014] Figure 7 This describes an example of UDP packet APP detection according to an embodiment of this solution.

[0015] Figure 8 This describes an example of TCP packet APP detection according to an embodiment of this solution.

[0016] Figure 9 This describes an example of ASN IP detection according to an embodiment of this solution.

[0017] Figure 10 This describes an example of a table with protocol hostname details according to an embodiment of this solution.

[0018] Figure 11 This describes instances of protocol hostnames for different applications according to embodiments of this solution.

[0019] Figure 12 This describes an example of an IP pool database according to an embodiment of this solution.

[0020] Figure 13 An example illustrating the code architecture of an embodiment of this solution.

[0021] Figure 14 This describes one of the supported applications and categories according to an embodiment of this solution.

[0022] Figure 15 This describes instance instructions for detecting applications according to an embodiment of this solution. Detailed Implementation

[0023] This embodiment will now be described in detail with reference to the accompanying drawings, which are provided as illustrative examples of the embodiments to enable those skilled in the art to practice embodiments and alternatives that are obvious to them. The following figures and examples are not intended to limit the scope of this embodiment to a single embodiment, but rather other embodiments are possible by interchangeing some or all of the described or illustrated elements, or elements that are obvious to those skilled in the art. Some elements in this embodiment may be implemented using some or all of known components, and only those portions of such known components necessary for understanding this embodiment should be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the embodiment. The embodiments described in their illustrative context should not be limited thereto. For example, unless otherwise specified herein, as will be apparent to those skilled in the art, embodiments described as implemented in software should not be limited to this embodiment, but may include embodiments implemented in hardware or a combination of software and hardware, and vice versa. In this specification, embodiments showing a single component should not be considered limiting; rather, unless expressly stated otherwise herein, this disclosure is intended to cover other embodiments that include multiple identical components, and vice versa. Furthermore, unless explicitly stated otherwise, the applicant does not wish for any terminology in the specification or claims to be given an unusual or special meaning. Additionally, this embodiment covers current and future known equivalents of the known components mentioned herein by way of description.

[0024] For IP networks, the traditional method for enabling QoS is typically through static network configuration and / or fixed packet labeling by applications that generate IP services. Example IP networks include WiFi networks, DOCSIS access networks, DSL / PON access networks, and core IP networks. Network devices on these networks include wired / DSL / PON modems and residential gateways, IPSTBs, etc.

[0025] This disclosure provides an alternative to conventional methods for QoS enabling, with the following key contributions. For example, the source device (e.g., a SoC) can automatically detect the category of applications that generate IP traffic across an IP network. Detection can be based on multi-stage processing of a set of selected packets associated with an application session. Compared to the typical static “deep packet inspection (DPI)” in conventional QoS systems, the processing of selected packets can rely on a dynamic “shallow packet inspection” process, and is therefore much more computationally efficient. Application categories are categorized for specific QoS requirements, such as low latency, high throughput, and low packet loss.

[0026] The results of application category detection can be used by the source device to dynamically tag (e.g., with DSCP) packets upstream based on the detected application session attributes. The detected application session attributes may include application category, session start / end, bandwidth variations, inter-packet interval statistics, etc. These session attributes are dynamically mapped to packet tags that convey the corresponding QoS requirements. The source device then maps the dynamic tags in upstream packets to appropriate QoS queues for upstream transmission.

[0027] For downstream packets, the source device associates and correlates them with the corresponding upstream packet and applies the corresponding QoS to the receive QoS queue. On the destination device (e.g., SoC) side, the tagged upstream packet can be associated and correlated with the corresponding downstream packet. The associated downstream packet can be tagged with a tag consistent with (e.g., the same) as the upstream packet. The destination device can map the dynamic tags in the downstream packet to the appropriate QoS queue for downstream transmission. The disclosed solution involves detecting application categories to map the detection results to packet tags. Packet tags can exist and be detected in the transmitted packets.

[0028] For example, this solution provides a Quality of Service (QoS) enablement that may involve automatically detecting application categories generating IP traffic in an IP network by utilizing multi-stage processing of selected packets based on a dynamic "shallow packet inspection" procedure. The detected application categories can be categorized to meet specific QoS requirements, such as low latency, high throughput, and low packet loss. The source device can dynamically label packets upstream based on the detected application session attributes, allowing appropriate QoS queue mapping and transmission. Similarly, downstream packets can be associated and linked to corresponding upstream packets, ensuring consistent QoS labeling and downstream queue mapping for efficient downstream transmission at the destination device.

[0029] For example, the solution can provide an automated method to achieve Quality of Service (QoS) in IP networks by detecting the application categories that generate IP traffic. This can be achieved by using a dynamic “shallow packet inspection” technique to process selected packets in a multi-stage process. By classifying the detected application categories, specific QoS requirements, such as low latency, high throughput, and low packet loss, can be addressed. The source device can dynamically tag upstream packets based on the attributes of the detected application sessions, allowing appropriate mapping to QoS queues and efficient transmission in the upstream direction. Furthermore, the solution can correlate and associate downstream packets with their corresponding upstream packets, thereby allowing consistent QoS tagging and appropriate downstream queue mapping at the destination device.

[0030] refer to Figures 1 to 2 IP network Quality of Service (QoS) can be implemented using either SGS or Netify architectures or solutions. SGS can refer to a service gateway system, which may include network infrastructure providing advanced service management and control capabilities, including QoS enforcement, traffic shaping, and policy enforcement. Netify may include network infrastructure utilizing deep packet inspection (DPI) technology to analyze and control network traffic for performance optimization, enhanced security, and improved management capabilities. SGS can use third-party licenses, and application detection can be a small module of SGS. If we only use this module, this approach may be too cumbersome. On the other hand, Netify is available under both commercial and open-source licenses. Both SGS and Netify detect categories by application, which are detected via network packets through hostnames, DNS, protocols, and IP pools. We use the same approach to design our system for detection categories because it is common and effective. It is advanced detection in user space with low CPU load and memory.

[0031] Figure 3 This describes a system 300 that can be used for category detection purposes. The system may include one or more devices configured to communicate via a network (e.g., a wireless network, the Internet) using any number of communication protocols (e.g., TCP / IP, UDP, etc.). The system may include a processor coupled to a memory that can store instructions, commands, computer code, and / or data to implement an apparatus embodiment of this solution.

[0032] Network packets can be input into a category detection procedure that corresponds to or relates to cloud gaming, conferencing, or other applications. Cloud gaming and conferencing can be assigned to or correspond to high-priority queues. Other applications can be assigned to or correspond to normal-priority queues. The system can assign packet priorities based on tags in the data packets.

[0033] The system can detect applications in the data stream from the CPE. Categories can be based on applications. Categories / applications can be reported to other modules. In some instances, supported categories can include conferencing (e.g., video conferencing) applications and gaming applications. This solution can add or support applications by adding application-specific protocols, application hostnames, application IP pools, etc.

[0034] Figure 4 This section illustrates an example of the detection process. A network packet can enter the process module. It can be determined whether it follows a known process. If it does, QoS can proceed to the category module. If it doesn't follow a known process, it can enter packet inspection, where protocol headers can be parsed, ASN lookup can be performed on the packet's IP address, and hostname verification can be completed. Then, it can be determined whether the solution is processing a known application. If it does, the known process can be updated. If it doesn't, routing or implementing a private IP pool can determine if it's a known IP, after which the unknown process can be updated.

[0035] Figure 5 Refer to an example of the application protocol detection layer according to an embodiment of this solution. The system can detect application protocols in the application layer. The application layer may include or support various protocols, such as DNS, SNMP, NFS, HTTP / S, TLS, FTP, and others. The transport layer may support protocols such as TCP or UDP, and the Internet layer may support ICMP, IGMP, or others.

[0036] Figure 6 This section illustrates an example of an application protocol detection process according to an embodiment of this solution. The diagram shows the flow of UDP, TCP, or other packets.

[0037] Figure 7 This describes an example of UDP packet application detection according to an embodiment of this solution. The packet may contain an RTP payload and a video conferencing SFU encapsulation. It may contain an RTP header, a UDP header, and an IP header. Video conferencing applications (e.g., Zoom) can detect the packet from the RTP payload.

[0038] Figure 8 This describes an example of TCP packet application detection according to an embodiment of this solution. The system can detect another video conference (MS Teams) from the TLS handshake protocol header.

[0039] Figure 9 This describes an example of ASN IP detection according to an embodiment of this solution. The system can detect IP addresses from the ASN of a known application. This example relates to another example: a video conferencing application (e.g., Webex).

[0040] Figure 10 This describes an example of a table with protocol hostname details according to an embodiment of this solution. This solution may include, support, process, utilize, or relate to many protocols that have a hostname field in the protocol header.

[0041] Figure 11 This describes examples of protocol hostnames for different applications according to embodiments of this solution. For example, this solution may include instructions, computer code, or data for processing protocol hostnames for Webex and Zoom applications.

[0042] Figure 12 This describes an example of an IP pool database according to an embodiment of this solution. A private IP pool may be provided, containing or relating to an internal extension of APP IP addresses, including known APP IP addresses not in the public ASN and operator-private APPs with known IP addresses.

[0043] Figure 13 An example illustrating the code architecture of an embodiment of this solution.

[0044] Figure 14 This describes one of the supported applications and categories according to an embodiment of this solution. In one instance, this solution may support application detection for conferencing applications (e.g., Zoom, Microsoft Teams, and Webex) and games (e.g., NetEase Cloud Games).

[0045] This solution provides or adds support for more applications. For example, it can define new application categories, add application protocol support, including protocol characteristics, protocol ports, header options, payload identifiers, etc. This solution can define application hostnames as available and application ASNs or IP pools as available.

[0046] Figure 15 This describes example instructions for detecting applications according to embodiments of this solution. This solution may include board IP address 172.18.0.14 for board 3390. View 1502 provides computer code or instructions for detecting Webex video conferencing. View 1504 provides computer code or instructions for detecting Zoom video conferencing. View 1506 provides computer code or instructions for detecting Microsoft Teams video conferencing. View 1508 provides computer code or instructions for detecting NetEase Cloud Gaming.

[0047] The compilation category detection daemon can include git clone ssh: / / gitbsesw@git-bei-01.bji.broadcom.net / rglinux / cdd, git submodule update --init, . / autogen.sh, . / configure and make.

[0048] This solution can add machine learning algorithms (e.g., rule-based) to APP protocol detection.

Claims

1. A method comprising: The first device receives one or more network packets tagged by the second device to identify one or more attributes of the one or more network packets; The receiving device detects the attribute from the one or more network packets; and The receiving device determines the Quality of Service (QoS) configuration of the one or more network packets in response to the detected attributes.

2. The method of claim 1, wherein the one or more attributes indicate an application or session corresponding to the one or more network packets.

3. The method according to claim 1, comprising: Map the session or application attributes to one or more QoS configurations.

4. The method according to claim 1, comprising: Based on the application or session attributes, determine one or more of the following: the start of the session, the end of the session, bandwidth changes, or inter-packet interval statistics.

5. A system comprising: One or more processors coupled to memory and configured to: Receive one or more network packets tagged by a remote device to identify one or more attributes of the one or more network packets; Detect the attribute from one or more network packets; and The Quality of Service (QoS) configuration of the one or more network packets is determined in response to the detected attributes.

Images