Process and system for capture and analysis of HFC based packet data

[0001] This invention relates generally to computer networks and more particularly to monitoring a network having cable modems.

[0002] A cable modem switch is designed to handle many clients. Given the number of clients and the complexity of the overall system, it requires a tool to aid network managers in tracing and determining the cause of problems. This is particularly important where there are a large number of attachment ports that need to be traced and monitored. Network information must be collected and analyzed quickly in order to be useful. A successful monitoring system must also be able to draw on the data stream without adding an undue load and must overcome or avoid data encryption.

[0003] It is an object of the present invention to provide a method and apparatus to analyze a cable modem network.

[0004] The problems of monitoring a cable modem network are solved by the present invention of a protocol analyzer.

[0005] Using the protocol analyzer, a system administrator can trace and monitor the traffic on the network from any given node or segment. In addition, statistical and expert analysis can be applied to this data to determine such things as: the general health of the network, overall utilization of the network, course of action for a specific network problem, and intruder detection.

[0006] There are three main components in the protocol analyzer, a capture engine, a filter/trigger engine and a display engine. The capture engine collects data and then duplicates, encapsulates, and forwards all packets that meet a basic criteria. The captured data included out-of-band data such as ranging power levels. The capture engine has three parameters which control its operation and can be programmatically set: a flag which operates as an on/off switch, a course-level filter and a destination where captured packets are delivered. These controls allow a system administrator the ability to switch between different, physical cable plants using a software interface (i.e., a physical tap does not have to be moved between said plants). Further filtering takes place after packets are passed on by the capture engine.

[0007] The capture criteria is defined by a course or pre-filter mechanism. The filter/trigger engine collates and filters said data. The display engine then analyzes and displays the data.

[0008] The present invention together with the above and other advantages may best be understood from the following detailed description of the embodiments of the invention illustrated in the drawings, wherein:

[0009] FIG. 1 is a block diagram of the protocol analyzer in a cable network system according to principles of the invention;

[0010] FIG. 2 is a flow chart of the data capture process of a receive packet by the protocol analyzer of FIG. 1;

[0011] FIG. 3 is a flow chart of the data capture process of a transmit packet by the protocol analyzer of FIG. 1;

[0012] FIG. 4 is a diagram of a copied packet with an encapsulation header according to principles of the invention;

[0013] FIG. 5 is a block diagram of a rule according to the principles of the present invention;

[0014] FIG. 6 is a diagram of the filtering table in the filter/trigger engine of FIG. 1;

[0015] FIG. 7 is a diagram of the filter/trigger engine state machine;

[0016] FIG. 8 is a flow chart of the operation of the filter/trigger engine according to principles of the invention; and,

[0017] FIG. 9 is a flow chart of the matching operation of the filter portion of the filter/trigger engine using the filter table of FIG. 6; and

[0018] FIG. 10 is a flow chart of the matching operation of the trigger portion of the filter/trigger engine using the filter table of FIG. 6.

[0019] FIG. 1 is a block diagram of a cable modem head end system in a cable modem network implementing a protocol analyzer according to principles of the invention. FIG. 1 shows a chassis 10 having a Cable Modem Termination System (CMTS) card 15 and a analyzer engine card 20 connected by a backplane 25. The CMTS card 15 has a capture engine 30, an encryption/decryption device 32, and a receiver/transmitter 35. The analyzer engine card 20 has a filter/trigger engine 40, an analyzer device 43, and a display unit 50. In alternate embodiments, the display processor 45 may also be external to the chassis.

[0020] The chassis 10 takes in signals over the cable modem network. The CMTS card 15 has 4 upstream channels 55 for downloading to cable modem users and 1 downstream channel 60 for uploading data from cable modem users. A chassis may have a plurality of CMTS cards and Analyzer cards. The receiver/transmitter 35 provides a data interface between the CMTS card 15 and the data channels 55, 60. Alternative embodiments of the CMTS card may have more upstream or downstream channels.

[0021] The capture engine 30 captures packets, that is, it collects data and the duplicates, encapsulates, and forwards all packets that meet a basic criteria. The criteria is defined by a pre-filter mechanism. The criteria may be all packets on an interface or it may be simply Protocol X packets from Node Y. The encryption/decryption engine handles the encryption of data to be transmitted downstream and the decryption of received packets upstream.

[0022] The filter/trigger engine 40 in the analyzer engine filters the data arriving from the capture engine 30. The analyzer device 43 performs statistical and heuristical analysis on the data. The display processor then processes the information for display.

[0023] Capture Engine

[0024] In the present embodiment of invention, the capture engine is a part of the embedded software running on each CMTS card in the chassis. The capture engine captures all data traffic on the receive and transmit paths of the CMTS card. The captured data also includes out-of-band data appropriate to the media, such as ranging power levels and minislot counts for CMTS (capture on an alternate media may include out-of-band data particular to that of the media type). The capture engine captures all data traffic, and for each captured packet, checks a capture flag. The capture engine time-stamps and sequence numbers captured packets. The capture engine then forwards the captured packets to the filter/trigger engine. The capture engine may also pre-filter the data based on some coarse level filter (e.g., capture only packets from channel X). The capture engine is implemented in the CMTS card in software.

[0025] The capture engine has three parameters which control is operation and can be programmatically set: a flag which operates as an on/off switch, a coarse-level filter(s) and a destination where captured packets will be delivered. Control over these values is presented in the display engine. The flag, also called the capture flag is set for a card or a port by the system administrator or user. The individual packets do not contain the capture flag. This enables the system to set the source of captured data through software and not through a physical tap on a signal line. Although the capture engine offers some level of filtering, the majority of the filtering must be done on the capture engine. The processes of the capture of transmit packets and receive packets are described as follows.

[0026] FIG. 2 is a flow chart of the process of capturing a receive packet by the capture engine. A receive packet arrives at the CMTS card, block 100. The capture engine determines if the capture flag is set, block 102. If the capture flag is not set, the packet is forwarded to its destination, block 104. If the capture flag is set, the capture engine applies a pre-filter, block 106. If the packet does not pass through the pre-filter, the packet is forwarded to its destination, block 104. If the packet passes the pre-filter, the packet is copied into a buffer in the capture engine and the original is forwarded to its destination, block 107. The capture engine then prepends RF demodulation out-of-band data, block 108. The out-of-band data is provided by the chipset that received the packet. The out-of-band data is based on measurements made a the time the packet was received. The capture engine then adds an encapsulation header to the copied packet, block 110. The capture engine then adds a switching header, block 112. The reformatted packet is then forwarded to the analyzer engine, block 114.

[0027] FIG. 3 is a flow chart of the process of capturing a transmit packet by the capture engine. When a transmit packet arrives at the CMTS card, the packet is copied into a buffer and enqueued for transmit on the downstream channel, block 120. After transmission, the packet is forwarded to the capture engine. The capture engine checks to determine whether the capture flag is set, block 122. The capture flag is set on the CMTS card and not on individual data packets. The capture flag is set by the system administrator. If the capture flag is not set, the packet is not captured and the capture process ends for that packet, block 124. If the capture flag is set, the capture engine applies a pre-filter, block 126. If the packet does not pass the pre-filter, the capture process ends for that process, block 124. The capture engine then adds an encapsulation header, block 128, and then a switching header, block 130. The switching header is for transferring the captured data from the CMTS card to the analyzer engine through the backplane. Transfer of data over the backplane is disclosed in a related patent application Ser. No. 09/566,540 filed May 8, 2000 and titled, System Having a Meshed Backplane and Process of Transferring Data Therethrough. The capture engine then sends the reformatted packet to the analyzer engine, block 132.

[0028] FIG. 4 is a block diagram of the copied packet 150 with the encapsulation header. Captured data 152 is encapsulated with both an encapsulation header 153, and a switching layer header 154 (which contains the destination address for the data). The encapsulation header stores data that indicates which direction the captured data was going, the device on which the data was capture, the time of capture and a sequence number indicating relative order of capture in comparison to other captured packets on the same device. In the present embodiment of the invention, the sequence number and the time stamp are particular to the device. In alternative embodiments of the invention, the sequence number and the time stamp may be chassis-wide.

[0029] The elements of the captured packet with the encapsulation header are as follows:

[0030] Destination Chassis 155 and Destination Slot 160 are the values assigned during the protocol analyzer startup.

[0031] Next Hop IP 165 is not used and can be set to 0.

[0032] Data Type 170 is BAS_ENCAPSULATED_PKT (11).

[0033] Source Chassis 175, Source Slot 180 and Source Port 185 identify the card (and CPU) that captured this packet.

[0034] Interface Number 190 specifies which connection port the data was captured from. Interfaces are numbered sequentially starting from 1; numbering is dependent upon the card type.

[0035] Interface Type 195 is a value to help simplify the decode and filter operations. It will have one of the following values:

[0036] ETHERNET (1)

[0037] SONET (2)

[0038] CMTS (3)

[0039] Path ID/Sequence Number 200 is a monatonic value that is unique only to this interface number. This may be used by the protocol analyzer to determine that frames were lost in the transfer between capture engine and the decode engine.

[0040] Timestamp 205 is used to time stamp when the packet was actually captured.

[0041] The capture engine uses the above described encapsulation to deliver the packet to the filter/trigger engine. The encapsulated packets are sent via the backplane 25 to the analyzer engine. If so required, the display engine can use the encapsulation sequence number to note that packets have been lost.

[0042] Filter/Trigger Engine

[0043] Data is collected and encapsulated with appropriate information and headers by the capture engine and forwarded to the filter/trigger engine. To allow for the greatest level of flexibility, this filtering/triggering process is accomplished using a set of rules arranged in a table. Each filter/trigger rule contains enough information to perform some basic comparison against the packet.

[0044] FIG. 5 is a block diagram of a rule 300. Each filter/trigger rule contains a set of parameters:

[0045] A rule type 305which specifies what portion of the packet will be used for the filter (e.g., a rule type of source IP address would indicate that the bytes of the packet that form the source address will be matched against the rule data)

[0046] A rule action 310which specifies what to do if the packet matches the rule (e.g., fail this match or proceed to the next rule; or a start or stop trigger action

[0047] Rule data 315data to which the packet data is compared;

[0048] Rule mask 320a value which dictates the portions of the packet data that are valid for this comparison; this allows for bit-level resolution of the data.

[0049] Each filter rule can be contained in a 16-byte element where 1 byte is reserved for the rule type, 1 byte is reserved for the rule action, 6 bytes are reserved for the rule data and 8 bytes are reserved for the rule mask (note that the rule mask is oversized only to pad the element out to an even power of 2 bits).

[0050] FIG. 6 is a diagram of a filter table 350. In order to build complex filters, a two dimensional filter table is constructed where rule elements in adjacent columns form a logical AND condition 355 and entire rows of the table form logical OR conditions 360. A complex filter expression can be described in such a table by fully expanding the expression such that it is a series of AND expressions connected by logical OR's. To illustrate: (Note: & is logical AND, is logical OR)

	Filter Expression	Expanded Expression	Filter Table
	A & B	A & B	Row 1: A B
	A B	A B	Row 1: A
			Row 2: B
	A & (B C)	(A & B)	Row 1: A B
		(A & C)	Row 2: A C
	A (B & C)	A (B & C)	Row 1: A
			Row 2: B C
	(A B) & (C D)	(A & C)	Row 1: A C
		(A & D)	Row 2: A D
		(B & C)	Row 3: B C
		(B & D)	Row 4: B D

[0051] Though there is an explicit limit to the length of the filter that can be built (i.e., the table dimensions), it is a fairly arbitrary length and reasonably long combinations can be constructed.

[0052] FIG. 7 is a diagram of the filter/trigger engine state machine. The filter/trigger engine can be described as a state machine with three states: STOPPED 400, ARMED 405, or TRIGGERED 410. In the STOPPED state, the filter/trigger engine is stopped and is not operating on packets. In the ARMED state, the filter/trigger engine has a defined trigger condition. In the TRIGGERED state, the filter/trigger engine has received a packet meeting the defined trigger condition and has been triggered.

[0053] The system administrator may initiate a transition from the ARMED state to the TRIGGERED state, transition 445, from the ARMED state to the STOPPED state, transition 415, the STOPPED state to the TRIGGERED state 420, and the TRIGGERED state to the STOPPED state 425.

[0054] When the filter/trigger engine is in the STOPPED state 400, all capture engine packets are discarded, The filter/trigger engine can be started without defining a start trigger, transition 420. In this case, the filter/trigger state moves directly to TRIGGERED, transition 420. When the filter/trigger engine is in the ARMED state 405, packets are compared against the filter table for a match. The system administrator defines the start triggers and arms the system, transition 440. A match marked as a start trigger will cause the filter/trigger engine state to be set to TRIGGERED, transition 430. Any other condition (a match to a stop trigger or no match at all) means that the packet is discarded. The engine can be forced from an ARMED to a TRIGGERED state by the user, transition 445. Likewise, the user can force a transition from ARMED to STOPPED, transition 415.

[0055] If the filter/trigger state is TRIGGERED, packets are compared against a trigger table to look for a stop trigger. If a stop trigger is matched, then the filter/trigger state is set to STOPPED, transition 435, and all further packets are discarded. If no match for a stop trigger is found, then the packet is further compared against the filter table for a match. Packets that have a match and whose rule is marked as pass are sent to the display engine. All other packets are discarded.

[0056] FIG. 8 shows the process of the filter/trigger engine. When a captured packet arrives, the filter/trigger engine first determines if it is in the STOPPED state, block 450. If it is in the STOPPED state, the packet is discarded, block 490. If it is not STOPPED<it determines if it is ARMED, block 455. If it is not ARMED<then the packet is compared to the filter table, block 475. If it is ARMED, the packet is compared to the trigger table, 460. If the engine is not triggered after this comparison, the packet is discarded, block 490. If the engine is triggered after this comparison, the filter/trigger engine again determines whether or not it is stopped, block 470. If it is stopped, the packet is discarded, block 490. If it is not stopped, the packet is compared to the filter table, block 475. From comparison to the filter table, the filter/trigger engine determines whether or not to drop the packet, block 480. If the packet is determined to be dropped, then the packet is discarded, block 490. If the packet is not to be dropped, the packet is passed to the display components for display, block 485.

[0057] FIGS. 9 and 10 show in detail the method used to compare packets against the filter and trigger rule tables, respectively.

[0058] Referring to FIG. 9, the filter engine starts at the first row, block 500. The filter engine then determines if all the rows in the filter table have been examined, block 505. If all the rows have been examined and no match has been found, the packet is discarded, block 510. If the all the rows have not been examined, the filter engine examines the first block in the row, block 515. If the entire row has been examined, block 520, the row number is increased by one, block 535, and the filter engine returns to block 505. If the entries in the row have not been examined, the filter engine applies the mask for the rule at the particular entry being examined, Row R, Column C, to the packet data, block 525. To apply a rule found at row R and column C, the following steps are used:

[0059] The rule type in rule (R, C) implicitly defines which bytes in the captured packet will be used for comparison.

[0060] The mask from the rule (R, C) is applied to the packet data to form masked data.

[0061] The masked data is compared against the rule data stored in rule (R, C), block 530.

[0062] If the masked data and rule data match, the rule action from rule (R, C) specifies the next action to take:

[0063] In the filter table:

[0064] An action of NEXT, block 560, means to advance to the next column, (R, C1), block 565.

[0065] An action of PASS, block 540, means to return a successful match and transfer the packet to the display engine, block 545.

[0066] An action of DROP, block 550, means to discard this packet and begin processing the next, block 555.

[0067] If the masked data and rule data do not match, the engine skips to the next row (rule (R1,1)), block 535.

[0068] Referring to FIG. 10, the trigger engine starts at the first row, block 500. The trigger engine then determines if all the rows in the trigger table have been examined, block 505. If all the rows have been examined and no match has been found, the packet is discarded, block 510. If the all the rows have not been examined, the trigger engine examines the first block in the row, block 515. If the entire row has been examined, block 520, the row number is increased by one and the trigger engine returns to block 505. If the entries in the row have no been examined, the trigger engine applies the mask for the rule at the particular entry being examined, Row R, Column C, to the packet data, block 525. To apply a rule found at row R and column C, the following steps are used:

[0069] The rule type in rule (R, C) implicitly defines which bytes in the captured packet will be used for comparison.

[0070] The mark from the rule (R, C) is applied to the packet data to form masked data.

[0071] The masked data is compared against the rule data stored in rule (R, C), block 530.

[0072] If the masked data and rule data match, the rule action from rule (R, C) specifies the next action to take:

[0073] In the trigger table:

[0074] An action of NEXT means to advance to the next column (R, C1).

[0075] An action of START means to return a successful match and move the filter/trigger state to TRIGGERED.

[0076] An action of STOP means to move the filter/trigger state to STOPPED.

[0077] If the masked data and rule data do not match, the engine skips to the next row (rule (R1,1)), block 535.

[0078] Display Engine:

[0079] In the present embodiment of the invention a commercial display engine is used and the ability to parse switching headers (BAS headers), internal protocols and CMTS MAC frames are added. In the present embodiment of the invention, the decode engine is the AG Group Etherpeek application.

[0080] Decodes

[0081] The recognized set of decodes will be substantially added to. EtherPeek defines a decode language of sorts that allows for this extensibility. Within this scope the following messages are decoded:

[0082] UCDUpstream Channel Descriptor messages

[0083] MAPMap messages

[0084] RNG_REQ/RSPRanging messages

[0085] REG_REG/RSP/ACKRegistration messages

[0086] UCC_REQ/RSPUpstream Channel Change messages

[0087] BPKM_REQ/RSPBaseline Privacy Key Management messages

[0088] DSA_REQ/RSP/ACKDynamic Service Addition messages

[0089] DSC_REQ/RSP/ACKDynamic Service Change messages

[0090] DSD_REQ/RSPDynamic Service Deletion messages

[0091] Fragmented packetspackets which have been split (or fragmented) into smaller units to facilitate transmission

[0092] Concatenated packetspackets which have been combined into a lager payload in order to facilitate transmission

[0093] Bandwidth Request packetsmessages which request additional upstream bandwidth for future transmissions

[0094] Encapsulated dataData units (such as email, web pages, digital video, etc) that are conveyed to and from a users cable modem.

[0095] The following messages are recognized but not decoded:

[0096] TRI_TCD/TSITelco return messages.

[0097] It is to be understood that the above-described embodiments are simply illustrative of the principles of the invention. Various and other modifications and changes may be made by those skilled in the art that will embody the principles of the invention and fall within the spirit and scope thereof.