Automatic dynamic determination of data traffic sampling policy in a network visibility appliance

A network visibility appliance automatically and dynamically determines a data traffic sampling policy that it should apply, i.e., a policy for determining which flows the network appliance should forward to one or more tools. The technique can be used to adjust for changes in network traffic to avoid exceeding performance constraints (e.g., maximum throughput) of network analytic tools, while maintaining high efficiency of usage of the tools. In the technique, a policy engine monitors network traffic characteristics in a subscriber throughput table and dynamically determines a sampling policy to apply, so as to decrease and/or increase traffic throughput to a given tool, so that the tool is efficiently used.

FIELD

At least one embodiment of the present disclosure pertains to network visibility technology, and more particularly, to a technique for automatically and dynamically determining a data traffic sampling policy in a network visibility appliance.

BACKGROUND

With the amounts of data traffic on modern computer networks continually increasing, network monitoring and security measures play an increasingly important role in reducing the vulnerability of a network to intrusion, unauthorized access and other security or performance issues. Various types of tools can be deployed in a computer network that process the network traffic and provide monitoring and security services. Examples of such tools include an intrusion detection system (IDS), an intrusion prevention system (IPS), a packet sniffer, a network monitoring system, an application monitoring system, an intrusion detection system, a forensic storage system, and an application security system, among others.

Tools deployed in a network environment are only effective to the extent that the relevant network traffic is visible to them. Existing approaches to making network traffic visible to such tools include connecting one or more network appliances (traffic visibility appliances) to the network and to the tools. In an in-line deployment, packets originating from a source node on a computer network are received by the network appliance, then routed by the network appliance through one or more tools (which are usually but not necessarily directly connected to the network appliance) and back to the network appliance; the packets are then forwarded by the network appliance to the intended destination node. In contrast, in an out-of-band deployment, copies of packets originating from a source node are made by the network appliance and routed to one or more tools, while the original packets are forwarded by the network appliance to the intended destination node.

In some instances the tools may not have the capacity to examine all of the flows received by the network appliance, such as during periods of heavy network traffic. In this application, a “flow” or “traffic flow” is defined as a series of packets between a source and a destination within the same transport connection. Packets of a single flow share some set of characteristics or fields, such as source IP address, IP destination address, L4 port source, L4 port destination, and protocol. For example, if two packets contain the exact same values for all five of the above-mentioned fields (5-tuple), then the two packets are considered to be part of the same flow. Since the tools may not have the capacity to examine all of the flows received by the network appliance, the network appliance may “sample” the flows for purposes of forwarding them to the tool; that is, the network appliance may forward some of the flows (the “sampled” flows) that it receives, but not all of them, to the tool, to avoid exceeding the performance limits of the tool. In conventional deployments, sampling is a performed according to a manually defined sampling policy. Such a sampling policy is static, i.e., it remains the same regardless of changes in the network traffic. This leads to inefficient utilization of the tool's capacity, since sampling policies are defined conservatively to avoid exceeding a tool's maximum throughput, which this results in significant capacity of a tool not being used during times of lower network traffic. It also requires significant time and effort by human network administrators to manually update sampling policies that are considered suboptimal.

DETAILED DESCRIPTION

Introduced here is a technique by which a network visibility appliance can automatically and dynamically determine a data traffic sampling policy that it should apply, i.e., a policy for determining which flows the network appliance should forward to one or more tools. The technique can be useful particularly, though not only, in the infrastructure portion of a wireless telecommunications network. The technique can be used to adjust for changes in network traffic to avoid exceeding performance constraints (e.g., maximum throughput) of network analytic tools, while maintaining high efficiency of usage of the tools. For example, in this technique, a policy engine constantly monitors network traffic characteristics in a subscriber throughput table and dynamically determines a sampling policy to apply, so as to decrease and/or increase traffic throughput to a given tool, so that the tool is always efficiently used.

One scenario in which a network visibility appliance can be useful is in the infrastructure portion of a wireless telecommunications network. The infrastructure portion of a wireless telecommunications network is the wired portion of the wireless operator's network and is sometimes called the terrestrial radio access network (TRAN), or the wireless operator's “core network.” A wireless operator can deploy one or more network visibility appliances in their TRAN, such as in a 4G/LTE or 5G telecommunications network, to allow various tools to monitor and/or affect various types of data traffic traversing their network. The traffic may include both control plane packets and user plane packets.

A network visibility appliance (hereinafter called simply “network appliance”) in a TRAN deployment can support flow sampling. Flow sampling allows a wireless operator to scale down subscriber traffic to be monitored by analytic tools in order to meet their processing throughput. This can be implemented by wireless operators to decide which subscribers, which traffic type, and how much of each traffic type is monitored and analyzed by tools, through a set of configurations, rules and/or policies.

A disadvantage of that method by itself is that the configurations, rules and/or policies are static, and editing them requires manual intervention. For example, sampling policies need to be manually configured, and these are applied constantly on all traffic regardless of any changes seen on the traffic, which does not optimize use of tools.

The technique introduced here, on the other hand, can use multiple inputs, such as metadata about the traffic, to edit configurations, rules and policies automatically and dynamically (i.e., as network traffic is being processed by the network appliance), and hence, can reduce or eliminate the network operators intervention and optimize the use of tools proactively. For example, sampling rules and percentages can be dynamically configured based on the analysis of metadata collected about network traffic, its pattern, subscriber behavior, etc., and additional sources of information that could be collected by the network appliance. Examples of possible input parameters include: session establishment/deletion rates, duration of established sessions, bit rates seen per session and APN/QCI distribution throughout the day. Any or all this information could be used as input to proactively define the sampling configuration to optimize the use of the tools.

In some embodiments, the technique introduced here entails a network appliance ascertaining a characteristic of data traffic associated with the network, such as throughput, by examining a first plurality of flows; then dynamically determining, without user input, a sampling policy for use in determining the forwarding of flows from the network appliance to a particular tool, based on the ascertained characteristic of the data traffic; then receiving a second plurality of flows communicated on the network; and then applying the determined sampling policy to select flows of the second plurality of flows to be forwarded to the tool.

Dynamically determining a sampling policy might involve dynamically deriving a modified sampling policy based on a sampling policy that is currently in use by the network appliance for a given tool. For example, the network appliance may determine that it needs to decrement or increment a current sampling percentage being used for a given traffic type and tool, by a specified decrementer or incrementer value. Further, dynamically determining the sampling policy might include determining a different sampling policy (e.g., a different sampling percentage) for each of various different types of network traffic/flows, based on a known prioritization of those traffic types. Note that in this description, the terms “traffic type” and “service type” are used synonymously. The different traffic types may include, for example, Internet Protocol (IP) Multimedia Subsystem (IMS), video, Internet, and others.

Further, the network appliance can dynamically determine a sampling policy based on an expected value of a characteristic of data traffic for a future time period (e.g., the expected network throughput for the next eight hours) and a performance parameter of the tool (e.g., the tool's maximum throughput). The network appliance can also use its own buffering capacity to increase the sampling percentage for certain types of traffic, such as higher priority traffic, when the current network throughput is below maximum throughput for a tool.

Further details of the technique introduced here are provided below and in the accompanying drawings. Before discussing those details, however, it is useful to consider an example of a network appliance and an environment in which it can be used.

FIG. 1illustrates an example of a network visibility appliance (“network appliance”)100, in which the technique introduced here can be implemented. The network appliance100includes a first network port112, a second network port114, a first pair of tool ports including an egress tool port128aand an ingress tool port128b, and a second pair of tool ports including an egress port129aand an ingress port129b. Packets received by the network appliance100are sent through tool egress port128ato tool170, which after processing those packets returns them to the network appliance100through tool ingress port128b. Similarly, packets received by the network appliance100are sent through tool egress port129ato tool172, which after processing those packets returns them to the network appliance100through tool ingress port129b. In other embodiments the network appliance100may contain more or fewer tool ports that four, and in operation, it may be coupled to more or fewer tools than two.

The network appliance100also includes a packet switch (“switch module”)140that implements selective coupling between network ports112,114and tool ports128,129. As used in this specification, the term “tool port” refers to any port that is configured to transmit packets to or to receive packets from a tool. The network appliance100further includes a processor144, and a network switch housing146for containing the packet switch140and the processor144. The processor144may be, for example, a general-purpose programmable microprocessor (which may include multiple cores), an application specific integrated circuit (ASIC) processor, a field programmable gate array (FPGA), or other convenient type of circuitry.

The network appliance100may also include other components not shown, such as one or more network physical layers (“PHYs”) coupled to each of the respective ports112,114, wherein the network PHYs may be parts of the packet switch140. Alternatively, the network PHYs may be components that are separate from the integrated circuit140. The PHY is configured to connect a link layer device to a physical medium such as an optical fiber, copper cable, etc. In other embodiments, instead of the PHY, the network appliance100may include an optical transceiver, or a Serializer/Deserializer (SerDes), etc.

The housing146allows the network appliance100to be carried, transported, sold, and/or operated as a single unit. The ports112,114,128,129are located at a periphery of the housing146and may be at least partially contained within the housing146. In other embodiments, the ports112,114,128,129may be located at other locations relative to the housing146. Although two network ports112,114are shown, in other embodiments the network appliance100may include more than two network ports. Also, although two tool ports128,129are shown, in other embodiments, the network appliance100may include only one tool port, or more than two tool ports.

During use, the first network port112of the network appliance100is communicatively coupled (e.g., via a network, such as the Internet) to a first node160, and the second port114is communicatively coupled (e.g., via a network, such as the Internet) to a second node162. The network appliance100is configured to communicate packets between the first and second nodes160,162via the network ports112,114. Also, during use, the tool ports128,129of the network appliance100are communicatively coupled to respective tools170,172. The tools170,172may include, for example, one or more of an IDS, IPS, packet sniffer, monitoring system, etc. The tools170,172may be directly coupled to the network appliance100, or communicatively coupled to the network appliance100through the network (e.g., Internet). In some cases, the network appliance100is provided as a single unit that allows the network appliance100to be deployed at a single point along a communication path.

In the illustrated embodiments, the packet switch140is configured to receive packets from nodes160,162via the network ports112,114, and process the packets in accordance with a predefined scheme. For example, the packet switch140may pass packets received from one or more nodes to one or more tools170,172that are connected to respective tool port(s)128,129, respectively.

The packet switch140may be any switch module that provides packet transmission in accordance with a predetermined transmission scheme (e.g., a policy). In some embodiments, the packet switch140may be user-configurable such that packets may be transmitted in a one-to-one configuration (i.e., from one network port to an tool port). The tool may be an out-of-band device (i.e., it can only receive packets intended to be communicated between two nodes, and cannot transmit such packets downstream), such as a sniffer, a network monitoring system, an application monitoring system, an IDS, a forensic storage system, an application security system, etc.; or the tool may be an in-line device (i.e., it can receive packets, and transmit the packets back to the network appliance100after the packets have been processed), such as an IPS. In other embodiments, the packet switch140may be configured such that the packets may be transmitted in a one-to-many configuration (i.e., from one network port to multiple tool ports). In other embodiments, the packet switch140may be configured such that the packets may be transmitted in a many-to-many configuration (i.e., from multiple network ports to multiple tool ports). In further embodiments, the packet switch140may be configured such that the packets may be transmitted in a many-to-one configuration (i.e., from multiple network ports to one tool port). In some embodiments, the one-to-one, one-to-many, many-to-many, and many-to-one configurations are all available for allowing a user to selectively configure the network appliance100so that the packets (or certain types of packets) are routed according to any one of these configurations. In some embodiments, the packet movement configuration is predetermined such that when the network appliance100receives the packets, the network appliance100will automatically forward the packets to the ports based on the predetermined packet movement configuration (e.g., one-to-one, one-to-many, many-to-many, and many-to-one) without the need to analyze the packets (e.g., without the need to examine the header, determine the type of packets, etc.).

Examples of network appliance100that may be used to implement features described herein include any of the commercially available GigaVUE™ series of network visibility appliances available from Gigamon Inc. of Santa Clara, Calif.

FIG. 2shows an example of one possible deployment of a network appliance200in a network environment1000. Network appliance200can be the same as or similar to network appliance100inFIG. 1. The Internet1004is coupled via routers1006a-band firewalls1068a-bto two switches1010aand1010b. Switch1010ais coupled to servers1012a-band IP phones1014a-c. Switch1010bis coupled to servers1012c-e. A sniffer1016, an IDS1018and a forensic recorder1020(collectively, “out-of-band tools”) are coupled to the network appliance200. The same out-of-band tools can access information anywhere in the network environment1000through the network appliance200. The user has the flexibility to channel whatever traffic to whatever tool or groups of out-of-band tools, using the any-to-any, any-to-many and many-to-one capability of the system in accordance with the different embodiments described herein. For example, all the conversations of the IP phones1014a-ccan be easily configured to be sent to an IDS1018. It is also possible that traffic inside a particular IP phone1014a-cconnection can be sent to a sniffer1016, and IDS1018and a forensic recorder1020simultaneously via the one-to-many function.

In some embodiments, when using the network appliance200, one or more out-of-band tools (such as IDS, sniffer, forensic recorder, etc.) may be connected to some tool port(s) of the network appliance200, and one or more in-line tools140a,140b(e.g., IPS) may be connected to other tool port(s) (e.g., inline port(s)) of the network appliance200. Such configuration allows out-of-band tool(s) and in-line tool(s) to simultaneously monitor and/or regulate network traffic.

FIG. 3shows an example of how a network appliance such as described above can be deployed in a core network (TRAN) of a wireless communications network. Note thatFIG. 3illustrates the deployment at a logical level, such that detailed physical connections are not necessarily depicted. A wireless operator's equipment306includes a core network (TRAN)301and a number of base stations302, which are connected to the core network301. Each of the base stations302communicates over-the-air with various user equipment (UEs)303, i.e., mobile devices such as cell phones, belonging respectively to various subscribers. The core network301may also be connected to, and provide its subscribers with access to, one or more other networks307, such as the Internet and/or a public switched telephone network (PSTN).

The wireless operator may connect one or more network appliances300to their core network301, in either an in-line or out-of-band configuration. Each such network appliance300may be connected to one or more tools305and may operate in the manner described above regarding network appliance100or200. Hence, the network appliance300may be used to facilitate monitoring, by one or more tools, of various types of network traffic traversing the core network.

In at least some embodiments, a user (e.g., a core network administrator employed by the wireless operator) inputs certain parameters to the network appliance, such as the maximum throughput capacity each tool can handle and the minimum throughput capacity below which the traffic rate should not drop (for in-line operation). The user may also assign an incrementer value and/or a decrementer value, which can be in the form of a percentage, which acts as a weights to increase or decrease the traffic to a tool, respectively. These user inputs and other configuration inputs may be provided to the network appliance through network visibility management software running on a separate device from the network appliance. For example,FIG. 4shows how one or more network appliances300can be connected via a network (e.g., a local area network (LAN))310to network visibility management software312running on a separate computer system314. To simplify illustration, the tools, network data sources and destinations are not shown inFIG. 4.

FIG. 5shows an example of processing logic that may be included in a network appliance100,200or300to implement the dynamic policy determination technique introduced here. The processing logic500may be in the form of hardwired circuitry, or programmable circuitry, or a combination of programmable circuitry and software. For example, processing logic500can be implemented at least partially as processor144shown inFIG. 1. As shown, the primary elements of the processing logic500are a policy engine501and a correlation engine502. Additionally, received packets are stored in a packets database503. One or more flow sampling policies are stored in a policies database504, and various network traffic statistics are stored in a traffic statistics database505. Each of these databases503,504,505can be maintained within the network appliance300, or within a separate device, which may be connected to the network appliance300via a network.

In certain embodiments, the processing logic500operates according to the following example. All mobility related (e.g., 3G, 4G and 5G) packets received by the network appliance300, including control and user plane packets, enter both the policy engine501and the correlation engine502. In the correlation engine502, all packets are timestamped, and time-correlated control packets and data packets are sent to the packet database503every T1 seconds. Control packets and user packets can be distinguished by their headers. In certain embodiments, each control packet is parsed by the correlation engine502to extract the following information elements from its headers (these parameters are taken using 4G as the example, but the parameters would be similar for 5G traffic):Subscriber Identities: MSISDN, IMEI, IMSI and UE IP addressTEID (both source and destination TEIDs for control and data bearers)IP addresses (both source and destination for control and data bearers)Bearer IDsQCI (Quality of Service Class Identifier)User location Information: Tracking Area Code, Cell ID, Country Code and Network CodeMessage TypesCause codesRadio Access TechnologyInterface TypesState of each session (completed, ongoing, failure or aged out)Theoretical throughput parameters (GBR: Guaranteed bit rate, MBR: Maximum bit rate for dedicated bearers, and AMBR: Aggregate Maximum bit rate for default bearers for both control and data packets)Actual throughput parameters: Total number of packets and corresponding octet count (both for control and data packets)Service Type (stored as Access Point Name (APN))

Based on the information stored in the packets database503, the correlation engine502extracts the relevant information every T1 seconds to build a subscriber throughput table that is stored in time series in the traffic statistics database505, which also includes historical data across different time periods for different parameters. An example subscriber throughput table601is shown collectively inFIGS. 6A, 6B and 6C.

The correlation engine502queries packets from the packets database503every T2 seconds to calculate the following parameters, for example, to create and continually update the subscriber throughput table:Average throughput and standard deviation from average throughput per service type per subscriber, with corresponding QCITotal average throughput and standard deviation from total average throughput per service type for all subscribers, with corresponding QCITotal average throughput and standard deviation from total average throughput per time period.

As the subscriber throughput table is built over many days, historical data is also built per service type per subscriber per time period, with corresponding QCI. Using this data, the correlation engine502can predict the expected traffic per service type for each subscriber for a future time period. The accuracy of prediction increases as more data is collected. For the purpose of illustration, example table501inFIG. 6splits each day into just three time period and shows only two subscribers for just dedicated bearers, but the same methodology can apply even when a day is divided into more time periods and/or for more subscribers with both default and dedicated bearers.

FIG. 7shows an example data record701that may be contained in the policies database504for a particular tool. Such a data record can be used by the policy engine501to determine dynamically the current sampling policy to use for each type of network traffic, for each tool. An example of a policy (expressed here in plain English only to facilitate this description) might be “Reduce IMS traffic forwarded to Tool X by 5%,” or something similar. This policy would equate to forwarding 95% of all IMS flows received by the network appliance to Tool X, i.e., a sampling rate of 95%.

The policy engine501is responsible for dynamically determining the sampling policy to apply to network traffic (flows) of each service type, for each tool, at any given point in time. It does so based on data stored in the policies database504as well as information from the subscriber throughput table in statistics database505. For example, the policy engine501constantly monitors network traffic characteristics in the subscriber throughput table and dynamically determines a flow sampling policy to apply for a tool, so as to decrease and/or increase traffic throughput to that tool, so that the tool is always efficiently used.

Referring now toFIG. 7, as noted above, an administrative user may be required to input the maximum throughput capacity702that each type708of tool can handle and the minimum throughput capacity703below which the traffic rate should not drop. The user may also be required to assign incrementer/decrementer values704(e.g., weights to reduce/increase the traffic). The maximum throughput seen for each service type706is, of course, higher than the mean throughput. Based on the QCI value707for each service type, the user can also assign a buffering value705to allow more flows to be sampled for high priority services when maximum traffic throughput is above the mean throughput. In the example ofFIG. 7, the user has decided to allow a buffer of 40% for service type with QCI equal to 1, 10% for service type with QCI equal to 4, 20% for service type with QCI equal to 7, and 0% for other service types.

Every T1 seconds, when the subscriber throughput table is updated, the policy engine501checks the maximum capacity of the tool (for each tool) against the current throughput and against the expected throughput for the next time period, to determine if, respectively, the throughput is exceeding or is expected to exceed the tool's capacity. If the policy engine501determines that the tool's capacity is being exceeded or is expected to be exceeded in the next time period, it will make the decision to reduce the sampled flows for each service type706by the decrementer value704that has been assigned to that service type by the user. Flows for a given service type are reduced by reducing the numbers of flows that are sampled (i.e., forwarded to a tool) based on the decrementer value.

FIG. 8is a flow diagram showing an example of a process that can be performed by the correlation engine502according to the technique introduced here. At step801, the correlation engine502receives one or more new packets from the network (e.g., from the wireless operators core network). At step802the correlation engine502timestamps the received packets. Every T1 seconds (step803), the correlation engine502correlates the received control packets and user packets (e.g., based on their timestamps) at step804, parses the control packets to extract the relevant parameters (such as those mentioned above) at step805, and sends the timestamps, correlated packet data to be packet database503at step806.

FIG. 9is a flow diagram showing an example of a process that can be performed by the policy engine501according to the technique introduced here. Every T1 seconds (step901), the policy engine501queries information from the packets database503at step902and builds or updates (as the case may be) the subscriber throughput table at step903. Every T2 seconds (step904; T2 is greater than T1), the process flow proceeds to step905and subsequent steps. At step105, the policy engine501queries information from the subscriber throughput table and uses that information to compute various time average statistics, such as:Average throughput and standard deviation from average throughput per service type per subscriber, with corresponding QCITotal average throughput and standard deviation from total average throughput per service type for all subscribers, with corresponding QCITotal average throughput and standard deviation from total average throughput per time period.

The policy engine501then updates the subscriber throughput table with the computed values at step907. At step908, the policy engine501determines if the current total average throughput is greater than a tool's (user-specified) maximum throughput. If the answer is negative, then the policy engine501determines at step909whether the expected total average throughput for the next time period is greater than the tool's maximum throughput. If the answer to either step908or step909is affirmative, then the process proceeds to step911, in which the policy engine501reduces the sampled flows for each service type by the corresponding decrementer value in the record for that tool in the policy database504(see the example ofFIG. 7). After step909or step911, the policy engine501determines in step910whether the network appliance has at least the minimum specified amount of buffer space available for the tool. If the answer is affirmative, then the policy engine501at step912increases the sampling rate for flows of one or more service types, based on the buffer values specified for each service type in the policy database504(e.g., buffer values705inFIG. 7). After step912, or if the answer to step910is negative, the process loops back to step901.

The above-described processes are now described further with reference to a specific example, using the example throughput table601inFIG. 6and the example data record701inFIG. 7to facilitate explanation. Each service type is assigned a decrementer value704in table701, which is specified as a percentage. The maximum throughput capacity that the particular tool associated with data record701can handle has been specified as 50 Gbps. Assume that currently all service types are sampled at 100%, i.e., all traffic is sent to the tool.

Assume that the current time period is 00:00 to 08:00 hours on day 2. Assume further that for the current time period, the total average throughput the network is seeing is 39.5 Gbps, which is below the maximum tool capacity of (per table701) 50 Gbps. Consequently, the policy engine501decides that there is no need to reduce the throughput for any service type. The policy engine501also looks at the next time period in table601, which is 08:01 to 16:00 on day 2, and refers to traffic throughput on day 1. The total average throughput is 52 Gbps, which is higher than what the tool can handle. The policy engine501, based on the historical data (from day 1), therefore decides to lower the traffic throughput for day 2 for the time period 08:01-16:00 for each service type.

To accomplish this, the policy engine501refers to table701to determine the decrementer value assigned to each service type, to reduce the traffic for the time period 08:01 to 16:00. For IMS traffic, according to table601the expected traffic for all subscribers is 13 Gbps. According to table701the decrementer for IMS traffic is 5%, so the policy engine501decides to reduce IMS traffic flows by 5% (i.e., sample 95%) which is 12.35 Gbps.

For video, according to table601the expected traffic for all subscribers is 14 Gbps. According to table701the decrementer for video traffic is 10%, so the policy engine501decides to reduce video traffic flows by 10% (i.e., sample 90%), which is 12.6 Gbps.

For Internet traffic, according to table601the expected traffic for all subscribers is 12 Gbps. According to table71the decrementer for Internet traffic is 20%, so the policy engine501decides to reduce the traffic flows by 20% (i.e., sample 80%), which is 9.6 Gbps.

For all other service types, according to table601the expected traffic for all subscribers is 13 Gbps, and according to table701the decrementer is 50%, so the policy engine501decides to reduce all other traffic flows by 50% (i.e., sample 50%), which is 6.5 Gbps.

The policy engine501then determines whether buffering can be utilized to increase higher priority services. The total average throughput for all service types is 41.05 Gbps, which is below the maximum tool capacity and also above the specified minimum of 40 Gbps. This information is applied by the policy engine501as follows. Approximately 9 Gbps of buffer is available for the tool to handle, since tool maximum capacity is 50 Gbps and currently used throughput is 41.05 Gbps. Hence, the policy engine501can accommodate a certain amount of extra traffic (i.e., extra flows) for one or more service types based on, for example, QCI value as defined by user in table701, when the service types are above mean throughput. If the available tool buffer is greater than, for example, 1 Gbps, the policy engine501can apply the buffer values705in table701to sample extra traffic flows for one or more service types, as in the following example.

IMS traffic is specified as having the highest priority. Currently IMS traffic has its throughput reduced to 12.35 Gbps (as described above) when its mean traffic rate was at 13 Gbps. Based on table601, it is known that the IMS service type can reach a maximum traffic throughput of 18 Gbps. When this traffic rate does increase above 13 Gbps, up to 18 Gbps, the policy engine501allows an additional 40% of traffic for this service type (per the buffer value705for IMS in table701) above the current 12.35 Gbps, which amounts to ([12.35*(40/100)]+12.35)=17.29 Gbps. If the available tool buffer after this adjustment is at least 1 Gbps, the policy engine501performs a similar check for the next highest priority service type, namely, video.

For video, the current reduced traffic throughput is at 12.6 Gbps when its mean traffic rate was 14 Gbps. It is known based on table601that this service type can reach a maximum traffic rate of 16 Gbps. When this traffic throughput does increase above 14 Gbps, up to 16 Gbps, the policy engine501allows an additional 10% of traffic for this service type above the current 12.6 Gbps, which amounts to ([12.6*(10/100)]+12.6)=−13.86 Gbps. If the available tool buffer after this adjustment is at least 1 Gbps, the policy engine501performs a similar check for the next highest priority service type.

There is no need to allow any additional traffic for other service types even when traffic throughput increases based on the buffer value table701.

The new increased tool throughput in this example is 17.29 Gbps (IMS)+13.86 Gbps (Video)+9.6 Gbps (Internet: existing throughput)+6.5 Gbps (other service types: existing throughput)=47.25 Gbps, which is still less than maximum tool capacity of 50 Gbps.

The policy engine501therefore applies these new policies for the time period 08:01-16:00. Similarly, the policy engine501refers to table601for time period 16:01 to 23:59 for day 1 and, based on the historical data, determines that throughput is going to be 72 Gbps for that time period. Consequently, the policy engine501determines that the traffic will need to be reduced again for day 2 and applies the same algorithm as described above in similar manner. In this way, the policy engine501constantly monitors network traffic characteristics in the subscriber throughput table601and dynamically determines the sampling policies accordingly to table701to decrease and/or increase traffic throughput to the tool, so that the tool is always efficiently used.

FIG. 10is a block diagram of. an example of a processing system1200or other similar device in which techniques described herein may be implemented. In some embodiments, processing system1200represents at least a portion of the components in a network visibility appliance, such as any of network appliances100,200and300inFIGS. 1 through 4.

As shown, system1200includes a bus1202or other communication mechanism for communicating information, and a processor1204coupled with the bus1202for processing information. The processor1204may be used to perform various functions described above. For example, in some embodiments, the processor1204may dynamically determine sampling policies and cause those policies to be applied.

The system1200also includes a main memory1206, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus1202for storing information and instructions to be executed by the processor1204. The main memory1206also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor1204. The computer system1200further includes a read only memory (ROM)1208or other static storage device coupled to the bus1202for storing static information and instructions for the processor1204. A data storage device1210, such as a magnetic or optical disk, is provided and coupled to the bus1202for storing information and instructions.

The system1200may be coupled via the bus1202to a display1212, such as a light emitting diode (LED) based or liquid crystal display (LCD) based monitor, for displaying information to a user. An input device1214, including alphanumeric and other keys, is coupled to the bus1202for communicating information and command selections to processor1204. Another type of user input device is cursor control1216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor1204and for controlling cursor movement on display1212.

The system1200may be used for performing various functions in accordance with the techniques described herein. According to one embodiment, such use is provided by system1200in response to processor1204executing one or more sequences of one or more instructions contained in the main memory1206. Such instructions may be read into the main memory1206from another computer-readable medium, such as storage device1210. Execution of the sequences of instructions contained in the main memory1206causes the processor1204to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in the main memory1206. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement features of the embodiments described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described herein may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.

The machine-implemented operations described above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), system-on-a-chip systems (SOCs), etc.

The term “logic”, as used herein, means: a) special-purpose hardwired circuitry, such as one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), or other similar device(s); b) programmable circuitry programmed with software and/or firmware, such as one or more programmed general-purpose microprocessors, digital signal processors (DSPs) and/or microcontrollers, system-on-a-chip systems (SOCs), or other similar device(s); or c) a combination of the forms mentioned in a) and b).

Any or all of the features and functions described above can be combined with each other, except to the extent it may be otherwise stated above or to the extent that any such embodiments may be incompatible by virtue of their function or structure, as will be apparent to persons of ordinary skill in the art. Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described herein may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.

EXAMPLES OF CERTAIN EMBODIMENTS

Certain embodiments of the technology introduced herein are summarized in the following numbered examples:

1. A method comprising:

receiving, by a network appliance, a first plurality of flows communicated on a network, each said flow including a series of packets between a source and a destination within a same transport connection, the network appliance being configured to forward packets selectively to a tool that is external to the network appliance;

ascertaining a characteristic of data traffic associated with the network, by examining packets of the first plurality of flows;

dynamically determining, by the network appliance, a sampling policy for use in determining a forwarding of flows from the network appliance to the tool, based on the ascertained characteristic of the data traffic, without user input specifying the sampling policy;

receiving, by the network appliance, a second plurality of flows communicated on the network; and

using the determined sampling policy, by the network appliance, to select flows of the second plurality of flows to be forwarded to the tool.

2. The method of example 1, wherein dynamically determining the sampling policy comprises dynamically deriving a modified sampling policy based on a sampling policy currently in use by the network appliance.

3. The method of example 1 or example 2, wherein the second plurality of flows include flows of a first type of network traffic and flows of a second type of network traffic, and wherein said using the determined sampling policy comprises:

selecting a first sampling rate for sampling the first type of network traffic and a second sampling rate for sampling the second type of network traffic, the second sampling rate not being equal to the first sampling rate, the first and second sampling rates being indicative, respectively, of a subset of traffic of the first type to be forwarded to the tool and a subset of traffic of the second type to be forwarded to the tool.

4. The method of any of examples 1 through 3, wherein dynamically determining the sampling policy comprises:

determining an expected value of the characteristic of the data traffic for a future time period; and

determining the sampling policy based on the expected value of the characteristic of the data traffic and a performance parameter of the tool.

5. The method of any of examples 1 through 4, wherein ascertaining the characteristic of the data traffic comprises determining a first value of a first performance parameter associated with the network during a first time period.

6. The method of any of examples 1 through 5, wherein the first performance parameter is a throughput associated with the network.

7. The method of any of examples 1 through 6, further comprising, prior to said using the determined sampling policy:

determining a second value of the first performance parameter associated with the network during a second time period that is after the first time period; and

selecting said determined sampling policy for use, based on the second value of the first performance parameter.

8. The method of any of examples 1 through 7, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter exceeds a specified maximum value of a second performance parameter associated with the tool, reducing, by the network appliance, a sampling rate of a traffic type in the second plurality of flows, the sampling rate being indicative of a subset of the second plurality of flows that are to be forwarded to the tool.

9. The method of any of examples 1 through 8, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter exceeds a specified maximum value of a second performance parameter associated with the tool, routing, by the network appliance, flows of a traffic type of the second plurality of flows, to a second tool.

10. The method of any of examples 1 through 9, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter is less than a specified maximum value of a second performance parameter associated with the tool, increasing, by the network appliance, a sampling rate of a traffic type of a plurality of traffic types, according to a specified value, the sampling rate being indicative of a subset of the second plurality of flows that are to be forwarded to the tool.

11. The method of any of examples 1 through 10, wherein increasing the sampling rate comprises buffering at least some flows of the traffic type in the network appliance.

12. The method of any of examples 1 through 11, further comprising:

receiving user input indicative of a decrement value;

wherein the sampling policy comprises the decrement value, and wherein using the determined sampling policy comprises reducing a sampling rate for the second plurality of flows based on the decrement value.

13. The method of any of examples 1 through 12, wherein the network comprises a terrestrial radio access network (TRAN) portion of a wireless telecommunication network.

14. The method of any of examples 1 through 13, wherein ascertaining the characteristic of the data traffic comprises analyzing control headers of packets of flows tapped by the network appliance from control interfaces and/or user interfaces in the TRAN portion of the wireless telecommunication network.

15. The method of any of examples 1 through 15, wherein using the determined sampling policy further comprises reducing, by the network appliance, a sampling rate of a particular traffic type in the second plurality of flows to zero, to prevent forwarding of any flows of the particular traffic type to the tool.

16. A network appliance comprising:

a first network port through which to receive a first plurality of flows originated by a plurality of sources on a network, each said flow including a series of packets between a source and a destination within a same transport connection;

a first instrument port through which to forward at least some of the first plurality of flows to a tool;

a second instrument port through which to receive the at least some of the first plurality of flows from the tool after the tool has processed the flows;

a second network port through which to forward the first plurality of flows onto the network for delivery to a destination; and

a processor configured to cause the network appliance to perform operations includingascertaining a characteristic of data traffic associated with the network, by examining the first plurality of flows;dynamically determining a sampling policy for forwarding flows from the network appliance to the tool, based on the ascertained characteristic of the data traffic, without user input specifying the sampling policy;receiving, by the network appliance, a second plurality of flows communicated on the network; andusing the determined sampling policy to select some but not all of the second plurality of flows to be forwarded by the network appliance to the tool.

17. The network appliance of example 16, wherein dynamically determining the sampling policy comprises dynamically deriving a modified sampling policy based on a sampling policy currently in use by the network appliance.

18. The network appliance of example 16 or example 17, wherein the second plurality of flows include flows of a first type of network traffic and flows of a second type of network traffic, and wherein said using the determined sampling policy comprises:

selecting a first sampling rate for sampling the first type of network traffic and a second sampling rate for sampling the second type of network traffic, the second sampling rate not being equal to the first sampling rate, the first and second sampling rates being indicative, respectively, of a subset of traffic of the first type to be forwarded to the tool and a subset of traffic of the second type to be forwarded to the tool.

19. The network appliance of any of examples 16 through 18, wherein ascertaining the characteristic of the data traffic comprises determining a first value of a first performance parameter associated with the network during a first time period.

20. The network appliance of any of examples 16 through 19, wherein the first performance parameter is a throughput associated with the network.

21. The network appliance of any of examples 16 through 20, further comprising, prior to said using the determined sampling policy:

determining a second value of the first performance parameter associated with the network during a second time period that is after the first time period; and

selecting said determined sampling policy for use, based on the second value of the first performance parameter.

22. The network appliance of any of examples 16 through 21, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter exceeds a specified maximum value of a second performance parameter associated with the tool, reducing, by the network appliance, a sampling rate of a traffic type the second plurality of flows, the sampling rate being indicative of a subset of the second plurality of flows that are to be forwarded to the tool.

23. The network appliance of any of examples 16 through 22, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter exceeds a specified maximum value of a second performance parameter associated with the tool, routing, by the network appliance, flows of a traffic type of the second plurality of flows, to a second tool.

24. The network appliance of any of examples 16 through 23, wherein using the determined sampling policy further comprises:

when a second value of the first performance parameter is less than a specified maximum value of a second performance parameter associated with the tool, increasing, by the network appliance, a sampling rate of a traffic type of a plurality of traffic types, according to a specified value, the sampling rate being indicative of a subset of the second plurality of flows that are to be forwarded to the tool.

25. The network appliance of any of examples 16 through 24, wherein increasing the sampling rate comprises buffering at least some flows of the traffic type in the network appliance.

26. The network appliance of any of examples 16 through 25, further comprising:

receiving user input indicative of a decrement value;

wherein the sampling policy comprises the decrement value, and wherein using the determined sampling policy comprises reducing a sampling rate for the second plurality of flows based on the decrement value.

27. The network appliance of any of examples 16 through 26, wherein the network comprises a terrestrial radio access network (TRAN) portion of a wireless telecommunication network.

28. The network appliance of any of examples 16 through 27, wherein using the determined sampling policy further comprises reducing, by the network appliance, a sampling rate of a particular traffic type in the second plurality of flows to zero, to prevent forwarding of any flows of the particular traffic type to the tool.

29. A non-transitory machine-readable storage medium tangibly storing code, execution of which by at least one processor in a network appliance causes the network appliance to perform operations comprising:

receiving a first plurality of flows communicated on a network, each said flow including a series of packets between a source and a destination within a same transport connection, the network appliance being configured to forward flows selectively to a tool that is external to the network appliance;

ascertaining a characteristic of data traffic associated with the network, by examining the first plurality of flows;

dynamically determining a sampling policy for forwarding flows from the network appliance to the tool, based on the ascertained characteristic of the data traffic, without user input specifying the sampling policy;

receiving, by the network appliance, a second plurality of flows communicated on the network;

accessing the determined sampling policy, by the network appliance; and

using the determined sampling policy, by the network appliance, to select flows of the second plurality of flows to be forward to the tool.

30. The non-transitory machine-readable storage medium of example 29, wherein ascertaining the characteristic of the data traffic comprises determining a first value of a first performance parameter associated with the network during a first time period;

the method further comprising, prior to said using the determined sampling policy:determining a second value of the first performance parameter associated with the network during a second time period that is after the first time period; andselecting the sampling policy for use, based on the second value of the first performance parameter;

wherein using the sampling policy comprises at least one of the following operations:when a second value of the first performance parameter exceeds a specified maximum value of a second performance parameter associated with the tool, reducing a sampling rate of a traffic type the second plurality of flows, the sampling rate being indicative of a subset of the second plurality of flows that are to be forwarded to the tool;when the second value of the first performance parameter exceeds the specified maximum value of a second performance parameter associated with the tool, routing flows of a traffic type of the second plurality of flows, to a second tool; orwhen the second value of the first performance parameter is less than a specified maximum value of a second performance parameter associated with the tool, increasing a sampling rate of a traffic type of a plurality of traffic types, according to a specified value.

31. The non-transitory machine-readable storage medium of example 29 or example 30, wherein the second plurality of flows include flows of a first type of network traffic and flows of a second type of network traffic, and wherein said using the determined sampling policy comprises:

selecting a first sampling rate for sampling the first type of network traffic and a second sampling rate for sampling the second type of network traffic, the second sampling rate not being equal to the first sampling rate, the first and second sampling rates being indicative, respectively, of a subset of traffic of the first type to be forwarded to the tool and a subset of traffic of the second type to be forwarded to the tool.