Application traffic flow prediction based on multi-stage network traffic flow scanning

Abstract

In a network control plane, a pattern matching database is constructed and maintained for identifying an application or application level protocol. Further, a pattern matching database for predicting subsequent streams of application layer / level protocols or data protocols is constructed and maintained. After flow distinguishing from the network traffic of the data plane mirror image, the network traffic flow is scanned in a first stage, and then if a signaling protocol message is detected in the first stage scan, the network traffic flow is scanned in a second stage. For the second stage, one of the application / data protocol pattern databases is selected for scanning based on the signaling protocol messages detected in the first stage scan. If a match is found from the stage 2 scan, a mapping between the signaling protocol identifier and the predicted identifier of the application traffic flow is created and communicated to the data plane for policy selection and enforcement.

Description

Background Art

[0001] The present disclosure relates generally to electronic communications (eg, CPC class H04) and digital transmission arrangements for network maintenance, management or operation (eg, subclass H04L 41 / 00).

[0002] Flow tracking examines information in the header of a packet (i.e., a transport layer protocol data unit) to classify packets of network traffic into different flows. A flow is identified by a tuple, which can be a 5-tuple or a 3-tuple. The 5-tuple used for flow classification includes the source Internet Protocol (IP) address, the source Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) port, the destination IP address, the destination TCP / UDP port, and the IP protocol. The 3-tuple used for flow classification will include the source IP address, the destination IP address, and the IP protocol. After flow classification, the firewall can use stateful inspection to identify the application of the flow based on the port and source / destination address. The firewall can also use deep packet inspection to identify the application based on the application signature / pattern in the application data. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Embodiments of the present disclosure may be better understood by referring to the accompanying drawings.

[0004] Figure 1 A diagram of a control plane of a network device that uses multi-stage pattern matching to perform application flow prediction on network traffic.

[0005] Figure 2 is a flow diagram of example operations for building an application / data protocol database for multi-stage application flow prediction.

[0006] Figure 3 is a flow diagram of example operations for multi-stage scanning of network traffic to apply flow prediction.

[0007] Figure 4 An example computer system having a data plane and a control plane including an application flow predictor is depicted. DETAILED DESCRIPTION

[0008] The following description includes example systems, methods, techniques and program flows to aid understanding of the present disclosure and does not limit the scope of the claims. For the sake of brevity, well-known instruction instances, protocols, structures and techniques are not shown in detail.

[0009] Overview

[0010] Before application data begins to flow through a checkpoint (e.g., a firewall), identifying an application layer protocol (e.g., Session Initiation Protocol (SIP) or File Transfer Protocol (FTP)) or application allows timely implementation of relevant policies and reduces the opportunity for network attacks. Some applications and application layer protocols rely on session establishment through a signaling protocol (e.g., SIP or H.323) before application traffic / data begins to flow. This description refers to application layer / level protocols that typically precede data / application traffic as "predictor protocols" because the subsequent flow of data or application traffic is expected or can be predicted. A security device (e.g., a firewall with an application level gateway) can use the identification of a signaling protocol message that establishes a session for an application or application layer protocol to determine flow identification information to identify the application or application protocol before data begins to flow for the application or application layer protocol. In the network control plane, a pattern matching database is built and maintained for identifying applications or application level protocols (e.g., SIP, Hypertext Transfer Protocol (HTTP), etc.). In addition, a pattern matching database is built and maintained for predicting subsequent flows of application layer / level protocols or data protocols. After traffic differentiation in the network traffic mirrored from the data plane, the process(es) in the control plane ("application identification engine") scans the flow in phase 1, and then scans the traffic in phase 2 if a predictor protocol message is detected in the phase 1 scan. For phase 2, the application identification engine selects an application / data protocol pattern database to scan based on the predictor protocol message detected in the phase 1 scan. If a match is found from the phase 2 scan, the application identification engine creates a mapping between the predictor protocol identifier and the identifier of the predicted application traffic flow.

[0011] Example diagram

[0012] Figure 1 A diagram of a control plane of a network device that uses multi-stage pattern matching to perform application flow prediction on network traffic. Figure 1 A control plane 101 and a data plane 103 are illustrated. The data plane 103 includes a packet forwarding engine 117. The control plane 101 includes an application identification engine 111 with an application flow predictor. The application identification engine 111 also includes a pattern matching engine 109. The control plane 101 also includes a traffic processor 110 that implements deep packet inspection (DPI) with flow tracking.

[0013] Figure 1 Labeled with a series of letters AG. Each stage represents one or more operations. Although the stages are in order for this example, the stages illustrate an example to aid understanding of the present disclosure and should not be used to limit the claims. Subject matter falling within the scope of the claims may differ from what is illustrated.

[0014] In phase A, network traffic received at the data plane 103 is mirrored to the control plane 101. Mirroring can be implemented using port mirroring.

[0015] In phase B, the service processor 110 differentiates the mirrored network services into detected service flows. For example, the service processor 110 creates (or generates a thread to create) a data structure having a detected network information tuple for flow differentiation.

[0016] For each flow, the application identification engine 111 scans packets of the flow to identify applications or application-level protocols to ensure that corresponding policies are applied.

[0017] In phase C, the application identification engine 111 uses the pattern matching engine 109 to scan the traffic flow for matching in the phase 1 application layer pattern database 113. The pattern matching database 113 and the pattern matching database 115 are pre-built. Expert / domain knowledge is used to select and define patterns or regular expressions based on message fields representing applications, signaling protocols, etc. For the pattern matching database 115, expert / domain knowledge is used to select and define patterns based on message fields representing data protocols or applications. For this illustration, it is assumed that the phase 1 scan produces a matching entry indicating that a SIP message is detected in the transport layer packet payload or user data payload.

[0018] In phase D, the application identification engine 111 selects a pattern matching database 115 for SIP based on the scanning results of phase 1 and scans the service flow accordingly. The application identification engine 111 uses the pattern matching engine 109 (or another instance of the pattern matching engine 109) to scan the service flow for matching in the selected SIP pattern matching database of the database 115.

[0019] In phase E, the application identification engine 111 determines the data protocol indicated in the service flow and extracts the flow identification information of the data protocol from the matching packet payload based on finding a pattern match in the selected phase 2 database. The matching entry can indicate the location of the flow identification information in the matching payload with the SIP message. For example, the matching pattern can be used for the real-time protocol (RTP) indicated in the session description protocol (SDP) message of the SIP message. The matching entry can indicate an offset within the SIP message to locate the network address (e.g., IP address) and port of the RTP connection to be established and stream multimedia data. The following is an example of a SIP message with an indication of the data protocol and the flow identification information for the data protocol. The lines with tokens in the SIP message are marked in bold, and the tokens will match the pattern.

[0020]

[0021] The phase 1 scan will have matched the pattern corresponding to "INVITE sip" and determined that the traffic flow includes a SIP message. The phase 2 scan will match multiple patterns within the SIP message, each pattern corresponding to the data or application level protocol RTP. After SIP establishes the session(s), RTP will be used to transport audio and video data streams. These are indicated by the m lines. The matching patterns for this example would be "c=IN", "m=audio", and "m=video". The phase 2 scan will find a match for "c=IN" in the SIP pattern database, and the application identification engine will extract the network address 10.120.42.3 based on the match result, which may, for example, indicate the location of the network address with an offset. The extracted network address forms part of the stream identifier of the RTP application, which will subsequently begin to traverse the data plane 103 after the SIP session is established. The phase 2 scan will find a match for "m=audio" in the SIP pattern database, and the application identification engine will extract port 49170 based on the match result. This port, combined with the extracted network address, forms the stream identifier for the audio stream. The Phase 2 scan will also find a match for "m=video" in the SIP pattern database, and the Application Identification Engine will extract port 51372 based on the match. This port, combined with the extracted network address, forms the stream identifier for the video stream. Using the stream identification information extracted for the expected / predicted data stream, the Application Identification Engine will create a mapping between the signaling protocol and the stream identification information. Referring again to the example SIP message above, the Application Identification Engine will create two mappings. For the predicted audio stream, the first mapping will be For the predicted video stream, the second mapping will be

[0022]

[0023] In phase F, control plane 101 communicates the mapping(s) to data plane 103. For example, assuming a matching pattern is found in one of databases 115 representing SIP, control plane 101 communicates a mapping of "sip" to an Internet Protocol (IP) address and port. Control plane 101 may communicate the mapping via an inter-process communication channel or an in-band interface.

[0024] In phase G, packet forwarding engine 117 determines the policy to apply to the flow identified in the transmitted mapping. Packet forwarding engine 117 accesses a repository (or structure) 119 indicating the policy assigned to the application and / or data protocol. Packet forwarding engine 117 accesses repository 119 using the application or protocol identifier transmitted from control plane 101 to determine the configured or assigned policy. Packet forwarding engine 117 then updates the memory or structure of data plane 103 to indicate the determined policy for implementation on the flow identified in the transmitted mapping.

[0025] Figure 2-Figure 3 is a flow chart of example operations associated with multi-stage prediction of application / data protocol flows following detection of messages for supporting and / or prior protocols, such as signaling protocol setup messages. Although the preceding figures relate to an application identification engine, the example operations are described with reference to an application flow predictor, which may be a component of the application identification engine or a stand-alone program that interacts with or supplements the application identification engine. The names chosen for the program code are not limitations on the claims. The structure and organization of the programs may vary depending on the platform, programmer / architect preference, programming language, etc. Additionally, the names of the code units (procedures, modules, methods, functions, etc.) may vary for the same reasons and may be arbitrary.

[0026] Figure 2 1 is a flow chart of example operations for building an application / data protocol database for multi-stage application flow prediction. While at least some of the databases will be pre-built, other databases for different application / data protocols may be added later. Furthermore, database maintenance may involve adding, removing, and / or editing entries, each of which associates information for flow identification information extraction with a pattern.

[0027] At block 201, the application flow predictor begins operation to build a pattern matching database for application / data protocols that are expected or predicted to follow session establishment over a signaling protocol. For example, the application flow predictor may build a regular expression matching database for each application / data protocol.

[0028] At block 203, the application flow predictor obtains the application / data protocol identifier pattern that appeared in the previous session setup message. For example, the application flow predictor may iterate over a file / structure containing regular expressions for multi-channel application layer gateway (ALG) protocols (e.g., SIP, File Transfer Protocol (FTP), H.323 protocol). The application flow predictor may process each of these files / structures in parallel or sequentially.

[0029] At block 205, a flow predictor is applied to obtain the position(s) of the flow identification information to associate with the identifier pattern. In the case of SIP, the network address follows the matching c-line pattern, and the port follows the matching m-line pattern. The obtained position may be indicated or represented by an offset from the start of the payload / message or an offset relative to the matching pattern.

[0030] In block 207, the application flow predictor compiles the (one or more) identifier patterns selected to represent the application / data protocol into a database. For example, the application flow predictor compiles regular expressions for the application / data protocol into a regular expression matching database. The compilation depends on the regular expression matching engine implementation used. For example, the compilation function of the super scan library can be used to compile regular expressions selected for the application / data protocol. For the SIP pattern database, the c-line and m-line tokens from the SDP payload can be used to predict media flows (e.g., audio / video, RTP / AVP). As another example, the pattern can be based on FTP port commands. Below are example SIP patterns defined with wildcards that can be compiled into a regular expression database for application / data protocols that are expected / predicted to follow the establishment of a SIP session.

[0031]

[0032] At block 209, the application flow predictor associates the obtained flow identification information location(s) with the compiled pattern in the corresponding database entry. The application flow predictor may update a pointer or field to indicate the location information. This is an optional operation, as the location information may be defined separately for each signaling protocol. For example, a match in the SIP pattern matching database causes the application flow predictor to look up the location information based on finding a match, rather than having the location information in the database.

[0033] At block 211, the application flow predictor determines whether there is a pattern for additional application / data protocols for flow prediction. If so, the operational flow returns to block 201. Otherwise, the operational flow ends.

[0034] Figure 3 is a flow chart of example operations for multi-stage scanning of network traffic applying flow prediction. The example operations are run after flow differentiation of network traffic mirrored from the data plane. Thus, the scan has separate flows. Depending on the implementation, a different thread may be instantiated for each flow to be scanned.

[0035] In block 301 , an application identification engine scans mirrored packets of a service flow against a phase 1 mode database. For example, a super scan library in scan mode can be used to scan the payload of packets in the flow. The scan generates phase 1 scan results 302 .

[0036] At block 303, the application identification engine determines whether the phase 1 scan result 302 indicates a match in the phase 1 pattern database. If the phase 1 scan result is negative for a match, the operational flow ends. In some cases, a default policy will be indicated for the scanned flow. If the phase 1 scan result indicates a match, the operational flow proceeds to block 305.

[0037] At block 305, the application identification engine determines whether the phase 1 scan results indicate a match for a "predictor" protocol. A predictor protocol is an application-level protocol (i.e., above the transport layer) for which a match message will indicate another application-level protocol in advance, perhaps because the predictor protocol is establishing a session or control information for a subsequent application / data protocol. An example of a predictor protocol frequently used in this specification is SIP. The phase 1 scan results will include an identifier based on the match (e.g., "SIP" or "H.323"). The predictor protocol is not necessarily different from the protocol of the subsequent data flow. For example, FTP will establish a control connection and then establish a data connection. The FTP process will use the control connection to transmit (one or more) commands. To illustrate, a pattern match for detecting FTP in a traffic flow as a predictor protocol will match a pattern based on an FTP command or response code (e.g., USER, RETR, CDUP, CWD, XRCP, XRMD, 220, 227, 332, 421, etc.). If a predictor protocol is not indicated, the operational flow proceeds to block 307. If predictor agreement is indicated in the Phase 1 scan results, operational flow proceeds to block 309 for Phase 2 scanning.

[0038] In block 307 , the application identification engine transmits the identified application to the data plane. Although the application traffic corresponding to the identified application may have already begun to flow through the checkpoint, the data plane may begin to implement the relevant policies. The operation flow ends after block 307 .

[0039] At block 309, the application flow predictor of the application identification engine selects a stage 2 database based on the stage 1 scan results. For example, the predictor protocol pattern matching database is indexed or identified by the value returned from the matching entry in the stage 1 pattern matching database.

[0040] At block 311, the flow predictor is applied to scan mirrored packets of a traffic flow in which a predictor protocol message is detected for a match in a selected predictor protocol database.

[0041] At block 313, the flow predictor is applied to determine if a match(es) is found in the selected database. If not, then the operational flow ends. For example, scanning multiple patterns in parallel may return a match indication or a set of match indications. Using FTP as an example, after the phase 1 scan detects the FTP port command message "227 Enter Passive Mode", which will convey the address and port that the FTP server will use for data transmission, the phase 2 scan will find the pattern associated with the flow identification information. If a match is found, then the operational flow proceeds to block 315.

[0042] At block 315, the application flow predictor extracts predicted flow information based on the matching entry. The match(es) in the selected predictor protocol database predicts that at least one subsequent flow (e.g., the RTP flow of an audio flow after SIP setup) will begin to pass through the checkpoint. The matching entry may indicate the location of the flow information within the predictor protocol message (e.g., the location of the network address and port). An embodiment may indicate the location of the flow information separately based on the match in the predictor protocol database. For example, a match in the predictor protocol XYZ pattern matching database causes the application flow predictor to look up the location information of the network address and port in a separate table. The predictor protocol may allow multiple flows to be indicated within a conforming message. For example, a SIP message body may contain SDP descriptions for multiple flows with multiple connections and multiple media sessions. Referring again to the FTP example, the application flow predictor may extract the flow identification information by forming the network address and port with the detection portion of the FTP port command message. Using a command message formatted as a port command code (I1, I2, I3, I4, p1, p2), the application flow predictor can form a network address using I1.I2.I3.I4, and the port is (p1*256)+p2. In the more specific example of detecting a port command message "227 Enter Passive Mode (192,168,20,101,117,254)", the application flow predictor can form a network address of 192.168.20.101 and calculate the port as 30206.

[0043] At block 317, the application flow predictor creates a mapping 318 of predicted flow information to predictor protocol identifiers. The application flow predictor may use the predictor protocol identifier indicated in the stage 1 scan results. Using the FTP example above, the application flow predictor creates the mapping 192.168.20.101:30206<->FTP.

[0044] The application flow predictor (or another process in the control plane of the checkpoint) communicates the mapping to the data plane at block 321. This may be communicated via an interface between the control plane and the data plane, or the like, with inter-process communication.

[0045] Variants

[0046] Although the description relates to detecting or identifying signaling protocol messages in a traffic stream before branching to Phase 2 scanning, embodiments are not limited thereto. Signaling protocol is selected as a representative type of predictor protocol because it typically precedes ALG application traffic (e.g., SIP messages precede RTP audio streams).

[0047] The flowcharts are provided to aid in understanding the illustrations and are not intended to limit the scope of the claims. The flowcharts depict example operations that may vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. It will be understood that each block of the flowcharts and / or block diagrams and combinations of blocks in the flowcharts and / or block diagrams may be implemented by program code. The program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable machine or device.

[0048] As will be appreciated, aspects of the present disclosure may be embodied as systems, methods, or program codes / instructions stored in one or more machine-readable media. Thus, these aspects may take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, which may all be collectively referred to herein as "circuits," "modules," or "systems." The functionality presented as individual modules / units in the example illustrations may be organized differently depending on any of the platform (operating system and / or hardware), application ecosystem, interface, programmer preference, programming language, administrator preference, etc.

[0049] Any combination of one or more machine-readable media may be utilized. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium may be, for example, but not limited to, a system, device, or apparatus that uses any one or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies to store program code. More specific examples (non-exhaustive list) of machine-readable storage media will include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium may be any tangible medium that may contain or store a program used by or in conjunction with an instruction execution system, device, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0050] A machine-readable signal medium may include a propagated data signal having a machine-readable program code embodied therein (e.g., in baseband or as part of a carrier wave). Such propagated signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that may transmit, propagate, or convey a program used by or in conjunction with an instruction execution system, apparatus, or device.

[0051] Program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0052] The program code / instructions may also be stored in a machine-readable medium, which may direct the machine to operate in a particular manner so that the instructions stored in the machine-readable medium produce an article of manufacture, which includes instructions for implementing the functions / actions specified in the flowchart and / or one or more block diagram boxes.

[0053] Figure 4 An example computer system having a data plane and a control plane is depicted, which includes an application flow predictor. The computer system includes a control plane 401 and a data plane 413. The control plane 401 includes a processor 403 (which may include multiple processors, multiple cores, multiple nodes and / or implement multithreading, etc.). The computer system includes a memory 405. The memory 405 can be any one or more of the possible implementations of the system memory or the machine-readable medium described above. The control plane 401 also includes an application identification engine 407, which includes an application flow predictor 411. The processor 403 can implement the application identification engine 411 (e.g., instructions for executing program code). The application identification engine 407 can be a dedicated integrated circuit coupled to the processor 403 but different from the processor 403. The communication channel 410 communicatively couples the control plane 401 to the data plane 413. The data plane 413 includes line cards 416A, 416B that communicate via a switch fabric 419. The line card 416A includes packet forwarding engines (PFEs) 417A, 417B. Line card 416B includes PFEs 417C, 417D. Application identification engine 407 distinguishes network traffic mirrored from at least one of PFEs 417A-417D and scans the distinguished traffic against a master database for application identification. If a predictor protocol message is detected in a flow from the application identification, application flow predictor 411 scans the flow for pattern matching of upcoming traffic for a predicted application / data protocol (e.g., a cloud-based conferencing application or protocol) and extracts the predicted flow identification information to create a mapping between the predictor protocol and the predicted flow. Control plane 401 then communicates the mapping to the appropriate PFE for policy selection and implementation.

[0054] The embodiments are not limited to Figure 4 For example, the embodiments may be deployed as a virtual firewall or a cloud-based firewall.

[0055] the term

[0056] Unless specifically stated otherwise, the phrase "at least one of" used before a list with the conjunction "and" should not be viewed as an exclusive list and should not be interpreted as a category list with one item from each category. A clause reciting "at least one of A, B, and C" may be violated by only one listed item, a plurality of listed items, and one or more items in the list and another unlisted item.

Claims

1. A method comprising: selecting a first signaling protocol pattern database from a plurality of signaling protocol pattern databases constructed with patterns corresponding to a plurality of different signaling protocols based at least in part on detecting a message of the first signaling protocol in the first network traffic flow; Scanning a first network service flow in a control plane for pattern matching in a first signaling protocol pattern database; extracting first application service flow identification information of an application or data protocol indicated in a payload of a first network service flow corresponding to the pattern match based on a scan indicating a pattern match in a first signaling protocol pattern database; Associating an identifier of the first signaling protocol with a first application service flow identifier based on the first application service flow identification information to generate a first mapping; transmitting the first mapping from the control plane to the data plane; and A first policy among the plurality of policies is selected in the data plane based on the first mapping.

2. The method according to claim 1 further comprises detecting a message of a first signaling protocol in the first network service flow, wherein the detecting message comprises: scanning a first network traffic flow in a control plane for pattern matching in a first pattern matching database constructed with patterns identifying applications and application layer protocols; and determining whether a pattern match in the first pattern matching database indicates a signaling protocol based on scanning the pattern matches in the first pattern matching database that indicate a pattern match in the first pattern matching database, The detecting of the message of the first signaling protocol in the first network service flow is based on determining that the pattern matching in the first pattern matching database is for the first signaling protocol.

3. A method according to any of the preceding claims, wherein extracting the first network traffic flow identifier from the first network traffic flow is based on an indication of an offset returned together with an indication of a pattern match, in particular, wherein the first network traffic flow identifier includes a network address and a port.

4. The method according to any of the preceding claims further includes mirroring the first network service flow from the data plane to the control plane, constructing a first signaling protocol pattern database using a pattern described by a session description protocol in a first signaling protocol message, and / or applying a first policy to the network service corresponding to the first network service flow identifier.

5. The method according to any one of the preceding claims, further comprising: Based on a scan indicating a second pattern match in a signaling protocol pattern database, second application service flow identification information of an application or data protocol indicated in a payload of a first network service flow is extracted, and a first application flow identifier is formed using the first and second application service flow identification information.

6. One or more non-transitory machine-readable media having program code stored thereon, the program code comprising instructions for: Scanning a payload of a first transport layer service flow in a control plane for pattern matching in a first pattern database; detecting a session establishment message of a first application level protocol based on an indication of a pattern match in a first pattern database; selecting a second pattern database based on detecting a session establishment message of the first application level protocol, wherein the second pattern database is constructed using patterns of the first application level protocol; scanning the payload for pattern matching in a second pattern database; creating, based on the scan indicating a first pattern match in a second pattern database, a first mapping between an identifier of a first application level protocol and a first application traffic flow identifier determined from at least a first payload corresponding to the first pattern match; and The first mapping is communicated from the control plane to the data plane.

7. The non-transitory machine-readable medium of claim 6, wherein the program code further comprises instructions for: selecting a first policy from among a plurality of policies based on a first mapping in a data plane, and applying the first policy to a network service corresponding to a first application service flow identifier following a first transport layer service flow.

8. The non-transitory machine-readable medium of claim 6 or 7, wherein the program code further comprises instructions for extracting the first application traffic flow identifier from the first payload, wherein the instructions for extracting the first application traffic flow identifier from the first payload comprise instructions for: extracting the network address from the first payload based on a scan indicating a match of the first pattern in a second pattern database; and extracting the port from the first payload based on an indication that the second pattern matches in the second pattern database, The network address and the port form a first application service flow identifier.

9. The non-transitory machine-readable medium of any one of claims 6-8, wherein the second pattern database is a regular expression database.

10. An apparatus comprising: processor; and a machine-readable medium having stored thereon instructions executable by the processor to cause the apparatus, scanning a payload of a first network service flow for pattern matching in a first pattern database, detecting a session establishment message of a first application level protocol based on a scan indicating a pattern match in a first pattern database, selecting a second pattern database from a plurality of pattern databases based on detecting the session establishment message, wherein the plurality of pattern databases are constructed using patterns of the application level protocol, scanning the first network traffic flow for one or more matches in a second pattern database, creating a first mapping between an identifier of the first application level protocol and an identifier of a first predicted traffic flow determined at least in part based on the first match based on scanning the second pattern database for a match indicating at least a first match in the second pattern database, and The first mapping is transmitted to the data plane.

11. The apparatus of claim 10, wherein the machine-readable medium further has instructions executable by the processor for causing the apparatus to extract a first application traffic flow identifier from at least a first payload in a first network traffic flow corresponding to a first match.

12. The apparatus of claim 11, wherein the instructions for extracting the first application traffic flow identifier from the first payload include instructions for: extracting the network address from the first payload based on scanning the second pattern database for a match indicative of a first match in the second pattern database; and extracting the port from the first payload based on an indication of a second match in the second pattern database, In particular, wherein the network address and the port form a first application service flow identifier, And optionally, the machine-readable medium further stores thereon instructions executable by the processor for causing the apparatus to determine an offset to extract a network address and a port based at least in part on the first match.

13. The apparatus of claim 10, wherein the first application level protocol is a Session Initiation Protocol.

14. An apparatus according to claim 10, wherein the machine-readable medium also stores thereon instructions executable by the processor for causing the apparatus to create a second mapping between an identifier of the first application-level protocol and an identifier of a second predicted business flow determined at least in part based on a second match in a second pattern database.

Images