I 1111111111111111 1111111111 111111111111111 IIIII 11111 11111 111111111111111111
`US010652111B2
`
`c12) United States Patent
`Barsheshet et al.
`
`US 10,652,111 B2
`(IO) Patent No.:
`(45) Date of Patent:
`May 12, 2020
`
`(54) METHOD AND SYSTEM FOR DEEP PACKET
`INSPECTION IN SOFTWARE DEFINED
`NETWORKS
`
`(71) Applicant: ORCKIT IP, LLC, Newton, MA (US)
`
`(58) Field of Classification Search
`CPC . H04L 43/026; H04L 12/6418; H04L 43/028;
`H04L 49/70; H04L 69/161
`(Continued)
`
`(72)
`
`Inventors: Yossi Barsheshet, Ashdod (IL);
`Simhon Doctori, Gan-Yavne (IL);
`Ronen Solomon, Ranat-Gan (IL)
`
`(73) Assignee: ORCKIT IP, LLC, Dover, DE (US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 306 days.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`2010/0208590 Al*
`
`2010/0212006 Al
`
`8/2010 Dolganow ............ H04L 43/026
`370/235
`
`8/2010 Dolganow et al.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`
`(21) Appl. No.:
`
`15/126,288
`
`EP
`
`2672668 Al
`
`12/2013
`
`(22) PCT Filed:
`
`Apr. 21, 2015
`
`(86) PCT No.:
`
`PCT /US2015/026869
`
`§ 371 (c)(l),
`(2) Date:
`
`Sep. 15, 2016
`
`(87) PCT Pub. No.: WO2015/164370
`
`PCT Pub. Date: Oct. 29, 2015
`
`(65)
`
`Prior Publication Data
`
`US 2017/0099196 Al
`
`Apr. 6, 2017
`
`Related U.S. Application Data
`
`(60) Provisional application No. 61/982,358, filed on Apr.
`22, 2014.
`
`(51)
`
`Int. Cl.
`H04L 12126
`H04L 12164
`
`(2006.01)
`(2006.01)
`(Continued)
`
`(52) U.S. Cl.
`CPC ........ H04L 431028 (2013.01); H04L 1216418
`(2013.01); H04L 431026 (2013.01);
`(Continued)
`
`OTHER PUBLICATIONS
`
`Supplementary Search Report of EP 15783292 dated Nov. 7, 2017.
`(Continued)
`
`Jae Y Lee
`Primary Examiner -
`Jean F Voltaire
`Assistant Examiner -
`(74) Attorney, Agent, or Firm - May Patents Ltd. c/o
`Dorit Shem-Tov
`
`(57)
`
`ABSTRACT
`
`A method for deep packet inspection (DPI) in a software
`defined network (SDN). The method includes configuring a
`plurality of network nodes operable in the SDN with at least
`one probe instruction; receiving from a network node a first
`packet of a flow, the first packet matches the at least one
`probe instruction and includes a first sequence number;
`receiving from a network node a second packet of the flow,
`the second packet matches the at least one probe instruction
`and includes a second sequence number, the second packet
`is a response of the first packet; computing a mask value
`respective of at least the first and second sequence numbers
`indicating which bytes to be mirrored from subsequent
`packets belonging to the same flow; generating at least one
`(Continued)
`
`Application
`servers
`12ll
`
`Application
`servers
`12ll
`
`Application
`servers
`12ll
`
`1 0 0~
`
`Central Controller
`111
`
`t,)30
`
`130
`
`~
`
`IPtraffio
`
`~
`
`1
`
`IP traffic
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 15
`
`

`

`US 10,652,111 B2
`Page 2
`
`mirror instruction based on at least the mask value; and
`configuring the plurality of network nodes with at least one
`mirror instruction.
`
`54 Claims, 6 Drawing Sheets
`
`(51)
`
`(2013.01)
`(2013.01)
`(2006.01)
`
`Int. Cl.
`H04L 121851
`H04L 121931
`H04L 29106
`(52) U.S. Cl.
`CPC .......... H04L 4712483 (2013.01); H04L 49170
`(2013.01); H04L 69/161 (2013.01)
`( 58) Field of Classification Search
`USPC .......................................................... 370/389
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`2014/0052836 Al*
`
`2015/0124812 Al*
`
`2016/0020998 Al *
`
`2016/0197831 Al*
`
`2016/0219080 Al *
`
`2/2014 Nguyen ................ H04L 45/306
`709/223
`5/2015 Agarwal ................. H04L 45/24
`370/392
`1/2016 Bifulco ................... H04L 45/64
`370/235
`7/2016 De Foy ............... H04L 45/7453
`370/392
`7/2016 Huang .................... H04L 63/20
`
`OTHER PUBLICATIONS
`
`Seugwon Shin et al, "Fresco: Modular Composable Security Ser(cid:173)
`vices for Software-Defined Networks", NDSS Symposium 2013,
`Apr. 23, 2013, pp. 1-16 XP055422187.
`International Search Report of PCT/US2015/026869 dated Aug. 6,
`2015.
`Minlan Yu et al, "Scalable flow-based networking with DIFANE",
`Proceedings of the ACM SIGCOMM 2010 Conference on Appli(cid:173)
`cations, Technologies, Architectures, and Protocols for Computer
`Communications, New Delhi, India, Aug. 30-Sep. 3, 2010, ACM,
`pp. 351-362 XP058189957.
`
`2011/0264802 Al
`2013/0329764 Al
`
`10/2011 Dolganow et al.
`12/2013 Chesla et al.
`
`* cited by examiner
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 2 of 15
`
`

`

`U.S. Patent
`
`May 12, 2020
`
`Sheet 1 of 6
`
`US 10,652,111 B2
`
`Application
`servers
`120
`
`Application
`servers
`120
`
`Application
`servers
`120
`
`100~
`
`Central Controller
`111
`
`130
`
`~ IP traffic
`
`IP traffic
`
`140
`
`FIG. 1
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 15
`
`

`

`KEY 210
`
`(200
`
`DATA 220
`
`Client IP
`
`Server IP Client
`
`Server
`
`IP
`
`Flow Client+
`
`Server+
`
`state
`
`Creation
`
`Client+
`
`Server
`
`Client+
`
`Server+ Age
`
`address
`
`address
`
`source
`
`destination
`
`protocol
`
`ID
`
`Server
`
`TCP port
`
`number
`
`TCP
`
`port
`
`sequence
`
`number M
`
`Client
`
`sequence
`
`number N
`
`timestamp Server
`
`Hit counter X
`
`[bytes]
`
`Server
`
`data buffer
`
`Client
`
`buffer
`
`bit
`
`+
`Client
`
`Hit
`
`counter
`y
`
`[bytes]
`
`192.1.1.1
`
`209.1.4.4
`
`15431
`
`21
`
`6
`
`1
`
`0xf46d5c34
`
`0x3c98b9ab ACK
`
`15:32:13
`
`FIG. 2
`
`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`~
`~ ....
`
`N
`'"
`N
`0
`N
`0
`
`('D
`('D
`
`rJJ =(cid:173)
`.....
`N
`0 ....
`
`O'I
`
`d r.,;_
`"'""'
`--= 0--,
`
`UI
`N
`'"
`"'""'
`"'""'
`
`"'""' = N
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 4 of 15
`
`

`

`U.S. Patent
`
`May 12, 2020
`
`Sheet 3 of 6
`
`US 10,652,111 B2
`
`Engine .......
`
`DPI
`
`312
`
`TCP Flag
`
`I
`
`i
`I
`I
`I
`I
`I
`I
`I
`•
`
`(
`1 11
`
`e
`
`I
`I
`
`314
`
`I
`
`I 313
`
`l
`
`I
`I
`
`Mirror
`Packets
`
`I S304
`
`-
`
`DPI Flow Detection unit
`311
`J§)
`-
`@)
`
`-
`
`=-
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`.l
`
`J.
`
`S302
`
`e
`
`Probe Flow Module
`321
`
`e
`
`08
`
`-~
`
`t I
`
`323
`
`TCP sequence
`- - - - number bas~--------------,
`I
`I
`
`-
`-
`
`-
`-
`
`322
`
`324
`
`Probe sequence:
`counter
`
`s
`
`(
`112
`
`FIG. 3
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 5 of 15
`
`

`

`U.S. Patent
`
`May 12, 2020
`
`Sheet 4 of 6
`
`US 10,652,111 B2
`
`DPI
`Engine
`312
`
`~ -
`- -
`
`I
`I
`I
`I
`I
`I
`I
`TCP flags
`I
`flow creation I
`I
`...
`
`(
`1 11
`
`e
`
`-
`
`B
`
`I
`
`.l
`
`.1.
`
`DPI Flow Detection unit
`311
`
`s
`
`-
`
`~
`
`~
`
`-
`-
`
`-
`
`~
`
`I
`
`-
`
`-
`
`313
`
`314
`
`-
`
`s
`E2
`
`e
`
`Probe Flow Module
`321
`
`:::.
`
`S404
`
`-
`
`: I
`
`323
`
`TCP sequence
`
`---- number bass--------------,
`-
`I
`-
`
`~
`
`-
`
`322
`
`- - - - - - - ---------------i - - - - - - - - -•
`~----- ---------------- - - - - - ~. ---
`(
`112
`
`Probe sequence
`counter
`
`324
`
`FIG. 4
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 6 of 15
`
`

`

`U.S. Patent
`
`May 12, 2020
`
`Sheet 5 of 6
`
`US 10,652,111 B2
`
`501 {
`
`Match fields
`MASK (filed 1 , ... , )
`
`Priority
`Instruction
`Highest Go to probe table , - -
`
`(
`
`500
`
`Probe table 51 0
`
`--
`
`511
`
`{
`
`Priority
`Ins truction
`Hi hest Go ton
`....
`ext table ID
`g
`,
`,
`<srclP destlP
`>
`1 - -__ <_sr_c_lP.....:,_d_e_s_tl_P..:...., _ .. _ .. _> _____ H.....:ig::....h_es_t __ G_o_to_n_e_xt_t_a_bl_e_l__.D
`
`511 {
`
`512 {
`
`<srclP, destlP, .... >
`<srclP, destlP, .... >
`MASK (filed 1 , ... , )
`MASK (filed 1, ... , )
`
`Highest Go to next table ID
`Highest Go to next table ID
`Medium Output: controller
`Medium I Output: controller
`
`513 {
`
`l~ ___ M_A_S_K_a_ll _fie_l_ds ___ ____,_ __ lo_w___.l._G_o_to_n_e_x_t _ta_b_le_l_D___.
`
`FIG. 5
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 7 of 15
`
`

`

`U.S. Patent
`
`May 12, 2020
`
`Sheet 6 of 6
`
`US 10,652,111 B2
`
`600
`j
`
`Start
`
`S610
`Configure nodes with a set of probe
`instructions
`
`S620
`Receive a first TCP packet with FLAG
`SYN=1 and a sequence number M
`
`S630
`Receive a first TCP packet with FLAG
`ACK=1 and a sequence number N
`
`S640
`Compute a mask value
`
`S650
`
`Generate and send mirroring instructions
`to nodes
`
`Inspect received mirrored bytes using DPI
`
`S660
`
`No
`
`S680
`
`Remove related exiting flows from flow table
`
`FIG. 6
`
`END
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 8 of 15
`
`

`

`US 10,652,111 B2
`
`1
`METHOD AND SYSTEM FOR DEEP PACKET
`INSPECTION IN SOFTWARE DEFINED
`NETWORKS
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`This application claims the benefit of U.S. provisional
`application No. 61/982,358 filed on Apr. 22, 2014, the
`contents of which are herein incorporated by reference.
`
`TECHNICAL FIELD
`
`This disclosure generally relates to techniques for deep
`packet inspection (DPI), and particularly for DPI of traffic in
`cloud-based networks utilizing software defined networks.
`
`BACKGROUND
`
`Deep packet inspection (DPI) technology is a form of
`network packet scanning technique that allows specific data
`patterns to be extracted from a data communication channel.
`Extracted data patterns can then be used by various appli(cid:173)
`cations, such as security and data analytics applications. DPI
`currently performs across various networks, such as internal
`networks, Internet service providers (ISPs), and public net(cid:173)
`works provided to customers. Typically, the DPI is per(cid:173)
`formed by dedicated engines installed in such networks.
`A software defined networking is a relatively new type of
`networking architecture that provides centralized manage(cid:173)
`ment of network nodes rather than a distributed architecture
`utilized by conventional networks. The SDN is prompted by
`an ONF (open network foundation). The leading communi(cid:173)
`cation standard that currently defines communication
`between the central controller (e.g., a SDN controller) and
`the network nodes (e.g., vSwitches) is the OpenFlow™
`standard.
`Specifically, in SDN-based architectures the data forward(cid:173)
`ing (e.g. data plane) is typically decoupled from control
`decisions ( e.g. control plane), such as routing, resources, and
`other management functionalities. The decoupling may also
`allow the data plane and the control plane to operate on
`different hardware, in different runtime enviromnents, and/
`or operate using different models. As such, in an SDN
`network, the network intelligence is logically centralized in
`the central controller which configures, using Open Flow
`protocol, network nodes and to control application data
`traffic flows.
`Although, the OpenFlow protocol allows addition of
`programmability to network nodes for the purpose of pack(cid:173)
`ets-processing operations under the control of the central
`controller, the OpenFlow does not support any mechanism
`to allow DPI of packets through the various networking
`layers as defined by the OSI model. Specifically, the current
`OpenFlow specification defines a mechanism to parse and
`extract only packet headers, in layer-2 through layer-4, from
`packets flowing via the network nodes. The OpenFlow
`specification does not define or suggest any mechanism to
`extract non-generic, uncommon, and/or arbitrary data pat(cid:173)
`terns contained in layer-4 to layer 7 fields. In addition, the
`OpenFlow specification does not define or suggest any
`mechanism to inspect or to extract content from packets
`belonging to a specific flow or session. This is a major
`limitation as it would not require inspection of the packet for
`the purpose of identification of, for example, security threats
`detection.
`
`2
`The straightforward approach of routing all traffic from
`network nodes to the central controller introduces some
`significant drawbacks, such as increased end-to-end traffic
`delays between the client and the server; overflowing the
`5 controller capability to perform other networking functions;
`and a single point of failure for the re-routed traffic.
`Therefore, it would be advantageous to provide a solution
`that overcomes the deficiencies noted above and allow
`efficient DPI in SDNs.
`
`10
`
`SUMMARY
`
`15
`
`A summary of several example embodiments of the
`disclosure follows. This summary is provided for the con(cid:173)
`venience of the reader to provide a basic understanding of
`such embodiments and does not wholly define the breadth of
`the disclosure. This summary is not an extensive overview
`of all contemplated embodiments, and is intended to neither
`20 identify key or critical nodes of all aspects nor delineate the
`scope of any or all embodiments. Its sole purpose is to
`present some concepts of one or more embodiments in a
`simplified form as a prelude to the more detailed description
`that is presented later. For convenience, the term some
`25 embodiments may be used herein to refer to a single
`embodiment or multiple embodiments of the disclosure.
`Certain embodiments disclosed herein include a method
`for deep packet inspection (DPI) in a software defined
`network (SDN), wherein the method is performed by a
`30 central controller of the SDN. The method comprises: con(cid:173)
`figuring a plurality of network nodes operable in the SDN
`with at least one probe instruction; receiving from a network
`node a first packet of a flow, wherein the first packet matches
`the at least one probe instruction, wherein the first packet
`35 includes a first sequence number; receiving from a network
`node a second packet of the flow, wherein the second packet
`matches the at least one probe instruction, wherein the
`second packet includes a second sequence number, wherein
`40 the second packet is a response of the first packet; computing
`a mask value respective of at least the first and second
`sequence numbers, wherein the mask value indicates which
`bytes to be mirrored from subsequent packets belonging to
`the same flow, wherein the mirrored bytes are inspected;
`45 generating at least one mirror instruction based on at least
`the mask value; and configuring the plurality of network
`nodes with at least one mirror instruction.
`Certain embodiments disclosed herein include a system
`for deep packet inspection (DPI) in a software defined
`50 network (SDN), wherein the method is performed by a
`central controller of the SDN. The system comprises: a
`processor; a memory connected to the processor and con(cid:173)
`figured to contain a plurality of instructions that when
`executed by the processor configure the system to: set a
`55 plurality of network nodes operable in the SDN with at least
`one probe instruction; receive from a network node a first
`packet of a flow, wherein the first packet matches the at least
`one probe instruction, wherein the first packet includes a first
`sequence number; receive from a network node a second
`60 packet of the flow, wherein the second packet matches the at
`least one probe instruction, wherein the second packet
`includes a second sequence number, wherein the second
`packet is a response of the first packet; compute a mask
`value respective of at least the first and second sequence
`65 numbers, wherein the mask value indicates which bytes to
`be mirrored from subsequent packets belonging to the same
`flow, wherein the mirrored bytes are inspected; generate at
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 9 of 15
`
`

`

`US 10,652,111 B2
`
`3
`least one mirror instruction based on at least the mask value;
`and configure the plurality of network nodes with at least
`one mirror instruction.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The subject matter disclosed herein is particularly pointed
`out and distinctly claimed in the claims at the conclusion of
`the specification. The foregoing and other objects, features,
`and advantages of the invention will be apparent from the 10
`following detailed description taken in conjunction with the
`accompanying drawings.
`FIG. 1 is a schematic diagram of a network system
`utilized to describe the various disclosed embodiments.
`FIG. 2 illustrates is a schematic diagram of a flow table
`stored in a central controller.
`FIG. 3 is a schematic diagram of a system utilized for
`describing the process of flow detection as performed by a
`central controller and a network node according to one
`embodiment.
`FIG. 4 is a schematic diagram of a system utilized for
`describing the process of flow termination as performed by
`a central controller and a network node according to one
`embodiment.
`FIG. 5 is a data structure depicting the organization of
`flows according to one embodiment.
`FIG. 6 is flowchart illustrating the operation of the central
`controller according to one embodiment.
`
`4
`example, a smart phone, a tablet computer, a personal
`computer, a laptop computer, a wearable computing device,
`and the like. The destination servers 140 are accessed by the
`devices 130 and may be, for example, web servers.
`According to some embodiments, the central controller
`111 is configured to perform deep packet inspection on
`designated packets from designated flows or TCP sessions.
`To this end, the central controller 111 is further configured
`to instruct each of the network nodes 112 which of the
`packets and/or sessions should be directed to the controller
`111 for packet inspections.
`According to some embodiments, each network node 112
`is configured to determine if an incoming packet requires
`inspection or not. The determination is performed based on
`15 a set of instructions provided by the controller 111. A packet
`that requires inspection is either redirected to the controller
`111 or mirrored and a copy thereof is sent to the controller
`111. It should be noted that traffic flows that are inspected are
`not affected by the operation of the network node 112. In an
`20 embodiment, each network node 112 is configured to extract
`and send only a portion of a packet data that contains
`meaningful information.
`The set of instructions that the controller 111 configures
`each of the network nodes 112 with include "probe instruc-
`25 tions", "mirroring instructions", and "termination instruc(cid:173)
`tions." According to some exemplary and non-limiting
`embodiments, the probe instructions include:
`If (TCP FLAG SYN=l) then (re-direct packet to central
`controller);
`30 If (TCP FLAG SYN=l and ACK=l) then (re-direct packet
`to central controller); and
`If (TCP FLAG ACK=l) then (forward packet directly to a
`destination server).
`The termination instructions include:
`35 If (TCP FLAG FIN=l) then (re-direct packet to controller);
`If (TCP FLAG FIN=l andACK=l) then (re-direct packet to
`controller); and
`If (TCP FLAG RST=l) then (re-direct packet to controller).
`The TCP FLAG SYN, TCP FLAG ACK, TCP FLAG FIN,
`40 TCP FLAG RST are fields in a TCP packet's header that can
`be analyzed by the network nodes 112. That is, each node
`112 is configured to receive an incoming packet ( either a
`request from a client device 130 or response for a server
`140), analyze the packet's header, and perform the action
`45 (redirect the packet to controller 111 or send to destination
`server 140) respective of the value of the TCP flag.
`The controller 111 also configures each of the network
`nodes 112 with mirroring instructions with a mirror action of
`X number of bytes within a packet. The mirrored bytes are
`50 sent to the controller 111 to perform the DPI analysis.
`According to some exemplary embodiments, the set of
`mirroring instructions have the following format:
`If (source IP Address=Vl and destination IP Address=V2
`and source TCP port=V3 and destination IP address=V 4 and
`55 TCP sequence=VS and TCP sequence mask=V6) then (mir(cid:173)
`ror V7 bytes)
`The values Vl through V7 are determined by the con(cid:173)
`troller 111 per network node or for all nodes 112. The values
`of the TCP sequence, and TCP sequence mask are computed,
`60 by the controller 111, as discussed in detail below.
`In another embodiment, in order to allow analysis of TCP
`packets' headers by a network node 112 and tracks flows,
`new type-length-value (TLV) structures are provided. The
`TLV structures may be applied to be utilized by an Open-
`65 Flow protocol standard as defined, for example, in the
`OpenFlow 1.3.3 specification published by the Open Flow
`Foundation on Sep. 27, 2013 or OpenFlow 1.4.0 specifica-
`
`DETAILED DESCRIPTION
`
`It is important to note that the embodiments disclosed
`herein are only examples of the many advantageous uses of
`the innovative teachings herein. In general, statements made
`in the specification of the present application do not neces(cid:173)
`sarily limit any of the various claimed embodiments. More(cid:173)
`over, some statements may apply to some inventive features
`but not to others. In general, unless otherwise indicated,
`singular nodes may be in plural and vice versa with no loss
`of generality. In the drawings, like numerals refer to like
`parts through several views.
`FIG. 1 is an exemplary and non-limiting diagram of a
`network system 100 utilized to describe the various dis(cid:173)
`closed embodiments. The network system 100 includes a
`software defined network (SDN) 110 (not shown) containing
`a central controller 111 and a plurality of network nodes 112.
`The network nodes 112 communicate with the central con(cid:173)
`troller 111 using, for example, an Open Flow protocol. The
`central controller 111 can configure the network nodes 112
`to perform certain data path operations. The SDN 110 can be
`implemented in wide area networks (WANs), local area
`networks (LANs), the Internet, metropolitan area networks
`(MANs), ISP backbones, datacenters, inter-datacenter net(cid:173)
`works, and the like. Each network node 112 in the SDN may
`be a router, a switch, a bridge, and so on.
`The central controller 111 provides inspected data (such
`as application metadata) to a plurality of application servers
`(collectively referred to as application servers 120, merely
`for simplicity purposes). An application server 120 executes,
`for example, security applications ( e.g., Firewall, intrusion
`detection, etc.), data analytic applications, and so on.
`In the exemplary network system 100, a plurality of client
`devices (collectively referred to as client devices 130,
`merely for simplicity purposes) communicate with a plural(cid:173)
`ity of destination servers ( collectively referred to as desti(cid:173)
`nation servers 140, merely for simplicity purposes) con(cid:173)
`nected over the network 110. A client device 130 may be, for
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 10 of 15
`
`

`

`US 10,652,111 B2
`
`10
`
`6
`microprocessors, multi-core processors, microcontrollers,
`digital signal processors (DSPs ), field progranimable gate
`array (FPGAs), programmable logic devices (PLDs), con-
`trollers, state machines, gated logic, discrete hardware com(cid:173)
`ponents, dedicated hardware finite state machines, or any
`other suitable entities that can perform calculations or other
`manipulations of information. The memories 313 and 322
`may be implemented using any form of a non-transitory
`computer readable medium.
`Prior to performing the flow detection process the net(cid:173)
`work node 112 is set with the probe instructions, such as
`those discussed above. Referring to FIG. 3, at S301, a packet
`arrives from a client (e.g., client 130, FIG. 1) at a port (not
`shown) at the network node 112. The packet is a TCP packet
`with a header including the following value [TCP FLAG
`SYN=l, SEQUENCE=M].
`As the header' value matches a redirect action, at S302,
`the probe flow module 321 redirects the packet to the
`controller 111, and in particular to the module 311.
`In response, at S303, the module 311 traps the packet and
`creates a new flow-id in the flow table (e.g., table 200) and
`marks the flow-id's state as 'SYN'. The flow table is saved
`in the memory 313. The initial sequence from the client to
`a destination server number equals M and saved in the flow
`25 table as well. Then, the packet is sent to the node 112 for
`further processing.
`At S304, a response packet arrives from a destination
`server (e.g., server 140, FIG. 1) with header value [TCP
`FLAG SYN=l, TCP FLAG ACK=l, SEQUENCE=N]. The
`30 response is received at the node's 112 port. At S305, as the
`header's value matches a probe instruction, the response
`packet is sent to the module 311 in the controller 111.
`In response, the module 311 traps the packet and searches
`for a pre-allocated corresponding flow-id in the flow table
`35 and updates the respective state as 'SYN/ACK'. The module
`311 also stores the initial sequence number of a packet from
`the server to client as equals to N. This will create a new
`bi-directional flow-id with M and N sequence numbers
`identified and the sequence mask logic can be calculated
`40 respective thereof.
`According to various embodiments, the DPI flow detec(cid:173)
`tion module 311 implements or executes a sequence mask
`logic that computes a mask for the initial trapped sequence
`numbers (M and N) to be used for a new flow to be
`45 configured into the node 112. Specifically, the computed
`mask is used to define new mirroring instructions to allow
`mirroring of a number of bytes from the TCP session in both
`directions. The computed mask value specifies which bytes
`respective of the correct sequence number would be required
`50 to mirror from the TCP session. In an embodiment, the
`computed value is placed in a mask filed defined by the
`Open Flow protocol.
`The following steps are taken to extract the computed
`mask value: Compute a temporary mask value (temp_mask_
`55 val) as follows:
`
`5
`tion published on Oct. 14, 2013, for parsing and identifying
`any arbitrary fields within a packet. According to non(cid:173)
`limiting and exemplary embodiments, the TLV structures
`disclosed herein include:
`1. TCP _FLG_OXM_HEADER (0x80FE, 2, 1). This TYL 5
`structure allows identification of the TCP header flags.
`The 'Ox80FE' value represents a unique vendor iden(cid:173)
`tification (ID), the value '2' represents a unique Type=2
`value for the TLV, and the '1' value is I-byte total
`length that stores the TCP flags header.
`2. TCP _SEQ_OXM_HEADER (0x80FE, 1, 4). This TLV
`structure allows identification of the TCP sequence
`number field. The '0x80FE' value represents a unique
`vendor ID, the value '1' represents a unique Type= 1
`value for this TLV, and the value '4' is a 4-byte total 15
`length that stores the TCP sequence number.
`In order to track the flows, the central controller 111 also
`maintains a flow table having a structure 200 as illustrated
`in the exemplary and non-limiting FIG. 2. The flow table
`200 contains two main fields KEY 210 and DATA 220. The 20
`KEY field 210 holds information with respect to the
`addresses/port numbers of a client device 130 and a desti(cid:173)
`nation server 140. The DATA field 220 contains information
`with respect to a TCP flow, such as a flow ID, a request
`(client to server) sequence number M, a response (server to
`client) sequence number N, a flow state (e.g., ACK, FIN), a
`creation timestamp, a client to server hit counter, server to
`client hit counter Y [bytes], client to server data buffer,
`server to client buffer, and an aging bit.
`FIG. 3 shows an exemplary and non-limiting schematic
`diagram of a system 300 for describing the process of flow
`detection as performed by the central controller 111 and a
`network node 112 according to one embodiment. In an
`the central controller 111
`exemplary
`implementation,
`includes a DPI flow detection module 311, a DPI engine 312,
`and a memory 313, and a processing unit 314. The DPI
`engine 312 in configured to inspect a packet or a number of
`bytes to provide application metadata as required by an
`application executed by an application server 120.
`According to various embodiments discussed in detail
`above, the DPI flow detection module 311 is configured to
`detect all TCP flows and maintain them in the flow table
`(e.g., table 200). The module 311 is also configured to
`generate and provide the network logs with the required
`instructions to monitor, redirect, and mirror packets. The
`DPI flow detection module 311 executes certain functions
`including, but not limited to, flow management, computing
`sequence masks, and TCP flow analysis. These functions are
`discussed in detail below.
`In exemplary implementation, the network node 112
`includes a probe flow module 321, a memory 322, and a
`processing unit 323. The probe flow module 321 is config(cid:173)
`ured to redirect any new TCP connection state initiation
`packets to the DPI flow detection module 311, as well as to
`extract several packets from each detected TCP flow and
`mirror them to the flow detection module 311. In an embodi(cid:173)
`ment, probe flow module 321 executes functions and/or
`implements logic to intercept TCP flags, redirect packets,
`and count sequence numbers.
`Both processing units 314 and 323 uses instructions
`stored in the memories 313 and 322 respectively to execute
`tasks generally performed by the central controllers of SDN
`as well as to control and enable the operation of behavioral
`network intelligence processes disclosed herewith. In an
`embodiment, the processing unit (314, 323) may include one
`or more processors. The one or more processors may be
`implemented with any combination of general-purpose
`
`temp_mask_val~M XOR (M+TCP_DATA_
`SIZE_DPI);
`
`The value TCP _DATA_SIZE_DPI specifies the number of
`60 bytes the node 112 would be required to mirror from the
`TCP session. In an embodiment, a different value of the
`TCP _DATA_SIZE_DPI may be set for the upstream and
`downstream traffic. For example, for an upstream traffic
`fewer bytes may be mirrored than the downstream traffic,
`65 thus the TCP _DATA_SIZE_DPI value for upstream traffic
`would be smaller than a downstream traffic. The temp_
`mask_ val returns a number where the most significant bit
`
`Exhibit 1001
`Cisco v. Orckit – IPR2023-00554
`Page 11 of 15
`
`

`

`US 10,652,111 B2
`
`7
`(MSB) set to one indicates the first bit of the mask. Then a
`sequence MSB is computed as follows:
`
`seq_msb~(int32_t)msb32(temp_Mask_ val);
`The 'msb32' function returns the MSB place oftemp_mask_ 5
`val. Finally, the mask value is computed as follows
`
`8
`At S308 and S309, packets arrive from either the client
`device or a destination server with their sequence number
`that matches the mirroring instructions and are mirrored to
`the central controller 111 for buffering and for analysis by
`the DPI engine 312. It should be noted that each instruction
`hit increments a counter Client-to-Server hit counter X
`[bytes] and Server-to-Client hit counter Y [bytes]. The flow
`table audit mechanism scans the flow table, every predefined
`time interval, and updates the mask to 0x00000000 and the
`10 ACTION to "no Action" of all entries that their Client-to(cid:173)
`Server buffer length=TCP _DATA_SIZE_DPI or Server-to(cid:173)
`Client buffer length=TCP _DATA_SIZE_DPI. The various
`fields of the flow table are shown in FIG. 2.
`FIG. 4 show an exemplary and non-limiting diagram of a
`system 400 for describing the process of flow termination as
`performed by the central controller 111 and a network node
`112 according to one embodiment. The various module of
`the controller 111 and node 112 are discussed with reference
`20 to FIG. 3.
`In the flow termination process, the module 311 follows
`a termination of a TCP flow and is responsible to remove the
`exiting flow from the flow table. In addition, the module 311
`disables or removes the mirroring instructions from the node
`25 112. According to one embodiment, the module 311 con(cid:173)
`figures the node 112 with a set of termination instructions.
`Examples for such instructions are provided above.
`At S401, a packet arrives, at the node 112, from a client
`130 with a header including the value of [TCP FLAG
`3° FIN=l]. The value matches one of the termination instruc(cid:173)
`tions, thus, at S402, to the packet is sent to the center
`controller 111.
`In response, at S403, the module 311 traps the packet and
`marks the corresponding flow-id in the flow table to update
`the state to FIN. Then, the packet is sent back it to the
`network log.
`At S404, a response packet from the destination server
`(e.g., server 140) with a header's value containing [TCP
`FLAG FIN=l, ACK=l] is received at the node 112. As the
`
`15
`
`35
`
`mask~(int32_t)(0-((0xl <<seq_msb ))).
`
`As an example,
`is
`if the sequence number M
`M=0xf46d5c34, and TCP _DATA_SIZE_DPI=16384, then:
`temp_mask_val=0xf46d5c34 XOR (0xf46d5c34+16384)=
`Oxc000
`seq_msb=(int3 2_t )ms b3 2(0xf 46d9c34 )= 16
`mask=(int32_t )(0-(0xl < <16) )=0xFFFFS000
`The mask is defined such that a '0' in a given bit position
`indicates a "don't care" match for the same bit in the
`corresponding field, whereas a '1' means match the bit
`exactly. In above example, all data packets containing
`to
`range of { 0xf46d5c34
`sequence number