( 12 ) United States Patent
`Barsheshet et al .
`
`( 10 ) Patent No .: US 10,652,111 B2
`( 45 ) Date of Patent :
`May 12 , 2020
`
`US010652111B2
`
`( 54 ) METHOD AND SYSTEM FOR DEEP PACKET
`INSPECTION IN SOFTWARE DEFINED
`NETWORKS
`( 71 ) Applicant : ORCKIT IP , LLC , Newton , MA ( US )
`Inventors : Yossi Barsheshet , Ashdod ( IL ) ;
`( 72 )
`Simhon Doctori , Gan - Yavne ( IL ) ;
`Ronen Solomon , Ranat - Gan ( IL )
`( 73 ) Assignee : ORCKIT IP , LLC , Dover , DE ( US )
`Subject to any disclaimer , the term of this
`( * ) Notice :
`patent is extended or adjusted under 35
`U.S.C. 154 ( b ) by 306 days .
`15 / 126,288
`Apr. 21 , 2015
`PCT / US2015 / 026869
`
`( 21 ) Appl . No .:
`( 22 ) PCT Filed :
`( 86 ) PCT No .:
`$ 371 ( c ) ( 1 ) ,
`Sep. 15 , 2016
`( 2 ) Date :
`( 87 ) PCT Pub . No .: WO2015 / 164370
`PCT Pub . Date : Oct. 29 , 2015
`Prior Publication Data
`US 2017/0099196 A1
`Apr. 6 , 2017
`
`( 65 )
`
`( 60 )
`
`Related U.S. Application Data
`Provisional application No. 61 / 982,358 , filed on Apr.
`22 , 2014 .
`( 51 ) Int . CI .
`H04L 12/26
`H04L 12/64
`
`( 2006.01 )
`( 2006.01 )
`( Continued )
`
`( 52 ) U.S. CI .
`CPC
`
`H04L 43/028 ( 2013.01 ) ; H04L 12/6418
`( 2013.01 ) ; H04L 437026 ( 2013.01 ) ;
`( Continued )
`
`( 58 ) Field of Classification Search
`CPC . H04L 43/026 ; H04L 12/6418 ; H04L 43/028 ;
`HO4L 49/70 ; HO4L 69/161
`( Continued )
`
`( 56 )
`
`2010/0208590 A1 *
`
`2010/0212006 A1
`
`References Cited
`U.S. PATENT DOCUMENTS
`8/2010 Dolganow
`8/2010 Dolganow et al .
`( Continued )
`FOREIGN PATENT DOCUMENTS
`
`H04L 43/026
`370/235
`
`EP
`
`2672668 A1 12/2013
`
`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
`120
`
`Application
`servers
`120
`
`Application
`servers
`120
`
`100
`
`130
`
`130
`
`IP traffic
`
`Network node
`112
`
`130
`
`130
`
`Central Controller
`111
`
`Network node
`112
`
`Network node
`112
`
`IP traffic
`
`140
`
`140
`
`

`

`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 ) Int . Ci .
`H04L 12/851
`H04L 12/931
`H04L 29/06
`( 52 ) U.S. CI .
`CPC
`
`( 2013.01 )
`( 2013.01 )
`( 2006.01 )
`
`H04L 47/2483 ( 2013.01 ) ; H04L 49/70
`( 2013.01 ) ; H04L 69/161 ( 2013.01 )
`( 58 ) Field of Classification Search
`USPC
`370/389
`See application file for complete search history .
`References Cited
`U.S. PATENT DOCUMENTS
`10/2011 Dolganow et al .
`12/2013 Chesla et al .
`
`( 56 )
`
`2011/0264802 Al
`2013/0329764 A1
`
`2014/0052836 A1 *
`
`2015/0124812 A1 *
`
`2016/0020998 A1 *
`
`2016/0197831 A1 *
`
`2016/02 19080 A1 *
`
`2/2014 Nguyen
`5/2015 Agarwal
`1/2016 Bifulco
`7/2016 De Foy
`7/2016 Huang
`
`HO4L 45/306
`709/223
`HO4L 45/24
`370/392
`HO4L 45/64
`370/235
`HO4L 45/7453
`370/392
`HO4L 63/20
`
`OTHER PUBLICATIONS
`Seugwon Shin et al , “ Fresco : Modular Composable Security Ser
`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
`cations , Technologies , Architectures , and Protocols for Computer
`Communications , New Delhi , India , Aug. 30 - Sep . 3 , 2010 , ACM ,
`pp . 351-362 XP058189957 .
`
`* cited by examiner
`
`

`

`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
`
`130
`
`130
`
`IP traffic
`
`Network node
`112
`
`130
`
`130
`
`Central Controller
`111
`
`Network node
`112
`
`Network node
`112
`
`IP traffic
`
`FIG . 1
`
`140
`
`140
`
`JI
`
`140
`
`

`

`U.S. Patent
`
`May 12 , 2020
`
`Sheet 2 of 6
`
`US 10,652,111 B2
`
`Age bit
`Server
`Client
`
`Server
`
`Server
`timestamp
`
`Client
`Server
`
`Client
`Creation
`state
`
`Server
`
`Client
`
`Client
`Flow
`
`IP
`
`Server
`Client
`Server IP
`
`Client IP
`
`ID
`
`Server
`protocol
`destination
`Source
`address
`address
`
`DATA 220
`
`200
`
`KEY 210
`
`buffer
`
`
`
`data buffer
`
`Client
`
`counter Y
`
`[ bytes )
`
`Hit
`
`
`
`Hit counter X
`[ bytes )
`
`number N
`
`number M
`
`sequence
`sequence
`
`number
`TCP port
`
`TCP
`
`port
`
`15:32:13
`ACK
`0x3c98b9ab
`Oxf46d5c34
`
`1
`
`6
`
`21
`
`15431
`209.1.4.4
`192.1.1.1
`
`FIG . 2
`
`

`

`U.S. Patent
`
`May 12 , 2020
`
`Sheet 3 of 6
`
`US 10,652,111 B2
`
`DPI
`Engine
`312
`
`TCP Flag
`
`111
`
`S301
`
`DPI Flow Detection unit
`311
`S303
`
`S306
`
`S302
`
`S305
`
`314
`
`313
`
`Mirror
`Packets
`
`S304
`
`S307
`
`Probe Flow Module
`321
`
`TCP sequence
`number base
`
`323
`
`322
`
`S308
`
`112
`
`FIG . 3
`
`1
`
`324
`
`S309
`
`Probe sequence :
`counter
`
`

`

`U.S. Patent
`
`May 12 , 2020
`
`Sheet 4 of 6
`
`US 10,652,111 B2
`
`DPI
`Engine
`312
`
`DPI Flow Detection unit
`311
`$ 403
`
`S407
`
`S402
`
`313
`
`314
`
`TCP flags
`flow creation 1
`
`S405
`
`111
`
`S401
`
`S407
`
`Probe Flow Module
`321
`
`S404
`
`TCP sequence
`number base
`
`323
`
`322
`
`112
`
`FIG . 4
`
`324
`
`Probe sequence
`counter
`
`

`

`U.S. Patent
`
`May 12 , 2020
`
`Sheet 5 of 6
`
`US 10,652,111 B2
`
`501
`
`Match fields
`MASK ( filed1 , ... , )
`
`Priority
`Instruction
`Highest Go to probe table
`
`500
`
`Probe table 510
`
`511
`
`< srcIP , destIP , .... >
`< srcIP , destIP , .... >
`
`Instruction
`Priority
`Highest Go to next table ID
`Highest Go to next table ID
`
`511 ps
`
`512
`
`513 {
`
`< src P , destIP
`< src / P , desti ,
`MASK ( filed1 ,
`MASK ( filed1 , ... , )
`
`Highest Go to next table ID
`Highest Go to next table ID
`Medium Output : controller
`Medium Output : controller
`
`MASK all fields
`
`low Go to next table ID
`
`FIG . 5
`
`

`

`U.S. Patent
`
`May 12 , 2020
`
`Sheet 6 of 6
`
`US 10,652,111 B2
`
`600 600
`
`u 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
`
`S660
`Inspect received mirrored bytes using DPI
`
`?.
`6
`
`S670
`
`Terminate
`Inspection ?
`
`No
`
`A
`
`Yes S680
`Remove related exiting flows from flow table
`
`FIG . 6
`
`END
`
`

`

`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 DPIoftraffic 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-
`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-
`works provided to customers. Typically,
`the DPI is per-
`formed by dedicated engines installed in such networks.
`A software defined networking is a relatively new type of
`networking architecture that provides centralized manage-
`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-
`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-basedarchitectures the data forward-
`ing (e.g. data plane) is typically decoupled from control
`decisions(e.g. control plane), such as routing, resources, and
`other managementfunctionalities. The decoupling may also
`allow the data plane and the control plane to operate on
`different hardware, in different runtime environments, 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.
`
`the OpenFlow protocol allows addition of
`Although,
`programmability to network nodes for the purpose of pack-
`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-
`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 purposeofidentification of, for example, security threats
`detection.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`The straightforward approach of routing all traffic from
`network nodes to the central controller introduces some
`
`significant drawbacks, such as increased end-to-endtraffic
`delays between the client and the server; overflowing the
`controller capability to perform other networking functions;
`and a single point of failure for the re-routedtraffic.
`Therefore, it would be advantageousto provide a solution
`that overcomes the deficiencies noted above and allow
`efficient DPI in SDNs.
`
`SUMMARY
`
`A summary of several example embodiments of the
`disclosure follows. This summary is provided for the con-
`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
`identify key or critical nodes ofall 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
`embodiments may be used herein to refer to a single
`embodiment or multiple embodiments of the disclosure.
`Certain embodiments disclosed herein include a method
`
`inspection (DPI) in a software defined
`for deep packet
`network (SDN), wherein the method is performed by a
`central controller of the SDN. The method comprises: con-
`figuring a plurality of network nodes operable in the SDN
`with at least one probeinstruction; receiving from a network
`nodea first packet of a flow, wherein thefirst packet matches
`the at least one probe instruction, wherein the first packet
`includesa first sequence number; receiving from a network
`node a second packetof 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 packetis a responseofthe 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;
`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
`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-
`figured to contain a plurality of instructions that when
`executed by the processor configure the system to: set a
`plurality of network nodes operable in the SDN with at least
`one probe instruction; receive from a network nodea first
`packet of a flow, wherein thefirst packet matchesthe at least
`one probeinstruction, wherein the first packet includesa first
`sequence number; receive 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 the second
`packet is a response of the first packet; compute 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; generate at
`
`

`

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

`

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

`

`US 10,652,111 B2
`
`10
`
`15
`
`7
`8
`At S308 and S309 , packets arrive from either the client
`( MSB ) set to one indicates the first bit of the mask . Then a
`sequence MSB is computed as follows :
`device or a destination server with their sequence number
`that matches the mirroring instructions and are mirrored to
`seq_msb = ( int32_t ) msb32 ( temp_Mask_val ) ;
`the central controller 111 for buffering and for analysis by
`The ‘ msb32 ” function returns the MSB place of temp_mask_ 5 the DPI engine 312. It should be noted that each instruction
`val . Finally , the mask value is computed as follows
`hit increments a counter Client - to - Server hit counter X
`[ bytes ) and Server - to - Client hit counter Y [ bytes ] . The flow
`mask = ( int32_t ) ( 0 - ( ( 0x1 << seq_msb ) ) ) .
`table audit mechanism scans the flow table , every predefined
`is
`As an example , if the sequence number M
`M = Oxf46d5c34 , and TCP_DATA_SIZE_DPI = 16384 , then :
`time interval , and updates the mask to 0x00000000 and the
`ACTION to “ no Action ” of all entries that their Client - to
`temp_mask_val = 0xf46d5c34 XOR ( Oxf46d5c34 + 16384 ) =
`Server buffer length = TCP_DATA_SIZE_DPI or Server - to
`Oxc000
`Client buffer length = TCP_DATA_SIZE_DPI . The various
`seq_msb = ( int32_t ] msb32 ( Oxf46d9c34 ) = 16
`mask = ( int32_t ) ( 0- ( Oxl << 16 ) = 0xFFFF8000
`fields of the flow table are shown in FIG . 2 .
`The mask is defined such that a ' O’in a given bit position
`FIG . 4 show an exemplary and non - limiting diagram of a
`system 400 for describing the process of flow termination as
`indicates a “ don't care " match for the same bit in the
`corresponding field , whereas a “ l ' means match the bit
`performed by the central controller 111 and a network node
`exactly . In above example , all data packets containing
`112 according to one embodiment . The various module of
`sequence number in
`the range of { Oxf46d5c34 to
`the controller 111 and node 112 are discussed with reference
`Oxf46d9c34 } be mirrored to the controller 111 .
`20 to FIG . 3 .
`Using the computed mask value , the module 311 using a
`In the flow termination process , the module 311 follows
`TCP flow analysis logic ( not shown ) creates the mirroring
`a termination of a TCP flow and is responsible to remove the
`instructions related to the client and server traffic . One
`exiting flow from the flow table . In addition , the module 311
`instruction identifies the client to server flow traffic , includ
`disables or removes the mirroring instructions from the node
`ing the OXM_OF_ _TCP_SEQ to identify the initial
`sequence number of the flow with the mask_M computed . 25 112. According to one embodiment , the module 311 con
`figures the node 112 with a set of termination instructions .
`The action of the flow is to mirror all packets that the
`Examples for such instructions are provided above .
`instruction applies , which will result in the TCP_DATA_
`At S401 , a packet arrives , at the node 112 , from a client
`SIZE_DPI number of bytes from the client to server direc
`130 with a header including the value of [ TCP FLAG
`tion to be mirrored to the controller 111. The second
`FIN = 1 ] . The value matches one of the termination instruc
`instruction identifies the server - to - client flow traffic , includ
`ing the OXM_OF_TCP_SEQ to identify the initial sequence
`tions , thus , at S402 , to the packet is sent to the center
`number of the flow with the mask N. The action is to mirror
`controller 111 .
`all packets that the instruction applies to , which will result
`In response , at S403 , the module 311 traps the packet and
`in the TCP_DATA_SIZE_DPI number of byte from the
`marks the corresponding flow - id in the flow table to update
`server to client direction to be mirrored to the controller 111
`the state to FIN . Then , the packet is sent back it to the
`for further analysis . The mask_N and mask_M are computed
`network log .
`using the sequence numbers N and M < respectively using
`At S404 , a response packet from the destination server
`the process discussed above . As a non - limiting examp