Depth packet detection for multicast streams

Abstract

Embodiments of the present disclosure relate to deep packet detection of multicast streams. An access switch is provided that can connect one or more terminal devices to a network. During operation, an access switch may identify a multicast stream associated with a multicast group based on one or more packets received at the access switch. An access switch may store a flow identifier of a multicast flow in an entry of a data structure stored in a storage device of the access switch. The access switch may then facilitate deep packet detection of the multicast flow. To this end, an access switch may determine a set of attributes associated with a multicast flow based on a plurality of packets of a multicast group and determine a multicast traffic category for the multicast flow based on the set of attributes. The access switch may then store a tag identifying a multicast traffic category in an entry of the data structure.

Description

Background Art

[0001] Network devices in a network, such as switches, may support different protocols and services. For example, a network device may support one or more multicast protocols to facilitate the distribution of certain classes of traffic, such as video streaming and online gaming. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An example of a network supporting deep packet inspection of multicast flows according to an aspect of the present application is illustrated.

[0003] Figure 2 An example of a multicast deep packet inspection (MDPI) system that collects information from multicast flows according to an aspect of the present application is illustrated.

[0004] Figure 3A An example of a category data structure based on which the MDPI system classifies multicast flows according to an aspect of the present application is illustrated.

[0005] Figure 3B An example of an overlay category data structure based on which the MDPI system classifies multicast flows in an overlay network according to an aspect of the present application is illustrated.

[0006] Figure 4 A flow chart illustrating an example of a process for a switch to perform deep packet inspection on multicast flows in a network according to an aspect of the present application is presented.

[0007] Figure 5A A flow chart illustrating an example of processing of a switch to classify multicast flows in a network according to an aspect of the present application is presented.

[0008] Figure 5B A flow chart illustrating an example of a process in which a switch selects multicast packets to perform deep packet inspection in accordance with an aspect of the present application is presented.

[0009] Figure 6 An example of a switch supporting deep packet inspection of multicast flows according to an aspect of the present application is illustrated.

[0010] In the drawings, like reference numerals refer to like drawing elements. DETAILED DESCRIPTION

[0011] In various Internet applications, multicast is often used to distribute content such as video from a source to multiple hosts through one or more network devices (e.g., switches). Efficient distribution of multicast traffic can improve the performance of the network. Network layer multicast protocols, such as protocol independent multicast (PIM), can be used to distribute content in heterogeneous networks. In some scenarios, a host can send a client join request (e.g., an Internet Group Management Protocol (IGMP) join request or a Multicast Listener Discovery (MLD) join request) to an upstream switch. The switch can be in an overlay network such as a tunnel structure formed based on overlay routing for VPN on a set of tunnels. For example, Ethernet VPN (EVPN) can be deployed as an overlay layer on a set of virtual extensible LANs (VXLANs).

[0012] In order to allocate bandwidth and resources for multicast traffic in a network, it may be useful to identify different types of multicast traffic flows (or multicast streams) in the network. For example, if a network administrator can identify which switches in a network are forwarding Internet Protocol (IP) television (IPTV) streams, the administrator can allocate resources to the corresponding switches. Typically, switches can perform deep packet inspection (DPI) to collect information about data streams forwarded by the switch. In doing so, the DPI process can detect processing beyond the standard header performed to forward packets. Therefore, the DPI processing method can analyze traffic patterns and payloads (i.e., beyond the data link, IP, and transport headers) to identify the type of traffic and the application associated with the traffic. However, because multicast traffic forwarding can be one-to-many and is typically active (e.g., to a rendezvous point (RP)), traditional DPI processes may not be able to identify corresponding traffic classes in the network and corresponding applications for different multicast streams.

[0013] Various aspects described herein solve the problem of effectively performing DPI on multicast flows in a network by: (i) capturing a set of relevant packets from the multicast flow and analyzing the packets to determine a set of attributes; (ii) comparing the set of attributes to corresponding parameters of a multicast traffic pattern; and (iii) classifying the multicast flow into a corresponding traffic class based on the comparison. By matching the set of attributes to the traffic pattern, the traffic class and the corresponding application can be determined.

[0014] With existing technology, performing DPI on packets involves processing outside of the header of the packet. Typical DPI processes may rely on examining bidirectional flows associated with request and response packets. Because multicast packets are not associated with a specific source-destination pair, there may be no request and response paradigm for multicast streams. Therefore, performing DPI on multicast packets may be challenging. If multicast packets are sent via an overlay tunnel, extracting information from the multicast packets may be even more challenging. In addition, information associated with certain multicast data streams, such as port information, may not be universally defined. As a result, performing traditional DPI on multicast packets may not be able to determine the type of data stream of the multicast packet. Without performing DPI on multicast streams, telemetry data associated with multicast streams may not be collected. Therefore, administrators may not be able to allocate resources accordingly.

[0015] To address this issue, a multicast DPI (MDPI) system capable of performing DPI on multicast streams can be deployed on an access switch. An access switch can be an edge switch in a network that is capable of connecting one or more terminal devices to the network. The MDPI system can maintain a set of traffic categories (e.g., video streaming, monitoring, signaling, etc.) associated with multicast in a category data structure (CDS), such as a table. Each traffic category can represent a corresponding traffic pattern. The CDS can also include a set of parameters (e.g., attribute values) representing each traffic category. In addition, each of these traffic categories can be identified by a corresponding label. If the multicast stream matches the label, the MDPI system can classify the multicast stream using the category associated with the label.

[0016] To find a matching category for a multicast flow, the MDPI system may analyze a set of multicast packets for the multicast flow. For example, when an initial multicast packet is received at a switch, the forwarding hardware of the switch may not find a match. Therefore, the forwarding hardware may promote the packet to a multicast daemon (e.g., a PIM daemon) at the switch that manages the distribution of multicast traffic. Promoting the packet may include providing the packet from the hardware of the switch to the software of the switch (e.g., an operating system) for further processing. When the packet is promoted, the MDPI system may capture a copy of the packet. The MDPI system may then determine from the packet the multicast address of the multicast group and the source address associated with the source of the multicast group. Here, the address may indicate a (source, group) or (S, G) combination representing a multicast flow associated with the packet. The MDPI system may create an entry for the multicast flow in a flow data structure (FDS) by applying a hash function to the (S, G) combination (e.g., to the source and multicast group addresses). The hash function may generate a hash value, which may then be an identifier for the multicast flow.

[0017] The MDPI system may also identify control packets associated with the multicast group, such as IGMP joins, and merge them into a set of multicast packets. In addition, the MDPI system may sample multicast packets from a multicast stream (e.g., using IP Flow Information Export (IPFIX)) and merge the sampled packets into a set of multicast packets. The MDPI system may then perform further analysis on the set of packets and may determine a set of attributes for the multicast stream. These attributes may include interface type, traffic direction, data rate, packet size, and application information. The interface type may include the ingress and egress interface types for the multicast group at the switch (e.g., access, multi-chassis link aggregation group (MC-LAG), etc.). Similarly, the traffic direction may indicate whether the traffic is north-south traffic (e.g., from a server to a client) or east-west traffic (e.g., between terminal devices).

[0018] The MDPI system may then classify the multicast stream by applying a classifier or clustering algorithm on the set of attributes to determine a label for the multicast stream. Classification may include comparing the set of attributes to a set of parameters for a corresponding category in the CDS. If the attributes of the multicast stream match the parameters of the category, the MDPI system may determine a corresponding label from the entry in the CDS. The MDPI system may then assign the label to the multicast stream and store the label in an entry associated with the multicast stream in the FDS. The MDPI system may then present the label to a network management system (NMS), such as a network orchestrator.

[0019] By associating multicast streams with corresponding tags, the MDPI system can effectively perform DPI on multicast streams in the network. After assigning tags to multicast streams, the NMS can determine telemetry data associated with the multicast streams and perform analysis based on the telemetry data. In addition, the NMS can facilitate application-based policies in the network. The policies can be defined based on corresponding combinations of user roles and applications. For example, the NMS can deploy role-based access policies that indicate which user role has a subscription to receive IPTV streams. In addition, the determined telemetry data can be used as input for different artificial intelligence (AI)-based modeling. Based on the tags, the administrator (e.g., via the user interface of the NMS) can configure the network and allocate resources accordingly.

[0020] The network may be an overlay network, such as a distributed tunnel structure, in which switches may be coupled to each other via tunnels. In the structure, tunnel encapsulation starts and terminates within the structure. The structure may be coupled to other networks via a gateway device. The gateway device may be a virtual gateway switch (VGS). Typically, at least two switches may operate in conjunction with each other as a single switch to facilitate the VGS. If the network is an overlay network, the access switch may maintain an overlay CDS (OCDS), which may incorporate parameters associated with the tunnel. For example, the interface type indicated in the OCDS may include a tunnel. Since the MDPI system may be deployed at the access switch, the MDPI system may determine a set of packets for the multicast stream to be analyzed and determine corresponding labels before or after the tunnel encapsulation is applied to the packet.

[0021] In this disclosure, the term "switch" is used in a general sense, and it may refer to any standalone network device or fabric switch operating in any network layer. "Switch" should not be interpreted as limiting examples of the present invention to layer 2 networks. Any device that can forward traffic to an external device or another switch that can be referred to as a "switch". In addition, if a switch facilitates communication between networks, the switch may be referred to as a gateway switch. Any physical or virtual device that can operate as a network device and forward traffic to a terminal device (such as a virtual machine or switch operating on a computing device) may be referred to as a "switch". If the switch is a virtual device, the switch may be referred to as a virtual switch. Examples of "switches" include, but are not limited to, layer 2 switches, layer 3 routers, routing switches, components of a Gen-z network, or a fabric switch that includes multiple similar or heterogeneous smaller physical and / or virtual switches.

[0022] The term "packet" refers to a group of bits that can be transmitted together through a network. "Packet" should not be interpreted as limiting the present invention to a specific layer of the network protocol stack. "Packet" may be replaced by other terms related to a group of bits, such as "message", "frame", "unit", "datagram" or "transaction". In addition, the term "port" may refer to a port that can receive or send data. "Port" may also refer to hardware, software and / or firmware logic that can facilitate the operation of a port.

[0023] Figure 1An example of a network supporting deep packet inspection of multicast streams according to one aspect of the present application is illustrated. Network 100 may include multiple switches and devices, and may include heterogeneous network components, such as layer 2 and layer 3 hops, and tunnels. In some examples, network 100 may be an Ethernet, InfiniBand network, or other network, and may use corresponding communication protocols, such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. Network 100 may include multiple network devices, such as switches 102, 103, 104, and 105. Here, switches 103, 104, and 105 may be access switches, and switch 102 may be a border or gateway switch. Switches 103, 104, and 105 may be access switches because they can facilitate access to network 100 by connecting one or more terminal devices to network 100. The corresponding switches in network 100 may be associated with MAC addresses as well as IP addresses.

[0024] Switches 101, 102, 103, and 104 may be in a distributed tunnel structure 110, and the switches may be coupled to each other via tunnels. In the structure 110, tunnel encapsulation starts and terminates within the structure 110. The switches in the structure 110 may form a mesh of tunnels. Examples of tunnels may include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), Internet Security Protocol (IPsec), and Multi-Protocol Label Switching (MPLS). Tunnels in the structure 110 may be formed on an underlying network (or underlying network). The underlying network may be a physical network, and the corresponding links of the underlying network may be physical links. The corresponding switch pairs in the underlying network may be Border Gateway Protocol (BGP) peers. VPNs, such as EVPN, may be deployed on the structure 110.

[0025] A plurality of terminal devices 116, such as terminal devices 112 and 114, may be coupled to an access switch via one or more hops. In other words, these terminal devices may be coupled to the access switch locally or remotely. For example, terminal device 114 may be coupled to switches 103 and 104 via MC-LAG 130. Here, terminal device 114 may be coupled to switches 103 and 104 via corresponding links. These links may be grouped together to operate as a logical or virtual link represented by MC-LAG 130. In addition, terminal device 112 may be coupled to switch 104 via corresponding links. One or more of these terminal devices may be requesting hosts for multicast group 140. For example, terminal devices 112 and 114 may send corresponding join requests 132 and 134 (e.g., IGMP or MLD join) for multicast group 140. Therefore, terminal devices 112 and 114 may also be referred to as hosts 112 and 114, respectively. Switch 104 may then send a corresponding network join request (eg, a PIM join) to the RP of multicast group 140 .

[0026] Switch 102 may facilitate external communications to switches 103, 104, and 105 via a wide area network (WAN) 120 (e.g., an enterprise network or the Internet). Within network 100, network 120 may be coupled to a source network 160 (e.g., a data center network or a DCN that may facilitate multicast flows for multicast group 140). Network 160 may include an end device 162 that may be a source of multicast group 140. Thus, end device 162 may also be referred to as source 162. Network 160 may include switch 101 that may forward multicast flow 136 from end device 162 to switch 102 via network 120. Switch 102 may then forward multicast flow 136 to end devices 112 and 114 via switch 104.

[0027] In some examples, performing DPI on a packet may include processing in addition to the packet's header. Based on the processing, the DPI process may identify a data flow from a request and its response (e.g., a Hypertext Transfer Protocol (HTTP) request and a corresponding response). DPI may then determine an application and its corresponding traffic class (e.g., network traffic) from the data flow. However, even when multicast packets in multicast stream 136 are processed outside of the packet's multicast header, the application and traffic class associated with the data flow may not be determined.

[0028] In particular, the multicast packets in the multicast stream 136 may be distributed to all requesting hosts, such as the terminal devices 112 and 114. In addition, another terminal device 164 may also serve as a source for the multicast group 140. As a result, at least a portion of the multicast stream 136 may also be sent from the terminal device 164. Therefore, the multicast stream 136 may not be associated with a specific source-destination pair. In addition, different types of applications may generate multicast traffic. As a result, identifying the multicast stream group may not be sufficient to determine the traffic class associated with the application and the multicast group.

[0029] When the multicast stream 136 is sent via a tunnel in the structure 110, extracting information from the multicast packets may be more challenging. Because the packets of the multicast stream 136 may be encapsulated with a corresponding tunnel header, the DPI process may not identify the multicast stream and its traffic class associated with the multicast stream 136. In addition, information associated with the multicast stream 136, such as port information, may not be universally defined. As a result, performing traditional DPI on the multicast stream 136 may not be able to determine the traffic class. Without performing DPI on the multicast stream, telemetry data associated with the multicast stream may not be collected in the network 100. Therefore, an administrator may not be able to allocate resources accordingly.

[0030] To address this problem, an MDPI system 150 capable of performing DPI on multicast streams 136 can be deployed on access switches 103, 104, and 105. The MDPI system 150 can maintain a known set of traffic categories in CDS 172. Each traffic category can represent a corresponding traffic pattern. Examples of traffic categories may include, but are not limited to, ultra-high definition (UHD) video streams, high definition (HD) video streams (e.g., HDIPTV, video on demand (VoD), and online games), standard definition (SD) video streams (e.g., SDIPTV), closed-circuit television (CCTV), and low-resolution (LD) CCTV or control traffic. CDS 172 may also include a set of parameters (e.g., attribute values) representing each traffic category. In addition, each of these categories may be identified by a corresponding label. If the multicast stream 136 matches a label, the MDPI system 150 can obtain the label from CDS 172 and classify the multicast stream 136 using the category associated with the label.

[0031] CDS172 may indicate that the packet rate for the video stream may be medium to high. The multicast stream associated with the video stream may be a north-south stream. For the video stream, a join request from a requesting host is sent to an access port, while the multicast stream may be received from an uplink switch (e.g., an uplink LAG). On the other hand, CDS172 may indicate that the packet rate for the CCTV stream may be medium. CCTV streams may typically be south-north streams to upstream servers (e.g., from a data center). For example, a CCTV stream may arrive at the switch 104 via an access port and be forwarded to an uplink port. In addition, CDS172 may indicate that the control packet may be a low-rate packet belonging to an east-west stream between access switches.

[0032] The MDPI system 150 running on the switch 104 can analyze the set of packets for the multicast group 140 to classify the multicast stream 136. When the MDPI system 150 receives an initial multicast packet for the multicast stream 136, the MDPI system 150 can determine the source address (e.g., the IP address of the terminal device 162) and the multicast address of the multicast group 140 from the multicast packet. Therefore, the initial multicast packet for the multicast stream 136 can be included in the set of packets. The source and multicast address indicate the (S, G) combination representing the multicast stream 136. Therefore, the MDPI system 150 can identify the multicast stream 136 based on the (S, G) combination. The MDPI system 150 can then apply a hash function to the (source, group) combination to determine an entry for the multicast stream 136 in the FDS 170 of the switch 104. The hash function can generate a flow identifier for the multicast stream 136. The flow identifier can be used as an index to the entry in the FDS 170. By performing this operation for each multicast flow forwarded through switch 104 , MDPI system 150 may build a cache of multicast flows in FDS 170 .

[0033] MDPI system 150 may also merge join requests 132 and 134 into the set of packets. In addition, MDPI system 150 may sample multicast packets based on a sampling rate from multicast stream 136. Sampling may select every nth packet of multicast stream 136 to obtain sampled multicast packet 138. MDPI system 150 may also use a sampling mechanism, such as IPFIX or NetFlow, to sample from multicast stream 136 to determine multicast packet 138. MDPI system 150 may then merge multicast packet 138 into the set of packets. In this way, MDPI system 150 may select packets of multicast stream 136 to perform DPI.

[0034] Therefore, the MDPI system 150 can perform further analysis on the set of packets and can determine a set of attributes for the multicast stream 136. Examples of attributes can include, but are not limited to, interface type, traffic direction, data rate, packet size, and application information. For example, the MDPI system 150 can determine that the switch 104 can forward the multicast stream 136 to the terminal device 112 via an access port and to the terminal device 114 via the MC-LAG 130 based on the interfaces of the join requests 132 and 134. The MDPI system 150 can then use a classifier or clustering algorithm to compare the set of attributes to a set of parameters for each traffic class in the CDS 172. If the set of attributes corresponds to a set of parameters for the traffic class, the MDPI system 150 can assign a corresponding label to the multicast stream 136. The MDPI system 150 can include the label in a corresponding entry in the FDS 170.

[0035] By associating the multicast stream 136 with the corresponding tag, the MDPI system 150 can effectively perform DPI on the multicast stream 136. The MDPI system 150 can then present the tag to the NMS 180. The administrator can use the NMS 180 to configure and provision the corresponding network devices in the network 100. After assigning the tag to the multicast stream, the NMS 180 can determine the telemetry data associated with the multicast stream and perform analysis based on the telemetry data. The determined telemetry data can be used as input to different AI-based modeling. The NMS 180 can also facilitate application-based policies in the network, which can be defined based on user roles and corresponding combinations of applications. In addition, based on the tag, the administrator (e.g., via the user interface of the NMS 180) can configure the network 100 and allocate resources accordingly. For example, if the multicast stream 136 corresponds to a video stream, the policy defined in the network 100 can indicate whether the terminal devices 112 and 114 have a subscription to receive the video stream. The administrator may also configure switches 102 and 104 to reduce latency of multicast stream 136 and ensure better viewing at end devices 112 and 114 .

[0036] In the structure 110, the switch 104 may also maintain an OCDS 174, which may incorporate parameters associated with the tunnel. For example, the interface type indicated in the OCDS 174 may include a tunnel. Since the MDPI system 150 may be deployed at the access switches 103, 104, and 105, the MDPI system 150 may determine a set of packets of the multicast stream 136 for analysis and determine corresponding labels before or after the tunnel encapsulation is applied to the packets. For example, upon receiving the join requests 132 and 134, the switch 104 may perform analysis on the join requests 132 and 134 before encapsulating them with corresponding tunnel headers. On the other hand, the switch 104 may decapsulate the corresponding tunnel headers of the packets of the multicast stream 136. The MDPI system 150 may perform sampling on the decapsulated packets of the multicast stream 136 and select the multicast packet 138. Therefore, the MDPI system 150 may be deployed in the structure to perform DPI on the multicast packets.

[0037] Figure 2 An example of an MDPI system collecting information from a multicast stream according to an aspect of the present application is illustrated. Switch 202, which may be an access switch in network 200, may deploy MDPI system 250. Terminal device 206 may be coupled to switch 202 via an access port of switch 202. Terminal device 206 may be interested in receiving multicast traffic of multicast group 230. Therefore, terminal device 206 may send a join request (e.g., IGMP or MLD join) of multicast group 230 to switch 202. In turn, switch 202 may send a network join request (e.g., PIM join) of multicast group 230 to the RP of multicast group 230. Terminal device 204 may be the source of multicast group 230 in network 200. When terminal device 204 becomes aware of the network join from switch 202, terminal device 204 may send a multicast stream 236 including multicast packets (i.e., data packets) of multicast group 230 to switch 202.

[0038] During operation, switch 202 may receive an initial multicast packet 234 of a multicast stream 236. When switch 202 receives packet 234, forwarding hardware 210 of switch 202 may not find a match in a forwarding data structure (e.g., in a content addressable memory or CAM). Therefore, forwarding hardware 210 may promote packet 234 to a multicast daemon 220 (e.g., a PIM daemon) that manages the distribution of multicast traffic at switch 202. Promoting packet 234 may include providing it from forwarding hardware 210 to software of switch 202 (e.g., an operating system running multicast daemon 220) for further processing. When packet 234 is promoted, MDPI system 250 may capture a copy of packet 234. Analyzer 252 may then determine a multicast address 274 of multicast group 230 and a source address 272 associated with source 204 based on packet 234. Here, addresses 272 and 274 may indicate a (S, G) combination of multicast stream 236 representing multicast group 230. MDPI system 250 may create an entry in FDS 260 for multicast stream 236 by applying a hash function to the (S, G) combination (eg, to addresses 272 and 274).

[0039] MDPI system 250 may also identify control packets associated with multicast group 230, such as control packet 232. End device 206 may send control packet 232 to switch 202. Control packet 232 may be an IGMP or MLD join request from multicast group 230. When multicast daemon 220 processes control packet 232, MDPI system 250 may capture a copy of packet 232. Analyzer 252 may perform further analysis on packet 232 and identify the port to which end device 206 (i.e., requesting host) is coupled. Analyzer 252 may also determine the amount of replication and direction of multicast stream 236.

[0040] In addition, the MDPI system 250 can sample multicast packets from the multicast stream 236 (e.g., using a data sampler 240 such as IPFIX) and analyze the sampled packets 238. The analyzer 252 can determine packet and byte counter values ​​from the sampled packets 238. In this way, the MDPI system 250 can perform further analysis on the packets 232, 234, and 238, and can determine a set of attributes 242 for the multicast stream 236. The attributes 242 can include interface type, traffic direction, data rate, packet size, application information. The interface type can include the ingress and egress interface types (e.g., access, MC-LAG, etc.) of the multicast group 230 at the switch 202. Similarly, the traffic direction can indicate whether the traffic of the multicast stream 236 is north-south traffic or east-west traffic.

[0041] The MDPI system 250 may then classify the multicast stream 236 to determine a label 244 for the multicast stream 236. To do so, the MDPI system 250 may apply a classifier 254 on the attribute 242. The classification may include comparing the attribute 242 to a set of parameters in the CDS 262 for a corresponding traffic class. If the attribute 242 matches the parameters of the class in the FDS 260, the MDPI system 250 may determine the label 244 from the corresponding entry in the CDS 262. The MDPI system 250 may then assign the label 244 to the multicast stream 236 and store the label 244 in an entry in the FDS 260 associated with the multicast stream 236. The MDPI system 250 may then present the label 244 to the NMS 280. If the network 200 is an overlay network, the switch 202 may maintain an OCDS 264, which may incorporate parameters associated with a tunnel. Since the switch 202 may be an access switch, the MDPI system 250 may determine the label 244 before applying the tunnel encapsulation to the packet. By associating multicast streams 236 with corresponding tags 244, the MDPI system can effectively perform DPI on the multicast streams in the network.

[0042] Figure 3A An example of a category data structure according to one aspect of the present application is illustrated, based on which the MDPI system classifies multicast flows. CDS 300 may include a set of parameters for multiple predetermined traffic categories. To represent the parameters, CDS 300 may include interface 302, traffic direction 304, rate range 306, packet size 308, application data 310, the presence of other parameters 312, labels 314, and accuracy score 316. Accuracy score 316 may be an optional field (indicated by a dashed line). If the multicast flow is a north-south flow from an uplink LAG to an access port, other parameters (e.g., IGMP join) are present, the packet size is large, and the application data is carried by the real-time transport protocol (RTP) over the user datagram protocol (UDP), the CDS 300 may include a label for a video flow. In other words, such a multicast flow may be classified as a video flow.

[0043] If the data rate of the video stream is within the range of [X1, Y1] (e.g., 50 Mbps - 300 Mbps), the label of the corresponding entry can be a UHD video stream. On the other hand, if the data rate is within the range of [X2, Y2] (e.g., 30 Mbps - 50 Mbps), the label can be an HD video stream. Similarly, if the data rate is less than Y3 (e.g., < 10 Mbps), the label can be an SD video stream. The application data for the SD video stream can also indicate a Moving Picture Experts Group (MPEG) stream. In addition, if the multicast stream is a north - south stream from the access port to the uplink LAG, there are other parameters, the packet size is medium, the data rate is within the range of [X4, Y4] (e.g., 5 Mbps - 10 Mbps), and CDS 300 can include a label for Closed - Circuit Television (CCTV). Since such a multicast stream can be encrypted, the application data may not be available.

[0044] Additionally, if the multicast stream is an east - west stream between access ports, there are other parameters, the packet size is medium, the data rate is low (e.g., < Y5), and CDS 300 can include a label for low - resolution (LD) CCTV or a control stream. For example, if the application data indicates the Simple Service Discovery Protocol (SSDP), Domain Name System (DNS), or Precision Time Protocol (PTP), the label can be a control stream. Otherwise, the label can be LD CCTV. If the attributes of the multicast stream match the parameters of an entry in CDS 300, the corresponding label is assigned to the multicast stream. The accuracy score 316 can indicate how well the multicast stream matches the corresponding traffic class. Separately, the accuracy score 316 can be for UHD video stream, HD video stream, SD video stream, CCTV, and LD CCTV, or the control stream can be N1, N2, N3, N4, and N5. These scores can be improved with more classes.

[0045] Figure 3B An example of a coverage class data structure according to an aspect of the present application is illustrated, based on which the MDPI system classifies multicast streams in the overlay network. OCDS 350 can include a set of parameters for multiple predetermined traffic classes in the overlay network. To represent the parameters, CDS 350 can include the presence of an interface 352, traffic direction 354, rate range 356, packet size 358, application data 360, other parameters 362, label 364, and accuracy score 366. The accuracy score 366 can be an optional field (shown as a dashed line). If the multicast stream is a north - south stream from the tunnel to the access port, there are other parameters, the packet size is large, and the application data is carried by RTP over UDP, CDS 350 can include a label for a video stream.

[0046] If the data rate of the video stream is within the range of [X1, Y1], the label for the corresponding entry can be a UHD video stream. On the other hand, if the data rate is within the range of [X2, Y2], the label can be an HD video stream. Similarly, if the data rate is less than Y3, the label can be an SD video stream. The application data for the SD video stream can also indicate an MPEG stream. Additionally, if the multicast stream is a south-north flow from an access port to a tunnel, there are other parameters, the packet size is medium, the data rate is within the range of [X4, Y4], and the CDS 350 can include a label for CCTV. Since such a multicast stream can be encrypted, the application data may not be available.

[0047] In addition, if the multicast stream is a south-north flow from an access port to a tunnel, there are other parameters, the packet size is medium, and it has a low data rate (e.g., <Y5), the CDS 350 can include a label for LDCCTV or a control flow. For example, if the application data indicates SSDP, DNS, or PTP, the label can be a control flow. Otherwise, the label can be LDCCTV. If the attributes of the multicast stream match the parameters of the entry in the CDS 350, the corresponding label is assigned to the multicast stream. The accuracy score 366 can indicate how well the multicast stream matches the corresponding traffic class. The accuracy score 366 can be for a UHD video stream, an HD video stream, an SD video stream, CCTV, and LDCCTV, or the control flow can be M1, M2, M3, M4, and M5 respectively. These scores can increase with more classes.

[0048] Figure 4 A flowchart is presented that illustrates an example of a process in which a switch in a network performs deep packet inspection on a multicast stream according to an aspect of the present application. During operation, the switch can connect one or more terminal devices in the network (operation 402). Since the switch is connected to the terminal devices, the switch can be an access switch. Then, the switch can deploy an MDPI system and perform DPI on the multicast stream in the network. To do this, the switch can identify the multicast stream associated with the multicast group based on one or more packets received at the local switch (operation 404). The one or more packets can include the initial multicast packet (i.e., the initial data packet) of the multicast stream received at the switch.

[0049] The switch may then identify the source of the multicast group associated with the multicast flow (operation 406). The switch may then apply a hash function to the respective addresses of the multicast group and the source to determine an entry in a data structure (e.g., an FDS) (operation 408). Here, the hash function may generate a hash value. The switch may then identify the entry (i.e., the location in the data structure) based on the hash value. Subsequently, the switch may store the flow identifier of the multicast flow in the entry of the data structure stored by a storage device of the switch (operation 410). The hash value generated by the hash function may be the flow identifier.

[0050] The switch may then facilitate DPI for the multicast stream (operation 412). To facilitate DPI, the switch may determine a set of attributes associated with the multicast stream based on a plurality of packets of the multicast group (operation 414). The plurality of packets may include an initial packet of the multicast stream, a control packet of the multicast group (e.g., a join request), and a packet sampled from the multicast stream. The switch may also maintain a set of multicast traffic classes, each of which indicates a multicast traffic pattern (e.g., in a CDS or OCDS) (operation 416). These traffic classes may be defined based on typical applications such as IPTV, CCTV, online gaming, and control traffic. The traffic pattern of each traffic class may be represented by a set of parameters. For example, if the parameters indicate a north-south flow with a high data rate and a large packet size, and the application data is carried by RTP over UDP, the corresponding traffic class may be a UHD or HD video stream.

[0051] The switch may determine a multicast traffic class for the multicast flow based on the set of attributes (operation 418). The switch may compare the set of attributes to a set of parameters for a corresponding traffic class, and determine the traffic class based on a match. The matching traffic class may be associated with a tag. The switch may then store the tag identifying the multicast traffic class in an entry of a data structure (operation 420). The switch may then perform network enhancement for the multicast flow based on the tag (operation 422). Examples of network enhancement may include, but are not limited to, implementing a role-based access policy indicating which user role has permission to receive the multicast flow, and applying a set of configurations associated with the traffic class at the local switch.

[0052] Figure 5AA flow chart illustrating an example of processing of a switch for classifying multicast flows in a network according to an aspect of the present application is presented. During operation, the switch may maintain a set of multicast traffic classes, each of which may be associated with a set of parameters indicating a corresponding multicast traffic pattern (operation 502). The switch may apply a classification mechanism to the set of attributes by matching the set of parameters with the set of attributes (operation 504). The matching may include comparing the set of attributes with a corresponding set of parameters for an individual traffic class. The switch may then determine a multicast traffic class for the multicast flow based on the application of the classification mechanism (operation 506). In other words, the classification mechanism may classify the multicast flow into a multicast traffic class whose parameters match the attributes of the multicast flow.

[0053] Figure 5B A flow chart illustrating an example of a process for a switch to select a multicast packet to perform deep packet inspection according to an aspect of the present application is presented. During operation, the switch may identify a control packet to a multicast group and merge the control packet into multiple multicast packets of the multicast group (operation 552). Here, the switch may perform DPI based on multiple multicast packets. The switch may also determine whether an initial multicast packet of a multicast stream is promoted to a multicast daemon of the switch (operation 554). Since the forwarding hardware of the switch may not find a match for the initial multicast packet, the forwarding hardware may promote the initial multicast packet to the multicast daemon. Promoting the packet may include providing the packet from the hardware of the switch to the software (e.g., an operating system) of the switch for further processing.

[0054] Before the initial multicast packet is promoted to the multicast daemon, the switch may continue to check the initial multicast packet of the multicast stream promoted to the multicast daemon of the switch (operation 554). On the other hand, if the initial multicast packet is promoted to the multicast daemon, the switch may merge the initial multicast packet into multiple packets of the multicast group (operation 556). The switch may identify the multicast stream based on the initial multicast packet. In addition, the initial multicast packet may trigger a DPI process for the multicast stream. Therefore, the switch may apply a packet sampling mechanism (e.g., IPFIX) to the multicast stream to select a subset of multiple packets of the multicast group (operation 558).

[0055] Figure 6An example of a switch supporting deep packet inspection of multicast streams according to an aspect of the present application is illustrated. In this example, a switch 600, which may also be referred to as switch 600, may include multiple communication ports 602, a packet processor 610, and a persistent storage device 650. The switch 600 may also include forwarding hardware 660 (e.g., processing hardware of the switch 600, such as a processing hardware application specific integrated circuit (ASIC) chip), which includes information based on which the switch 600 processes the packet (e.g., determines the output port of the packet). The packet processor 610 can extract and process header information from the received packet. The packet processor 610 can identify a network device identifier (e.g., a MAC address and / or an IP address) associated with the switch 600 in the header of the packet. The switch 600 may include a storage medium 620. In some examples, the storage medium 620 may include a set of volatile memory devices (e.g., dual in-line memory modules (DIMMs)).

[0056] The communication port 602 may include an inter-device communication channel for communicating with other network devices and / or user equipment. The communication channel may be realized via a conventional communication port and based on any open or proprietary format. The communication port 602 may include one or more Ethernet ports that can receive a frame encapsulated in an Ethernet header. The communication port 602 may also include one or more IP ports that can receive IP packets. The IP port can receive IP packets and can be configured using an IP address. The packet processor 610 may process Ethernet frames and / or IP packets. The corresponding ports of the communication port 602 may be used as an inlet port and / or an outlet port.

[0057] The switch 600 may maintain a database 652 (e.g., in a storage device 650). The database 652 may be a relational database and may run on one or more database management system (DBMS) instances. The database 652 may store information associated with the routing, configuration, and interfaces of the switch 600. The database 652 may store the FDS, CDS, and OCDS for the switch 600. The storage medium 620 may include instructions associated with a tunnel system 640. The tunnel system 640 may allow the switch 600 to operate as a tunnel endpoint in a tunnel structure. To this end, the tunnel system 640 may establish tunnels with one or more remote switches. The storage medium 620 may include instructions associated with an MDPI system 630 that may allow the switch 600 to efficiently forward bidirectional multicast traffic.

[0058] The MDPI system 630 may include an identification subsystem 632, an analysis subsystem 634, and a classifier subsystem 636. The identification subsystem 632 may identify a multicast flow associated with a multicast group based on one or more packets received at the switch 600. The one or more packets may include an initial multicast packet (i.e., an initial data packet) of the multicast flow received at the switch 600. The identification subsystem 632 may also identify a source of a multicast group associated with the multicast flow and apply a hash function to the respective addresses of the multicast group and the source to determine an entry in the FDS.

[0059] The analysis subsystem 634 may determine a set of attributes associated with the multicast flow based on a plurality of packets of the multicast group. The plurality of packets may include an initial packet of the multicast flow, a control packet of the multicast group, such as a join request, and packets sampled from the multicast flow. Subsequently, the classifier subsystem 636 may determine a multicast traffic class for the multicast flow based on the set of attributes. The classifier subsystem 636 may compare the set of attributes to a set of parameters for a corresponding traffic class and determine the traffic class based on a match. The matched traffic class may be associated with a label. The classifier subsystem 636 may then store the label identifying the multicast traffic class in an entry of the FDS.

[0060] The description herein is presented to enable any person skilled in the art to make and use the present invention, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the present invention. Therefore, the present invention is not limited to the examples shown, but conforms to the widest scope consistent with the claims.

[0061] One aspect of the present technology may provide an access switch that can connect one or more terminal devices to a network. During operation, the access switch may associate a multicast stream with a multicast group based on one or more packet identifiers received at the access switch. The access switch may store a stream identifier of the multicast stream in an entry of a data structure stored in a storage device of the access switch. Subsequently, the access switch may facilitate deep packet inspection of the multicast stream. To this end, the access switch may determine a set of attributes associated with the multicast stream based on a plurality of packets of the multicast group and determine a multicast traffic class for the multicast stream based on the set of attributes. The access switch may then store a label identifying the multicast traffic class in an entry of the data structure.

[0062] In variations of this aspect, the multicast flow may be further associated with a source of the multicast group.The access switch may then apply a hash function to the respective addresses of the multicast group and the source to determine an entry in the data structure.

[0063] In a variation of this aspect, the access switch can maintain a set of multicast traffic classes. Here, each multicast class indicates a multicast traffic pattern. The access switch can then apply a classification mechanism to the set of attributes to determine a multicast traffic class for a multicast flow.

[0064] In a further variation, each multicast traffic class may correspond to a set of parameters indicative of a corresponding traffic pattern. The access switch may then apply a classification mechanism to the set of attributes by matching the set of parameters.

[0065] In a variation of this aspect, the set of attributes for the multicast stream includes one or more of: interface type, traffic direction, data rate, packet size, and application information associated with the multicast stream, and interface types include: routing interface, link aggregation group (LAG), and tunnel interface.

[0066] In a variation on this aspect, the access switch may apply a packet sampling mechanism to the multicast flow to select a subset of the plurality of packets of the multicast group.

[0067] In a variation of this aspect, the network may be an overlay network. The plurality of packets of the multicast group may then be received from a tunnel of the overlay network or the plurality of packets of the multicast group may go to a tunnel of the overlay network.

[0068] In variations of this aspect, the one or more packets include control and data packets associated with the multicast group.

[0069] In a variation of this aspect, the access switch may perform one or more network enhancements based on the tag. The network enhancement may include implementing a role-based access policy that indicates which user roles have permission to receive the multicast stream. The network enhancement may also include applying a configuration set associated with the multicast traffic class at the access switch.

[0070] In a variation of this aspect, the access switch can identify a multicast flow associated with the multicast group from the switch's forwarding hardware by receiving an initial multicast packet for the multicast flow and determining to provide the initial multicast packet to a multicast daemon of the access switch. The access switch can then determine an address associated with the multicast flow from the initial multicast packet.

[0071] The data structures and codes described in this detailed description are generally stored in computer-readable storage media, which can be any device or medium for storing code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as magnetic disks, tapes, CDs (compact disks), DVDs (digital versatile disks or digital video disks), or other media known or later developed that are capable of storing computer-readable media.

[0072] The methods and processes described in the specific embodiments section may be embodied as code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on a computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and code and stored in the computer-readable storage medium.

[0073] The methods and processes described herein may be performed by and / or included in hardware logic blocks or devices. These logic blocks or devices may include, but are not limited to, application specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), dedicated or shared processors that execute a specific software logic block or piece of code at a specific time, and / or other programmable logic devices now known or later developed. When the hardware logic blocks or devices are activated, they perform the methods and processes included therein.

[0074] The foregoing description of examples of the present invention is for the purpose of description and illustration only. They are not intended to be exhaustive or to limit the present disclosure. Therefore, many modifications and variations will be apparent to those skilled in the art. The scope of the present invention is defined by the appended claims.

Claims

1. A method comprising: identifying, by an access switch in a network, a multicast flow associated with a multicast group based on one or more packets received at the access switch, wherein the corresponding access switch connects one or more terminal devices to the network; storing a flow identifier of the multicast flow in an entry of a data structure stored in a storage device of the access switch; Deep packet inspection of the multicast stream is facilitated by: determining a set of attributes associated with the multicast flow based on a plurality of packets of the multicast group; as well as determining a multicast traffic class for the multicast flow based on the set of attributes; as well as A label identifying the multicast traffic class is stored in the entry of the data structure.

2. The method of claim 1, wherein the multicast stream is further associated with a source of the multicast group; and The method further includes applying, by the access switch, a hash function to the respective addresses of the multicast group and the source to determine the entry in the data structure.

3. The method according to claim 1, further comprising: maintaining, by the access switch, a set of multicast traffic classes, wherein each multicast class indicates a multicast traffic pattern; as well as A classification mechanism is applied by the access switch to the set of attributes to determine the multicast traffic class for the multicast flow.

4. The method of claim 3, wherein each multicast traffic class corresponds to a set of parameters indicating a corresponding traffic pattern; and Wherein applying the classification mechanism further comprises matching the parameter set with the attribute set.

5. The method of claim 1 , wherein the set of attributes of the multicast stream comprises one or more of: an interface type, a traffic direction, a data rate, a packet size, and application information associated with the multicast stream, and wherein the interface type comprises: Routing interfaces, link aggregation groups (LAGs), and tunnel interfaces.

6. The method of claim 1, further comprising using, by the access switch, a packet sampling mechanism for the multicast flow to select a subset of the plurality of packets for the multicast group.

7. The method of claim 1, wherein the network is an overlay network, and wherein the plurality of packets of the multicast group are received from or destined for a tunnel of the overlay network.

8. The method of claim 1, wherein the one or more packets include control and data packets associated with the multicast group.

9. The method of claim 1 , further comprising performing network enhancement based on the tag by one or more of: implementing a role-based access policy indicating which user roles have permission to receive the multicast stream; and A configuration set associated with the multicast traffic class is applied at the access switch.

10. The method of claim 1, wherein identifying the multicast stream associated with the multicast group further comprises: receiving an initial multicast packet of the multicast flow; determining that the initial multicast packet is provided from forwarding hardware of the switch to a multicast daemon of the access switch; as well as An address associated with the multicast flow is determined from the initial multicast packet.

11. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of an access switch in a network, cause the processor to perform a method comprising: identifying a multicast flow associated with a multicast group based on one or more packets received at the access switch, wherein the corresponding access switch connects one or more terminal devices to the network; storing a flow identifier of the multicast flow in an entry of a data structure stored in a storage device of the access switch; Deep packet inspection of the multicast stream is facilitated by: determining a set of attributes associated with the multicast flow based on a plurality of packets of the multicast group; as well as determining a multicast traffic class for the multicast flow based on the set of attributes; as well as A label identifying the multicast traffic class is stored in the entry of the data structure.

12. The non-transitory computer-readable storage medium of claim 11, wherein the multicast stream is further associated with a source of the multicast group; The method further comprises applying a hash function to the respective addresses of the multicast group and the source to determine an entry in the data structure.

13. The non-transitory computer-readable storage medium of claim 11, wherein the method further comprises: maintaining, by the access switch, a set of multicast traffic classes, wherein each multicast class indicates a multicast traffic pattern; as well as A classification mechanism is applied by the access switch to the set of attributes to determine the multicast traffic class for the multicast flow.

14. The non-transitory computer-readable storage medium of claim 13, wherein each multicast traffic class corresponds to a set of parameters indicating a corresponding traffic pattern; and Wherein applying the classification mechanism further comprises matching the parameter set with the attribute set.

15. The non-transitory computer-readable storage medium of claim 11, wherein the set of attributes of the multicast flow comprises one or more of: an interface type, a traffic direction, a data rate, a packet size, and application information associated with the multicast flow, and wherein the interface type comprises: Routing interfaces, link aggregation groups (LAGs), and tunnel interfaces.

16. The non-transitory computer-readable storage medium of claim 11, wherein the method further comprises applying a packet sampling mechanism to the multicast flow to select a subset of the plurality of packets of the multicast group.

17. The non-transitory computer-readable storage medium of claim 11, wherein the network is an overlay network, and wherein the plurality of packets of the multicast group are received from or destined for a tunnel of the overlay network.

18. The non-transitory computer-readable storage medium of claim 11, further comprising performing network enhancement based on the tag by one or more of: implementing a role-based access policy indicating which user roles have permission to receive the multicast stream; and A configuration set associated with the multicast traffic class is applied at the access switch.

19. The non-transitory computer-readable storage medium of claim 11, wherein identifying the multicast stream associated with the multicast group further comprises: receiving an initial multicast packet of the multicast flow; determining that the initial multicast packet is provided from forwarding hardware of the switch to a multicast daemon of the access switch; as well as An address associated with the multicast flow is determined from the initial multicast packet.

20. A computer system comprising: Processing resources; Storage devices; as well as A non-transitory machine-readable medium comprising instructions executable by the processing resource to: Connect one or more terminal devices to a network; identifying a multicast flow associated with a multicast group based on one or more packets received at the computer system; storing a stream identifier of the multicast stream in an entry of a data structure stored in the storage device; Deep packet inspection of the multicast stream is facilitated by: determining a set of attributes associated with the multicast flow based on a plurality of packets of the multicast group; as well as determining a multicast traffic class for the multicast flow based on the set of attributes; as well as A label identifying the multicast traffic class is stored in the entry of the data structure.

Images