The subject matter described herein relates to collecting statistics based on network packets. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for distributed network packet statistics collection in a test environment.
Network packet statistics collection is performed by test systems that transmit simulated packets to one or more devices under test. For example, one type of test system transmits simulated packets a device under test over different network ports of the test system, receives packets from the device under test, and generates statistics grouped by packet group identifiers inserted in the packets by the test system. In some tests, multiple statistics may be generated for each packet group identifier. Generating statistics for a packet group identifier may include looking up the packet group identifier in a table, locating the column in the table containing the statistic to be updated, and updating the statistic. As the number of packet group identifiers increases, the size of the statistics table increases and the amount of processing required to insert a statistic in the table also increase. In addition, as the table size increases, operations on the table, such as sorting, grouping, inserting, etc. require an increased amount of processing resources and/or time to complete.
In one exemplary network packet statistics collection system, packet statistics are collected on a per port basis in the test system chassis. The port processor associated with each port collects statistics for that port and forwards the statistics to a client device for merging with statistics from other ports and report generation. As the number of ports in a test increases, the amount of processing required to be performed by the client device also increases. As a result, the capacity of the client processor to perform statistics processing can limit the scalability of the test system.
Accordingly, there exists a need for distributed network packet statistics collection in a test environment.
Methods, systems, and computer readable media for distributed network packet statistic collection in a test environment are disclosed. One method for distributed network packet statistics collection includes instantiating first and second operations that implement different portions of a network packet statistics collection task on processing nodes implemented on different processors in a network packet statistics collection system. The method includes utilizing an auto-discovery mechanism for the second operation to subscribe to a set of capabilities and identify the first operation as a matching operation. The method further includes establishing a channel between the first and second operations. The method further includes executing the network packet statistics collection task, where the first and second operations perform the different portions of the network packet statistics collection task.
A system for distributed network packet statistics collection in a test environment is also disclosed. The system includes a network packet statistics collection system including a chassis and a client, each including a processor. The system includes first and second processing nodes for executing on one or more of the processors. The system further includes first and second operations that implement different portions of a network packet statistics collection task for executing on the first and second processing nodes. The first and second operations are configured to utilize an auto-discovery mechanism for the second operation to subscribe to a set of capabilities and identify the first operation as a matching operation. The first and second operations are configured to connect to each other and execute the network packet statistics collection task, where the first and second operations perform the different portions of the network packet statistics collection task.
The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
As used herein, the term “operation” refers to an entity that implements a portion of a network packet statistics collection task. An operation may be implemented in software. One example of an operation that implements a network packet statistics collection task may be an operation that counts packets having a particular source address. Another operation may count packets having a particular destination address.
As used herein, the term “network packet statistics collection task” refers to any task associated with collecting or generating data based on test packets transmitted between a test system and a device under test. Examples of statistics that may be collected for internet protocol packets include session identifier, session state, topology ID, port ID, device group ID, protocol ID, and protocol type. Such information may be collected and stored in a table. Network packet statistics collection may include performing operations based on the table, including grouping, sorting, inserting, deleting, etc.
In the illustrated example, each processing node 100 includes a processing acceptor 104 that accepts allocation of operations from other processing nodes. Each processing node 100 also includes an operation/broker discover 106 for discovering and communicating with broker 102 and other operations. Each operation/broker discoverer 106 further includes an operation publisher/subscriber 108 for publishing details about operations implemented on the respective processing node and subscribing to operations implemented on remote processing nodes.
The message flow illustrated in
Once a processing node accepts an operation, the operation publisher/subscriber 108 publishes or subscribes to an operation by transmitting a publish or subscribe message with operation-identifying attributes to broker 102. In the illustrated example, the processing node associated with operation 2 publishes the details of operation 2 to broker 102. Processing node 100 associated with operation 1 subscribes to particular operation attributes by transmitting a subscribe message with operation-identifying attributes to broker 102. Upon receiving the published operation and subscribe operation messages, broker 102 determines whether the attributes of a publishing operation match those of a subscribing operation. In the illustrated example, operation 2 publishes attribute A with value v. Operation 1 subscribes to an operation with attribute A and value v. Accordingly, because the attributes match, broker 102 determines that the operations match and transmits a matching remote operation message to operation 1 identifying the remote processing node and the operation on the remote processing node that matches the subscription request. The matching remote operation message includes information sufficient for the subscribing operation to connect to the publishing operation.
Once operation 1 has discovered operation 2, operation 1 creates a channel to operation 2 to be used in the test. Creating a channel may include operation 1 acting as a channel initiator and initiating a connection with operation 2, which acts as a channel acceptor. The channel may be a transport or other layer connection. It should also be noted that the initiator/acceptor sides of a channel are independent from the input/output sides, even though in the illustrated example operation 1 is providing output to operation 2. The accepting side of the channel is identified by the operation instance and input/output index to which the channel should connect. Attributes are used to find the family of potential operation instances from which to select the actual channel remote endpoint.
Once a channel is connected between the operations, a network test may be executed and the operations may perform their respective portions of the network packet statistics collection task. For example, packets may be forwarded to processing node 100 where operation 1 implements its portion of the packet statistics collection task. The packets may then be forwarded to operation 2 over the created channel where operation 2 performs its respective portion of the network packet statistics collection task. Alternatively, if the network packet statistics collection task is a high level table sort followed by a lower level sort, operation 1 may perform the high level sort, forward the sorted packet statistics table to operation 2, which further sorts the table received from operation 1. If a processing node or a channel fails, the discovery process illustrated in
The first step to initiating the process for a distributed network test is to create mesh flows processing nodes 100 and broker 102 and allocate the mesh flows processing nodes 100 and broker 102 to processors 212. Referring to
In step 302, different portions of a network packet statistics collection task are assigned to different processing nodes and corresponding operations are instantiated on the assigned processing nodes. For example, each mesh flows processing node 100 may be assigned a different portion of a network packet statistics collection task. In one example, the task may be a table sort operation where the table contains network packet statistics. A processor 212 associated with port 208 may be assigned to the highest level of the table sort. A processor 212 associated with chassis card 206 may be allocated to receive the results from port processor 212 and perform a next level table sort on the data received from port processor 212. A Processors associated with client 204 may be allocated to receive the results from processor 212 of chassis card 206 and perform the lowest level table sort. Once the processor assignment is completed, operations are instantiated on the assigned processors.
In step 304, the auto-discovery mechanism described herein is used to discover matching operations. For example, as illustrated in
In step 306, connections are established between matching operations. For example, once matching operations are discovered, a subscribing operation may create a channel with a publishing operation by sending a create channel message to the publishing operation. The publishing operation preferably accepts the channel and sends confirmation to the subscribing operation. The process is repeated for each set of matching operations.
In step 308, a test is executed and statistics are generated using the matching operations. Continuing with a table sort example, one or more operations executing on one or more mesh flows processing nodes may implement higher level sort, provide the data to matching operations, which perform the next lowest level sort, which provide the data to the next level of processing nodes, and so forth. The mesh flows processing nodes that implement the final sort will contain the sorted data.
In step 310, it is determined whether a channel or operation failure has occurred. If a channel or operation failure has occurred, control returns to step 304 where the auto-discovery process is repeated to discover matching operations, establish channels between matching operations, and continue the test using the newly established channels. If a channel or operation failure has not occurred, test execution and statistics collection continues until the test ends.
The subject matter described herein is not limited to allocating processing nodes and operations among processors associated with chassis processor cards, port processor cards, and client processors. In an alternate example, as illustrated in
In yet another example, a processor on a dedicated mesh flows processing platform separate from chassis 202 and client 204 may be used to perform at least some of the network statistics collection task.
In yet another example, mesh flows processing nodes 100 and broker 102 may be allocated to different virtual machines of a network equipment test system or of a separate dedicated processing platform.
As stated above, according to one aspect of the subject matter described herein, different parts of a network packet statistics collection task are distributed among different processing nodes in a network packet statistics collection system. In one exemplary implementation, the scheduler that may be implemented on any of the processors illustrated in
In Table 1, a collection of statistics may be collected for each perceived packet having a particular packet group identifier. As each new packet group identifier is encountered, a table such as that illustrated in
Rather than collecting statistics at each port using the port processor of that port and then having each port forward its statistics to client processor 104 for combination, the operations and mesh flows processing nodes described herein may be distributed among processors in a hierarchical manner to reduce the processing burden over implementations where a single processor performs all of the statistics collection.
In
If data is being collected on a client node, the client node may have its own name for a particular data. The scan operation that receives the port configuration may provide the client to sign name to the join node, which replaces the port processors named for a port with the client processors name. Finally, the sort nodes sort the combined statistics according to user specified criteria, such as IP address.
It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
Number | Name | Date | Kind |
---|---|---|---|
5343463 | Van Tetering et al. | Aug 1994 | A |
5477531 | McKee et al. | Dec 1995 | A |
5600632 | Schulman | Feb 1997 | A |
5742760 | Picazo, Jr. et al. | Apr 1998 | A |
5787283 | Chin et al. | Jul 1998 | A |
5850386 | Anderson et al. | Dec 1998 | A |
5878032 | Mirek et al. | Mar 1999 | A |
5982753 | Pendleton et al. | Nov 1999 | A |
6028847 | Beanland | Feb 2000 | A |
6041053 | Douceur et al. | Mar 2000 | A |
6065053 | Nouri et al. | May 2000 | A |
6088777 | Sorber | Jul 2000 | A |
6172989 | Yanagihara et al. | Jan 2001 | B1 |
6233256 | Dieterich et al. | May 2001 | B1 |
6252891 | Perches | Jun 2001 | B1 |
6295557 | Foss et al. | Sep 2001 | B1 |
6360332 | Weinberg et al. | Mar 2002 | B1 |
6446121 | Shah et al. | Sep 2002 | B1 |
6545979 | Poulin | Apr 2003 | B1 |
6601098 | Case et al. | Jul 2003 | B1 |
6717917 | Weissberger et al. | Apr 2004 | B1 |
6728929 | Luong | Apr 2004 | B1 |
6789100 | Nemirovsky et al. | Sep 2004 | B2 |
6820034 | Hanes et al. | Nov 2004 | B2 |
6823219 | Lee et al. | Nov 2004 | B2 |
6888818 | Gubbi | May 2005 | B1 |
6910061 | Hu et al. | Jun 2005 | B2 |
6950405 | Van Gerrevink | Sep 2005 | B2 |
7007089 | Freedman | Feb 2006 | B2 |
7035223 | Burchfiel et al. | Apr 2006 | B1 |
7088735 | Roehr, Jr. et al. | Aug 2006 | B1 |
7187683 | Sandoval et al. | Mar 2007 | B1 |
7295555 | Elzur | Nov 2007 | B2 |
7406089 | Rahim et al. | Jul 2008 | B1 |
7443870 | Zioulas et al. | Oct 2008 | B2 |
7451458 | Tuchow | Nov 2008 | B2 |
7489706 | Hatley et al. | Feb 2009 | B2 |
7561559 | Hannel et al. | Jul 2009 | B2 |
7594159 | Fujikami et al. | Sep 2009 | B2 |
7643431 | Pepper | Jan 2010 | B2 |
7826377 | Pepper | Nov 2010 | B2 |
7826381 | Kastuar et al. | Nov 2010 | B1 |
8050175 | Pepper | Nov 2011 | B2 |
8219675 | Ivershen | Jul 2012 | B2 |
8310942 | Gintis et al. | Nov 2012 | B2 |
8391157 | Ginsberg et al. | Mar 2013 | B2 |
8582466 | Gintis et al. | Nov 2013 | B2 |
9531620 | Ciodaru et al. | Dec 2016 | B2 |
9553786 | Bergeron | Jan 2017 | B2 |
9654303 | Joyner | May 2017 | B2 |
20010016867 | Hu et al. | Aug 2001 | A1 |
20020172158 | Hoefelmeyer et al. | Nov 2002 | A1 |
20020183969 | Hanes et al. | Dec 2002 | A1 |
20030033025 | Lee et al. | Feb 2003 | A1 |
20040037277 | Mathews et al. | Feb 2004 | A1 |
20040052259 | Garcia et al. | Mar 2004 | A1 |
20040131013 | Ise et al. | Jul 2004 | A1 |
20040158744 | Deng et al. | Aug 2004 | A1 |
20040252686 | Hooper et al. | Dec 2004 | A1 |
20050013251 | Wang et al. | Jan 2005 | A1 |
20050286564 | Hatley et al. | Dec 2005 | A1 |
20060088060 | Fujikami et al. | Apr 2006 | A1 |
20060153078 | Yasui | Jul 2006 | A1 |
20070115833 | Pepper et al. | May 2007 | A1 |
20070195707 | Cidon | Aug 2007 | A1 |
20070291654 | Pepper | Dec 2007 | A1 |
20080112332 | Pepper | May 2008 | A1 |
20080317233 | Rey et al. | Dec 2008 | A1 |
20090310491 | Ginsberg et al. | Dec 2009 | A1 |
20100069092 | Bajpai et al. | Mar 2010 | A1 |
20100074135 | Pepper | Mar 2010 | A1 |
20110078319 | Ishida | Mar 2011 | A1 |
20120051234 | Gintis et al. | Mar 2012 | A1 |
20130331082 | Topaltzas et al. | Dec 2013 | A1 |
20130343389 | Stroud | Dec 2013 | A1 |
20130346628 | Canion | Dec 2013 | A1 |
20130346719 | Tomlinson | Dec 2013 | A1 |
20130346736 | Cook | Dec 2013 | A1 |
20130346987 | Raney | Dec 2013 | A1 |
20130347103 | Veteikis | Dec 2013 | A1 |
20140016479 | Coomber et al. | Jan 2014 | A1 |
20140269337 | Gintis | Sep 2014 | A1 |
20160057040 | Bergeron | Feb 2016 | A1 |
20170164186 | Yong | Jun 2017 | A1 |
20170272352 | Badea et al. | Sep 2017 | A1 |
20180013839 | Noldus et al. | Jan 2018 | A1 |
Entry |
---|
Ixia, “Specifications for Load Modules—Multilayer Gigibit Ethernet for LM1000LX, LM1000SX, LM1000GBIC, LM1000T, Product Specification Sheet,” pp. 1-2 (2002). |
Ixia, “Ixia 200 Chassis, Product Description,” pp. 1 (1999). |
Notice of Allowance and Fee(s) Due, Applicant-Initated Interview Summary and AFCP 2.0 Decision for U.S. Appl. No. 14/465,453 (dated Sep. 14, 2016). |
Final Office Action for U.S. Appl. No. 14/465,453 (dated Jun. 16, 2016). |
Applicant-Initiated Interview Summary for U.S. Appl. No. 14/465,453 (dated Mar. 3, 2016). |
Applicant-Initiated Interview Summary for U.S. Appl. No. 14/465,453 (dated Mar. 1, 2016). |
Non-Final Office Action for U.S. Appl. No. 14/465,453 (dated Dec. 18, 2015). |
Krishnan, “Flow-aware Real-time SDN Analytics (FRSA),” http://blog.sflow.com/2014/02/flow-aware-real-time-sdn-analytics-frsa.html, pp. 1-12 (Feb. 5, 2014). |
Non-Final Office Action for U.S. Appl. No. 15/077,832 (dated Apr. 3, 2018). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/870,729 (dated Aug. 31, 2012). |
Non-Final Office Action for U.S. Appl. No. 12/870,729 (dated Jul. 2, 2012). |
European Search Report for European Patent Application Serial No. 11008066.0 (dated Feb. 10, 2012). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/627,925 (dated Aug. 26, 2011). |
Examiner Initiated Interview Summary and Final Office Action for U.S. Appl. No. 12/627,925 (dated Jun. 17, 2011). |
Non-Final Office Action for U.S. Appl. No. 12/627,925 (dated Jan. 21, 2011). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 11/558,855 (dated Nov. 18, 2009). |
Final Office Action for U.S. Appl. No. 11/558,855 (dated Oct. 15, 2009). |
Non-Final Office Action for U.S. Appl. No. 11/558,855 (dated Mar. 24, 2009). |
Sadasivan et al., “Architecture for IP Flow Information Export,” Network Working Group, pp. 1-31 (Mar. 2009). |
Ixia, “IxExplorer User's Guide,” Revision 2.1.0, pp. 1-384 (Nov. 1, 1999). |
Ixia, “Specifications for Load Modules—Multilayer Gigibit Ethernet for LM1000LX, LM1000SX, LM1000GBIC, LM1000T, Product Specification Sheet,” pp. 1-2 (Undated). |
Ixia, “The Ixia 200 Traffic Generator and Analyzer, Product Description,” pp. 1-2 (1997-1999). |
Brownlee et al., “Traffic Flow Measurement: Architecture,” Network Working Group, The University of Auckland, GTE Laboratories, Inc. and GTE Internetworking, pp. 1-49 (Oct. 1999). |
Ixia, “Ixia 200 Chassis, Product Description,” pp. 1 (Undated). |
Commonly-assigned, co-pending U.S. Appl. No. 15/826,628 for “Methods, Systems, and Computer Readable Media for Network Traffic Statistics Collection,” (Unpublished, filed Nov. 29, 2017). |
Number | Date | Country | |
---|---|---|---|
20180131586 A1 | May 2018 | US |