`
`CORRECTED
`VERSION*
`
`PCT
`
`
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`lntemauonal Bureau
`
`
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(51) International Patent Classification 6 1
`H04L 12/00
`
`(11) International Publication Number:
`
`WO 97/23076
`
`(43) International Publication Date:
`
`26 June 1997 (26.06.97)
`
`Los Angeles, CA 90071-2066 (US).
`
`(21) International Application Number:
`
`PCT/US96/20779
`
`-
`
`(22) International Filing Date:
`
`13 December 1996 (13.12.96)
`
`(81) Designated States: AU, CA, CN, IL, JP, MX, SG, European
`patent (AT, BE, CH, DE, DK, ES, FI, FR, GB. GR, IE, IT,
`LU, MC, NL, PT, SE).
`
`(30) Priority Data:
`08/575,506
`
`20 December 1995 (20.12.95)
`
`US
`
`(71) Applicant: N B NETWORKS [US/US]; 7 Argonaut, Aliso
`Viejo, CA 92656 (US).
`
`(72) lnventors: BAKER, Peter, D.; 36 Blackbird Lane, Aliso Viejo,
`CA 92656 (US). NEAL, Karen; 1326 Saltair Avenue #6,
`Los Angeles, CA 90025 (US).
`
`(74) Agents: BROGAN, James, P. et a1.; Lyon & Lyon L.L.P., First
`Interstate World Center, Suite 4600, 633 West Fifth Street,
`
`Published
`With international search report.
`Before the expiration of the time limit for amending the
`claims and to be republished in the event of the receipt of
`amendments.
`
`(54) Title: SYSTEM AND METHOD FOR GENERAL PURPOSE NETWORK ANALYSIS
`
`STORAGE
`
`’I\-/ 74
`
`
`
`
`
`
`PROTOCOL
`
`‘.
`'NPUT
`DESCRIPTION
`OUTPUT
`iDEVlCES
`FILES
`DEVICES
`
`
`
`78
`
`
`
`NETWORK DEVICE
`CONTROL
`LOGIC
`
`
`
`‘—‘—_—J\/
`
`I 6
`
`(57) Abstract
`
`.A network interface system and related methods. A single logic control module, which may be implemented in hardware or software,
`.
`‘
`15 utIlIzed to perform any of a number of data manipulation functions including, for example, parsing, filtering, data generation or analysis,
`based upon one or more programmably configurable protocol descriptions which may be stored in and retrieved from an associated memory.
`
`. (Referred to in PCT Gazette No. 44/1997, Section II)
`
`NOAC EX. 1013 Page 1
`
`1
`
`1
`
`NOAC Ex. 1013 Page 1
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international
`applications under the PCT.
`
`AM
`AT
`AU
`BB
`
`BF
`3G
`8.]
`BR
`BY
`CA
`CF
`CG
`
`CI
`CM
`CN
`CS
`CZ
`DE
`DK
`EE
`ES
`Fl
`FR
`GA
`
`Armenia
`Austria
`Australia
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`COte d'lvoire
`Cameroon
`China
`Czechoslovakia
`Czech Republic
`Germany
`Denmark
`Estonia
`Spain
`Finland
`France
`Gabon
`
`Viet Nam
`
`United Kingdom
`Georgia
`Guinea
`Greece
`Hungary
`lreland
`Italy
`Japan
`Kenya
`Kyrgystart
`Democratic People‘s Republic
`of Korea
`Republic of Korea
`Kazakhstan
`Liechtenstein
`Sri Lanka
`Liberia
`Lithuania
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`Mali
`Mongolia
`Mauritania
`
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Singapore
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tajikistan
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`
`NOAC EX. 1013 Page 2
`
`2
`
`NOAC Ex. 1013 Page 2
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`l
`
`W
`
`m
`
`d
`
`Pur
`
`se
`
`rk
`
`Igghnigal Eield
`
`The
`
`present
`
`invention
`
`relates
`
`to
`
`network
`
`communications
`
`systems and,
`
`in particular,
`
`to improved
`
`systems and methods for parsing, filtering, generating and
`
`analyzing data composed of inter-related structures such
`
`as protocols found within network frames.
`
`W E
`
`xisting network interface devices provide systems
`
`for
`
`receiving,
`
`analyzing,
`
`filtering and
`
`transmitting
`
`network data or
`
`frames of data.
`
`Network Protocol
`
`Analyzers, Bridges, and Routers are among the most common
`
`network interface devices currently available.
`
`Conventional network protocol analyzers provide, for
`
`a predefined set of network frame structures or protocols,
`
`a system for monitoring the activity of a network and the
`
`stations on it by allowing network traffic to be captured
`
`and stored for
`
`later analysis.
`
`Common capture
`
`and
`
`analysis capabilities include the gathering of statistics,
`
`subsequent report generation,
`
`the ability to filter frames
`
`based on specific criteria, and the ability to generate
`network traffic.
`
`Bridges and routers are network devices that pass
`frames from one network interface to another.
`Bridges
`
`operate at the data—link layer and routers at the network
`
`Like protocol
`reference model.
`the OSI
`of
`layer
`analyzers, both bridges and routers may gather statistics
`
`and filter incoming network frames based on specific
`criteria, however incoming frames also may be forwarded to
`
`10
`
`15
`
`20
`
`25
`
`30
`
`other networks based on information collected by the
`bridge or
`router.
`Routers
`typically'
`support only a
`limited number of network protocols.
`
`NOAC EX. 1013 Page 3
`
`3
`
`3
`
`NOAC Ex. 1013 Page 3
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`2
`
`Each of these network devices requires an ability to
`
`separate network frames
`
`into individual protocols and
`
`their components
`
`(typically referred to as parsing),
`
`an
`
`ability to filter incoming frames based on a
`
`logical
`
`combination of one or more field values extracted during
`
`parsing, and an ability to gather statistics based in part
`
`on extracted field values. Typically, it is a requirement
`
`that network frames be received, analyzed and forwarded at
`
`full network speeds, sometimes on many different networks
`
`10
`
`at one time.
`
`A frame filter consists of one or more criteria which
`
`specify one or more valid values for a frame (or segments
`
`of
`
`a
`
`frame).
`
`Frame
`
`filtering criteria are typically
`
`implemented using an offset
`
`(from frame or protocol header
`
`15
`
`start),
`
`a length in bits which defines a field,
`
`a value
`
`for comparison, and mask values for identifying relevant
`
`and irrelevant bits within the field.
`
`For multiple value
`
`filter criteria,
`
`the result
`
`from each filter value is
`
`logically' OR'ed together
`
`to obtain an overall
`
`result.
`
`20
`
`Therefore, each additional result adds to the processing
`
`required,
`
`to filter a given field.
`
`For filtering on
`
`optional protocol fields that do not occur at
`
`the same
`
`relative offset
`
`in each protocol
`
`frame,
`
`this method is
`
`time-consuming.
`
`Thus,
`
`it would be desirable to perform
`
`25
`
`filtering on both fixed and optional variable offset
`
`fields for any number of
`
`'values or
`
`ranges of values
`
`without incurring any additional overhead.
`
`Parsing,
`
`the process wherein network frames are
`
`broken up into their individual protocols and fields,
`
`is
`
`3O
`
`necessary for filtering with offsets relative to protocol
`
`headers, gathering field based statistics, generating
`
`network traffic,
`
`routing data frames, verifying field
`
`values, and displaying network frames in human readable
`
`form.
`
`In conventional systems,
`
`the parsing process has an
`
`35
`
`overall structure which incorporates control
`logic for
`each supported protocol.
`Therefore, additional control
`logic must be developed when support for a new protocol is
`
`NOAC EX. 1013 Page 4
`
`4
`
`4
`
`NOAC Ex. 1013 Page 4
`
`

`

`WO 97/23076
`
`PCTIUS96/20779
`
`3
`
`added to a conventional system.
`
`As
`
`the development of
`
`additional control logic, whether implemented in hardware
`
`or software, may be both time consuming and expensive, it
`
`would be highly desirable to be
`
`able
`
`to parse all
`
`protocols with
`
`a
`
`single
`
`configurable
`
`software
`
`(or
`
`hardware) module so that support for additional protocols
`
`could be added to a system without requiring substantial
`
`modification to the system or its control logic.
`
`Further, although microprocessors (or
`
`CPUs) avail-
`
`able today can execute tens or even hundreds of millions
`
`of
`
`instructions per second, vendors often must provide
`
`dedicated hardware assistance and/or front-end processors
`
`with hand-coded assembly language routines to achieve the
`
`necessary processing rates for more
`
`than. one pair of
`
`networks. Unfortunately,
`
`this solution requires hardware
`
`and/or software modifications whenever changes are made to
`
`the number of supported features or protocols.
`
`Finally, as networks become larger and more complex,
`
`the maintenance of a comprehensive statistics database by
`
`each network device becomes more important. Because these
`
`statistics databases
`
`typically are not utilized by a
`
`maintaining device, but instead are collected by a network
`
`management device,
`
`the collection process may affect
`
`performance adversely without any corresponding benefit to
`
`10
`
`15
`
`20
`
`25
`
`the collecting device.
`
`In light of the considerations discussed above, it is
`
`believed that a network interface system having a con—
`
`figurable protocol analysis capability with common control
`
`logic applicable to many different network devices would
`
`30
`
`be highly desirable.
`
`W T
`
`he present invention is directed to improved systems
`
`and methods
`
`for parsing,
`
`filtering,
`
`generating and
`
`analyzing data (or frames of data)
`
`transmitted over a data
`
`35
`
`communications network.
`
`In one particularly innovative
`
`aspect of the present
`
`invention, a single logic control
`
`NOAC EX. 1013 Page 5
`
`5
`
`5
`
`NOAC Ex. 1013 Page 5
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`4
`
`module, which may be implemented in hardware or software,
`
`is utilized to perform any
`
`of
`
`a
`
`number
`
`of
`
`data
`
`manipulation functions (for example, parsing, filtering,
`data generation or analysis functions) based upon one or
`
`more programmably configurable protocol descriptions which
`
`may be stored in and retrieved from an associated memory.
`
`The use of common control
`
`logic (i.e.
`
`the use of a
`
`single logic control module) and programmably configurable
`
`protocol descriptions allows changes to existing protocols
`
`to be made and support for new protocols to be added to a
`
`system in accordance with the present
`
`invention through
`
`configuration only -— without the need for hardware and/or
`
`software system modifications. Thus,
`
`those skilled in the
`
`art will appreciate that a network interface in accordance
`
`with
`
`the present
`
`invention may
`
`be
`
`configured
`
`and
`
`reconfigured, if necessary,
`
`in a highly efficient and cost
`
`effective manner to implement numerous data manipulation
`
`functions and to accommodate substantial network modifica-
`
`tions (for example,
`
`the use of different data transmission
`
`hardware,
`
`protocols
`
`or
`
`protocol
`
`suites)
`
`without
`
`necessitating substantial system changes.
`
`10
`
`15
`
`20
`
`In one preferred form,
`
`the system of
`
`the present
`
`invention may employ a CPU or other hardware implementable
`
`method for analyzing data from a network in response to
`
`25
`
`selectively programmed parsing,
`
`filtering,
`
`statistics
`
`gathering, and display requests. Moreover,
`
`the system of
`
`the present
`
`invention may be incorporated in a network
`
`device,
`
`such as a network analyzer, bridge,
`
`router, or
`
`traffic generator,
`
`including a CPU and a plurality of
`
`3O
`
`input devices,
`
`storage devices,
`
`and output devices,
`
`wherein frames of network data may be received from an
`
`associated network,
`
`stored in the storage devices,
`
`and
`
`processed by the CPU based upon one or more programmably
`
`configurable protocol descriptions also stored in the
`
`35
`
`storage devices.
`
`The protocol descriptions may take the
`
`form of one or more protocol description files for each
`
`supported network protocol and may include a protocol
`
`NOAC EX. 1013 Page 6
`
`6
`
`6
`
`NOAC Ex. 1013 Page 6
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`5
`
`header record and plurality of field sub—records having
`
`data corresponding to an associated protocol and fields
`
`defined therein.
`
`The system of the present
`
`invention also preferably
`
`includes logic for extracting field values from particular
`
`network frames, performing validation and error checking,
`
`and making parsing decisions based upon field values and
`
`information in the programmably configurable protocol
`
`descriptions.
`
`The system of the present
`
`invention also preferably
`
`includes logic for filtering a subset of network frames
`
`received from the input or storage devices which satisfy
`
`a filter criteria based upon information defined in the
`
`programmably configurable protocol descriptions.
`
`The system of the present
`
`invention also preferably
`
`includes logic for filtering network frames which satisfy
`
`a plurality of filter criteria which,
`
`if desired, may be
`
`joined together by Boolean operators.
`
`The system of the present
`
`invention also preferably
`
`includes logic for analyzing a filter request by breaking
`
`the request
`
`into its component criteria to determine
`
`whether
`
`the result
`
`from evaluating a particular filter
`
`request criteria when combined with results from earlier
`
`criteria can be used to filter (i.e. discard) a particular
`
`10
`
`15
`
`20
`
`25
`
`network frame.
`
`The system of the present
`
`invention also preferably
`
`includes
`
`logic
`
`for collecting statistics based upon
`
`extracted field values satisfying a statistics criteria
`
`based upon information defined in the programmably con-
`
`figurable protocol descriptions.
`
`The system of the present
`
`invention also preferably
`
`includes logic for determining a next protocol description
`
`structure required to continue analyzing a network frame.
`
`The system of the present
`
`invention also preferably
`
`includes
`
`logic
`
`for determining a
`
`frame
`
`length and
`
`individual protocol header lengths from extracted field
`
`values in a network frame.
`
`3O
`
`35
`
`NOAC EX. 1013 Page 7
`
`7
`
`7
`
`NOAC Ex. 1013 Page 7
`
`

`

`WO 97/23076
`
`PCT/US96/ZO779
`
`6
`
`The system of the present
`
`invention also preferably
`
`includes logic for making routing decisions based upon
`
`information contained le the programmably configurable
`
`protocol descriptions.
`
`The system of the present
`
`invention also preferably
`
`includes logic for determining display formats based on
`
`information contained le the programmably configurable
`
`protocol descriptions.
`
`The system of the present
`
`invention also preferably
`
`includes logic for verifying individual field values and
`
`making parsing decisions based on the validity of
`
`the
`
`value.
`
`The system of the present
`
`invention also preferably
`
`includes logic for constructing and transmitting network
`
`frames with varying field contents based on information
`
`contained
`
`in the
`
`programmably
`
`configurable protocol
`
`10
`
`15
`
`descriptions.
`
`The system of the present
`
`invention may be employed
`
`in any system where it is useful to be able to examine and
`
`20
`
`perform various operations on contiguous bit-fields in
`
`data structures, wherein each data structure is composed
`
`of predefined fields of one or‘ more contiguous bits.
`
`Further,
`
`the
`
`system of
`
`the
`
`present
`
`invention
`
`is
`
`particularly efficient where operations must be performed
`
`25
`
`on a subset of included fields.
`
`Those skilled in the art will
`
`recognize that
`
`the
`
`system of the present invention gains a distinct advantage
`
`in size and maintainability over conventional network
`
`devices by implementing analysis capabilities for multiple
`
`30
`
`known and unknown protocols using common control
`
`logic.
`
`Furthermore,
`
`the systenl gains a (distinct advantage in
`
`speed and efficiency over conventional network devices
`
`when the control
`
`logic is implemented in hardware or a
`
`front-end processor, without
`
`incurring the penalty of
`
`35
`
`additional
`
`hardware
`
`and/or
`
`software
`
`development when
`
`protocol definitions change.
`
`NOAC EX. 1013 Page 8
`
`8
`
`8
`
`NOAC Ex. 1013 Page 8
`
`

`

`W0 9703076
`
`PCTlUS96/20779
`
`7
`
`Accordingly, it is an object of the present invention
`
`to provide an improved system for network analysis wherein
`
`the
`
`system may determine which protocols
`
`and which
`
`protocol fields exist
`
`in a network frame (also referred
`
`herein as parsing) using common control
`
`logic combined
`
`with configurable protocol descriptions.
`
`It is yet another object of the present invention to
`
`provide an improved system for network analysis wherein
`
`the control
`
`logic may be implemented in hardware as well
`
`10
`
`as software.
`
`It is yet another object of the present invention to
`
`provide an improved system for network analysis wherein
`
`each supported analysis capability is configurable even
`
`when the control logic is implemented in hardware.
`
`It
`
`is another object of
`
`the present
`
`invention to
`
`provide an improved system for network analysis wherein
`
`the systenl may' determine whethex‘
`
`a, particular network
`
`frame includes a field that satisfies a particular filter
`
`criteria based upon information stored in a programmably
`
`configurable protocol description.
`
`It is yet another object of the present invention to
`
`provide an improved system for network analysis wherein
`
`the system may determine if a particular network frame
`
`includes a protocol
`
`field that satisfies a. particular
`
`statistics gathering criteria defined in a programmably
`
`configurable protocol description.
`
`It is yet another object of the present invention to
`
`provide an improved system for network analysis wherein
`
`the system may generate network traffic in the form of
`
`frames constructed from selected protocol descriptions
`
`with the ability to specify a variety of methods
`
`for
`
`varying individual field values.
`
`It is still another object of the present
`
`invention
`
`to provide an improved system for network analysis wherein
`
`the
`
`system may
`
`route network
`
`frames
`
`(determine
`
`the
`
`appropriate
`
`destination
`
`interface)
`
`that
`
`satisfy
`
`a
`
`particular‘
`
`routing criteria defined in a programmably
`
`15
`
`20
`
`25
`
`3O
`
`35
`
`NOAC EX. 1013 Page 9
`
`9
`
`9
`
`NOAC Ex. 1013 Page 9
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`8
`
`configurable protocol description while providing
`
`a
`
`capability to specify a variety of methods for varying
`
`individual field values during the routing process.
`
`It is still another object of the present
`
`invention
`
`to provide an improved system for network analysis wherein
`
`the system may determine if a particular network frame
`
`includes a protocol field that contains a value related to
`
`either the overall
`
`length of
`
`the frame or the current
`
`protocol header length.
`
`10
`
`E'EI
`
`'I'
`
`:EIJL .
`
`Fig.
`
`l
`
`is a block diagram of a network interface
`
`system in accordance with one
`
`form of
`
`the present
`
`invention.
`
`Fig.
`
`2
`
`is a diagram representing a set of data
`
`15
`
`records of a typical network frame which may be contained
`
`in the data
`
`files of
`
`the network interface system
`
`illustrated in Fig. 1.
`
`Fig.
`
`3
`
`is a diagram representing a set of data
`
`records of a protocol description in accordance with one
`
`20
`
`form of the present invention.
`
`Fig. 4 is a diagram representing a control record of
`
`an Ethernet protocol description which may be utilized in
`
`a network interface system in accordance with one form of
`
`the present invention.
`
`25
`
`Fig. 4a is a diagram representing five defined field
`
`sub—records
`
`of
`
`the
`
`Ethernet
`
`protocol
`
`description
`
`illustrated in Fig. 4.
`
`Figs. 4b, 4c, and 4d are diagrams representing lockup
`
`structures referenced in Fig.
`
`4a
`
`fields 0,
`
`2
`
`and 4
`
`30
`
`respectively.
`
`Fig.
`
`5 is a diagram representing a control record of
`
`an imaginary Generic Protocol description which may be
`
`utilized in a network interface system in accordance with
`
`one form of the present invention.
`
`NOAC EX. 1013 Page 10
`
`10
`
`10
`
`NOAC Ex. 1013 Page 10
`
`

`

`WO 97/23076
`
`I
`
`PCT/US96/20779
`
`9
`
`Fig.
`
`5a
`
`is a diagranl representing eleven defined
`
`field sub-records of
`
`the GP description illustrated in
`
`Fig. 5.
`
`Figs. 5b, Sc, 5d, and Se are diagrams representing
`
`lookup structures referenced in Fig. 5(a) fields 1, 3,
`
`7
`
`and 8, respectively.
`
`Figs. 6, 6a,
`
`and 6b are diagrams representing the
`
`control
`
`record and
`
`field sub—record of
`
`a protocol
`
`description structure that allows parsing of optional
`
`fields of the GP description shown in Figs.
`
`5 - 5e.
`
`Figs. 7, 7a,
`
`and 7b are diagrams representing the
`
`control
`
`record and
`
`field sub—records of
`
`a protocol
`
`description structure that describes
`
`the End Of List
`
`option of the GP description shown in Figs.
`
`5 — Se.
`
`Figs. 8, 8a, and 8b are diagrams representing the
`
`control
`
`record and
`
`field sub—records of
`
`a protocol
`
`description structure that describes the No Operation
`
`option of the GP description shown in Figs.
`
`5 - Se.
`
`Figs. 9, 9a, and 9b are diagrams representing the
`
`control record and field records of a protocol description
`
`file that describes the Maximum Frame Size option of the
`
`GP description shown in Figs. 5 - 5e.
`
`Figs. 10, 10a, 10b, 10c, 10d and ice are diagrams
`
`representing data records of a filter expression control
`
`and associated field filter structures.
`
`Fig. 11 is a flow chart illustrating top level frame
`
`parsing control
`
`logic in accordance with one form of the
`
`present invention.
`
`Fig. 12 is a flow chart illustrating protocol parsing
`
`logic in accordance with one form of the present
`control
`invention.
`
`Fig. 13 is a flow chart of the field parsing control
`
`in accordance with one
`logic
`invention.
`
`form of
`
`the present
`
`Fig.
`
`14
`
`is
`
`a
`
`flow chart
`
`representing
`
`value
`
`verification, error checking, next protocol and branch
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`NOAC EX. 1013 Page 11
`
`11
`
`11
`
`NOAC Ex. 1013 Page 11
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`10
`
`determination control logic in accordance with one form of
`
`the present invention.
`
`Fig. 15 is a flow chart representing field filtering
`
`control
`
`logic in accordance with one form of the present
`
`invention.
`
`Fig.
`
`16
`
`is 21
`
`flow chart
`
`illustrating field value
`
`extraction and varying control
`
`logic in accordance with
`
`one form of the present invention.
`
`10
`
`Referring now to Fig. 1, a network interface system
`
`in accordance with one form of
`
`the present
`
`invention,
`
`generally referred to as 10, may be implemented in a
`
`network device including input devices 12, data storage
`
`devices 14, analysis control logic 16 for facilitating the
`
`>15
`
`input, storage, retrieval, and analysis of network frames,
`
`and output devices 18 for forwarding frames or displaying
`
`or" printing the results of analyses.
`
`A. data storage
`
`device 14 may include a data file 20 of network frames
`
`having n protocol data records, wherein each data record
`
`20
`
`contains data stored in a plurality of predefined fields.
`
`Protocol description files 22 also may be stored in the
`
`data storage device 14.
`
`The protocol description files 22
`
`may include a protocol control
`
`record and n field sub-
`
`records, which together may describe a subset of a network
`
`25
`
`protocol and include rules for analyzing that protocol.
`
`The network device control
`
`logic 16 is capable of
`
`retrieving a subset of network frames
`
`from the input
`
`devices 12 or data files 20 which satisfy one or more
`
`criteria based upon extracted field values and filtering
`
`30
`
`criteria contained in one or more
`
`of
`
`the protocol
`
`The network device control logic 16
`description files 22.
`also includes logic for determining frame and protocol
`
`header
`
`lengths, gathering statistics, verification and
`
`error checking, determining routes, varying values, and
`
`35
`
`formatting output.
`
`NOAC EX. 1013 Page 12
`
`12
`
`12
`
`NOAC Ex. 1013 Page 12
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`11
`
`A personal computer or conventional network device,
`
`such as an IBM PC (or compatible), Apple Macintosh®, or
`
`any Unix®, or Zenix® workstation, protocol analyzer,
`
`bridge, router,
`
`traffic generator, or similar system may
`
`be utilized in accordance with the system of the present
`
`invention.
`
`The data input devices 12 may comprise any of
`
`a number of
`
`commercially available network interface
`
`devices and may include a conventional keyboard or mouse
`
`if required.
`
`The data storage devices 14 may take the
`
`form of any of a number of commercially available data
`
`storage options (such as RAM, ROM, EPROM, or various sized
`
`fixed disk drives), and the data output devices 18 may
`
`comprise any of a number of commercially available user
`
`interface devices, such as CRT displays, monitors, network
`
`interface devices and/or printers
`
`(if
`
`required).
`
`The
`
`analysis control logic 16 may be implemented as a computer
`
`program. written in any language suitable for
`
`systems
`
`programming or may be implemented in hardware if better
`
`performance is required.
`
`In one presently preferred form,
`
`the analysis control
`
`logic 16 may be implemented via the
`
`programming files set
`
`forth in the attached Appendix,
`
`which is herein incorporated by reference. However,
`
`those
`
`skilled in the art will appreciate that
`
`the analysis
`
`control
`
`logic 16 ndght equivalently be implemented in
`
`dedicated hardware using,
`
`for
`
`example,
`
`one or more
`
`application specific integrated circuits ("ASICS") or one
`
`or more field programmable gate arrays ("FPGAs").
`
`The network interface system 10 of
`
`the present
`
`invention is preferably implemented
`
`on
`
`a
`
`personal
`
`computer, workstation or
`
`conventional network device
`
`having a
`
`32—bit or
`
`larger bus
`
`and register set,
`
`an
`
`optional math co-processor, at
`
`least one megabyte of
`
`available RAM, and for personal computer and workstation
`
`applications, a fixed disk having at least 10 megabytes of
`
`available storage space.
`
`As
`
`shown
`
`in the attached
`
`Appendix,
`
`the analysis control logic 16 may be programmed
`
`in the C++ language, with abstract data types defined for
`
`NOAC EX. 1013 Page 13
`
`13
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`13
`
`NOAC Ex. 1013 Page 13
`
`

`

`wo 97123076
`
`'
`
`PCT/US96/20779
`
`12
`
`statistics gathering, value verification, next protocol
`
`determination, filtering, varying values, checksumming and
`
`route determination capabilities, and protocol control and
`
`field records.
`
`5
`
`Referring now to Fig. 2, a data file 20 in accordance
`
`with. one
`
`forn1 of
`
`the present
`
`invention. may include a
`
`plurality (n) of protocol header data records and optional
`
`Data and Pad records.
`
`Each protocol record contains data
`
`organized into a plurality of predefined fields.
`
`Each
`
`10
`
`field comprises a collection of 1 or more contiguous bits
`
`and includes a set of valid values for that field.
`
`For
`
`example, a particular protocol specification might include
`
`ea
`
`6 bit header
`
`length field that
`
`limits the protocol
`
`header
`
`length to values between 20
`
`and 60
`
`inclusive,
`
`15
`
`thereby excluding values less than 20 and values from 61
`
`to 64.
`
`The number of possible contiguous bit fields for a
`
`protocol header of length N bits where N is greater than
`
`1 can be expressed by the following formula:
`N
`21'
`1:1
`
`Number of Possible Fields =
`
`20
`
`It will be appreciated by those skilled in the art that
`
`any possible organization of
`
`fields for any possible
`
`protocol specification is contemplated for
`
`the network
`
`interface system 10 of the present invention.
`
`25
`
`Referring now to Fig. 3, a protocol description file
`
`22 in accordance with one form of the present
`
`invention
`
`may include a protocol control record, and a plurality (n)
`
`of
`
`field data
`
`records.
`
`In a particularly preferred
`
`embodiment,
`
`the protocol control record (shown below in
`
`30 Table 1) may define the overall structure of a network
`
`protocol and reference other information relating to the
`
`network protocol.
`
`NOAC EX. 1013 Page 14
`
`14
`
`14
`
`NOAC Ex. 1013 Page 14
`
`

`

`WO 97/23076
`
`PCTfUS96/20779
`
`
`
`
`
`
`
`
`length of protocol name in bytes including NULL
`
`
`
`terminator
`
`5
`
`lo
`
`
`
`name of file control record is stored in
`
`total bit length of protocol header control record is
`
`describing
`
`
`
`
`-_‘
`--_|
`
`pointer to option control record to use if this
`
`
`
`
`
`
`15 Ml_ Wscificytin L ,
`
`
`
`
`
`protocol has optional fields
`
`
`
`
`The field records referenced at bytes 28-31 in the
`
`table above are preferably organized as shown in Table 2:
`
`TABLE 2
`
`F—V ’
`
`
`
`
`
`20
`
`
`
`
`flag indicating value is actual length of frame
`
`
`
`
`
`(multiplier)
`
`’ "W ' b” W’———rr—’ __,_.__.l______ "' “w ‘ "—‘——x—|
`
`
`
`-n byte offset from start of protocol header of 32—bit field
`
`
`
`containing value
`
`25
`
`
`
`NOAC EX. 1013 Page 15
`
`15
`
`
`
`
`15
`
`NOAC Ex. 1013 Page 15
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`l4
`
`
`number indicating a. display type (i.e., decimal, hex,
`
`.
`.
`. )
`
`
`flag indicating value is actual length of protocol header
`
`
`(multiplier)
`
`not used
`
`pad byte to align following fields
`
`multiplier to apply to value prior to display
`
`18
`
`{swap
`
`flag indicating the need to swap bytes and words in 32-
`
`
`
`bit field containing value
`
`
`
`
`}
`
`
`
`
`
`
`
`
`
`
`definition to use (O-none) I_
`m—_
`
`
`
`fsdspfield
`
`flag indicating that this field should be displayed
`
`pointer to configured statistics structure/class (Oxnone)
`
`28-31
`
`ptanp
`
`pointer to lockup structure/class . .. next protocol
`
`10
`
`
`
`The statistics records referenced in Table 2, above,
`
`15
`
`at bytes 24—27 are preferably organized as shown in Table
`
`3:
`
`
`
`STATISTICS STRUCTURE/CLASS RECORD
`
`
`
`
`
`-Jm
`
`
` 20
`pointer to user assigned name for statistic
`
`
`pointer to derived structure/class for accumulating
`
`configured statistic
`
`
`The next protocol
`
`lookup records referenced in the
`
`field sub-record table
`
`(Table
`
`2)
`
`at bytes 28-31 are
`
`preferably organized as shown in Table 4:
`
`NOAC EX. 1013 Page 16
`
`16
`
`16
`
`NOAC Ex. 1013 Page 16
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`TABLE 4
`
`
`15
`
`
`
`LOOKUP STRUCTURE RECORD
`
`pointer to protocol description structure
`
`
`
`
`
`
`
`
`
`-_
`
`
`
`_
`
`4-7
`
`Next Index
`
`index of field in protocol description to parse next
`
`10
`
`15
`
`Lookup structures can be used for determining the
`
`next protocol control record to use,
`
`terminating protocol
`
`processing on illegal values, branching decisions
`
`for
`
`variable length headers or overlapping fields,
`
`and for
`
`translation of numeric values
`
`to mnemonic or written
`
`language equivalents. This ability to specify branches on
`
`field values allows protocols with multiple overlapping
`
`structures to be specified and parsed dynamically.
`
`The vary field value records referenced in the field
`
`sub-record table (Table 2) at bytes 32—35 are preferably
`
`20
`
`organized as shown in Table 5:
`
`25
`
`minimum allowable value for field hits (relative to
`
`value to apply to field bits (relative to field)
`
`mask for isolating bits not in field
`
`NOAC EX. 1013 Page 17
`
`17
`
`17
`
`NOAC Ex. 1013 Page 17
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`16
`
`The checksum records referenced in the field sub-
`
`record table (Table 2) at bytes 36—39 are preferably
`
`organized as shown in Table 6:
`
`
`
`
`
`CHECKSUM RECORD
`L_M7
`Offse
`_-pointer to routine to verify protocol checksum
`
`-_ pointer to routine to compute protocol checksum
`
`
`
`
`
`
`
`
`
`
`The filter criteria records referenced in the field
`
`10
`
`sub—record table (Table 2) at bytes 40—43 are preferably
`
`organized as shown in Table 7:
`
`
`
`FILTER CRITERIA RECORD
`L
`1
`umindex of this filter criteria (zero--baaed)
`— ChPtr
`pointer to parent filter channel
`
`
`
`
`pointer to lookup structure containing all possible field
`
`values
`
`
`
`
`
`
`
`15
`
`
`
`-- pointer toassociatedprotocol definition for this
`
`
`criteria
`
`
`16- 19
`
`
`
`pointer to associated field definition for this criteria
`
`20
`
`The filter channel records referenced in the Filter
`
`Criteria record (Table 7)
`
`above at 4-7 are preferably
`
`organized as shown in Table 8:
`
`NOAC EX. 1013 Page 18
`
`18
`
`18
`
`NOAC Ex. 1013 Page 18
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`17
`
`TABLE 8
`
`FILTER CHANNEL RECORD
`
`
`
`extCriteriaI
` index of next criteria that should be applied to this
`ndex
`filter
`
` _ N
`
`i]
`
`
`
`
`
`
`
`
`
`TotalCriteria
`
`number of criteria required to implement this filter
`
`pointer to array of TotalCriteria criteria structures
`
`12-15
`
`
`
`
`ChannelName
`
`
`pointer to user supplied filter channel name
`
`
`
`Each configured filter consists of one or more filter
`
`criteria and the filter criteria may be organized into
`
`10
`
`Filter Criteria records.
`
`The Filter Criteria records may
`
`refer to lookup structures which allow the filter criteria
`
`to determine from a field value the current state of the
`
`filter expression at each criteria.
`
`These states may
`
`include:
`
`PASS_FRAME (accept this frame) and FILTER_FRAME
`
`15
`
`(discard this frame).
`
`The NextCriteriaIndex field referenced in Table 8
`
`above at bytes 0-3 is used to ensure that all filter
`
`expressions are applied in the required order.
`
`The Ptl
`
`and Fld fields at bytes 12-19 allow filter criteria to be
`
`associated with specific protocols and protocol fields.
`
`The
`
`lockup records
`
`referenced in the Filter Criteria
`
`record (Table 7) at bytes 8-11 are preferably organized as
`
`shown in Table 9:
`
`TABLE 9
`
`
`
`
`
`FILTER LOOKUP STRUCTURE RECORD
`
`20
`
`25
`
`
`
`
`Offset_
`
`
`
`
`Return
`
`Value
`
`PASS_FRAME, FILTER_FRAME value range result
`
`-“ index of field in Filter Expression structure
`
`12—15
`
`maximum accevtable value for this ran-e
`
`minimum acceptable value for this range
`
`NOAC EX. 1013 Page 19
`
`19
`
`
`
`
`
`
`
`
`30
`
`19
`
`NOAC Ex. 1013 Page 19
`
`

`

`WO 97/23076
`
`PCT/US96/20779
`
`18
`
`
`
`20—23
`
`
`
`
`pointer to associated human language equivalent
`
`selects EVEN, ODD or all values in range
`
`
`
`The Route Table records referenced in the Field Sub-
`
`Records table (Table 2) at bytes 44—47 are preferably
`
`5 organized as shown in Table 10:
`
`TABLE 10
`
`
`|ROUTE TABLE RECORD
`
`
`-Jm
`
`
`
`
`mask for extracting 1 to 96 bits from protocol header
`
`
`route field
`
`
`
`
`
`0-11
`
`NetMaak
`
`12-15
`
`
`16-19
`
`
`
`number of entries in Route Table
`
`
`pointer to