Chart Comparing Disclosures of Yu and ’859 Provisional
`
`Yu, Fig. 1 (Prior Art):
`
`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`Ex. __ (’859 Provisional), 3:
`
`Yu, Fig. 2:
`
`Ex. __ (’859 Provisional), 2:
`
`EX 1047 Page 1
`
`

`

`Yu, Fig. 3:
`
`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`Ex. __ (’859 Provisional), 5:
`
`Yu, Fig. 4 (Policy Engine Architecture):
`
`
`
`
`
`Ex. __ (’859 Provisional), 9:
`
`
`
`
`
`EX 1047 Page 2
`
`

`

`Yu, Figs 5-6:
`
`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`Ex. __ (’859 Provisional), 10:
`
`
`
`Yu, 1:1-18:
`
`
`
`RELATED APPLICATIONS
`This application claims the benefit of priority to U.S.
`Provisional Patent Application Ser. No. 60/112,859, filed Dec.
`17, 1998.
`
`TECHNICAL FIELD
`
`Ex. __ (’859 Provisional), 2:
`This document describes the system architecture of an
`embodiment of an inventive policy-based network equipment.
`This system architecture is suitable for policy-based applications
`such as Virtual Private Networks (VPN), Firewall, Traffic
`Management, Network Address Translation, Network
`Monitoring, TOS Marketing, etc.
`
`EX 1047 Page 3
`
`

`

`Yu Disclosures
`The present invention relates to policy-based network
`equipment and, in particular, to policy-based network equipment
`that employs a favorable division of hardware and software to
`provide both performance and flexibility.
`BACKGROUND
`Some typical policy-based computer network applications
`are Virtual Private Networks (VPN), Firewall, Traffic
`Management, Network Address Translation, Network
`Monitoring, and TOS Marking.
`Yu, 1:19-26:
`In general, the policy-based application has access to the
`network media through an operating system driver interface. In a
`typical network architecture, the policy-based application
`examines every packet coming in from the network along the
`data path, compares it against flow classification criteria, and
`performs the necessary actions based upon the policies defined
`in a policy database.
`Yu, 1:27-39:
`Today’s policy-based applications are challenged with
`several key issues. These issues can be major inhibitors for the
`future growth of the emerging industry:
`1) Flow classification overhead—Flow classification
`specifications can be complicated and lengthy for each
`network service. As can be seen from FIG. 1, in a
`conventional policy-based application, each packet compared
`with potentially hundreds of rules in order to find the
`matching one and determine the proper action specifications.
`With stateful applications, state tracking is even more time
`consuming. Multiple network services on a single system
`simply make matters worse.
`
`U.S. Provisional Application No. 60/112,859
`
`Ex. __ (’859 Provisional), 2:
`The policy-based application typically has access to the media
`through an OS driver interface. It examines every packet coming
`in from the network along the data path, compares it against the
`flow classification criteria, and performs the necessary actions
`based upon the policies defined in the policy database.
`
`Ex. __ (’859 Provisional), 4:
`Now, some Policy Engine design considerations are discussed.
`Today’s policy-based applications are challenged with several
`key issues. These issues can be major inhibitors for the future
`growth of the emerging industry:
`1) flow classification overhead - Flow classification specs can be
`complicated and lengthy for each network service. Each
`packet needs to be compared with potentially hundreds of
`rules in order to find the matching one and determine the
`proper actions. With stateful applications, state tracking is
`even more time consuming. Multiple network services on a
`same system simply make matters worse.
`
`EX 1047 Page 4
`
`

`

`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`
`Ex. __ (’859 Provisional), 3-4:
`When a packet arrives, a flow classifier typically classifies the
`packet and finds a action spec according to some predefined
`matching criteria. The found action spec is then passed to a
`action processor for policy enforcement. The process of flow
`classification and action processing may repeat for many
`iterations as multiple policies are activated at the same time as
`shown in the Fig 2. For example, a VPN (virtual private
`network) application may comprise Firewall Policy, IPSEC
`Policy, IPCOMP (IP compression) policy, NAT (Network
`Address Translation) Policy, QoS (Quantity of Service)policy,
`Monitoring Policy, L2TP/PPTP (L2 Tunnel Protocol/Point To
`Point Tunnel Protocol) Tunnel Policy, and so on.
`
`
`Yu, 1:40-62:
`As is also shown in FIG. 1, the process of flow classification
`and action processing may repeat for many iterations as
`multiple policies are activated at the same time. For
`example, a VPN (virtual private network) application may
`comprise Firewall Policy, IPSEC Policy, IPCOMP (IP
`compression) policy, NAT (Network Address Translation)
`Policy, QoS (Quality of Service) policy, Monitoring
`Policy, L2TP/PPTP (L2 Tunnel Protocol/Point To Point
`Tunnel Protocol) Tunnel Policy, and so on.
`The flow classification is a rule based operation that can be
`very flexible to tune to application needs. For example, it
`may define a rule to identify packets with a pattern of any
`random byte within a packet, and/or across many packets.
`The flow classifiers may also differ per action processor for
`performance optimization. As a result the matching criteria
`used by a flow classifier to classify a flow may include a
`specific value, a range, or wildcard on interface port
`numbers, protocols, IP addresses, TCP ports, applications,
`application data, or any user specifiable criteria. The
`distinctions of various implementation makes it difficult to
`cache a flow with its decision in many ways.
`
`The flow classification is a rule based operation can be very
`flexible to tune to application needs. For example, it may define
`a rule to identify packets with a pattern of any random bytes
`within a packet, and/or across many packets. The flow classifiers
`
`
`
`EX 1047 Page 5
`
`

`

`Yu Disclosures
`
`Yu, 1:63-2:50:
`2) Flow classification technique is evolving—Flow classification
`and analysis technique is more than just looking into the
`packet’s address, port number and protocol type and or other
`header information. It often involves state tracking for newer
`applications. This technique is being continuously modified
`and, therefore, is not practically appropriate for a hardware
`based implementation. Furthermore, flow classification
`techniques are often viewed as key differentiaters between
`vendors.
`3) Action execution speed—Once the classification process is
`complete, the proper actions need to be executed. Some of the
`actions are simple like a discard or forwarding decision for a
`firewall, while some others are extremely time consuming,
`like triple-DES encryption and SHA hashing algorithm or
`QOS scheduling algorithm. Software based implementations
`cannot keep up with the bandwidth expansion as newer and
`faster media technologies are employed.
`4) Integrated services—As more and more policy-based
`applications become available, it is desirable to provide
`integrated services on a single platform because this
`ostensibly reduces policy management complexity, avoids
`potential policy conflicts, and lowers the TCO (Total Cost of
`
`U.S. Provisional Application No. 60/112,859
`may also differ per action processor for performance
`optimization.
`As a result the matching criteria used by a flow classifier to
`classify a flow may include a specific value, a range, or wildcard
`on interface port numbers, protocols, IP addresses, TCP ports,
`applications, application data, or any user specifiable criteria.
`The distinctions of various implementation makes it difficult to
`cache a flow with its decision in many ways.
`Ex. __ (’859 Provisional), 4:
`2) flow classification technique is evolving - Flow classification
`and analysis technique is more than just looking into the
`packet’s address, port number and protocol type and or other
`header information. It often involves state tracking for newer
`applications. This technique is a continuous improving
`process and not suitable for hardware based implementation.
`And most importantly, flow classification techniques are often
`viewed as the key differentiators for vendors.
`3) action execution speed - Once the classification process is
`complete, the proper actions need to take place. Some of the
`actions are simple like discard or forwarding decision for
`firewall, while some others are extremely time consuming like
`triple-DES encryption and SHA hashing algorithm or QOS
`scheduling algorithm. Software based implementations cannot
`keep up with the bandwidth expansion as the industry moves
`into newer and faster media technologies.
`4) integrated services - As more and more policy-based
`applications become available, it is desirable to provide
`integrated services on a single platform because it reduces
`policy management complexity, avoids potential policy
`conflicts, and lowers the TCO (Total Cost of Ownership). On
`the other hand, integrated services impose a huge computing
`
`EX 1047 Page 6
`
`

`

`Yu Disclosures
`Ownership). On the other hand, integrated services impose a
`very large computing power requirement that cannot be
`practically achieved with off-the-shelf general purpose
`machines. A disadvantage of the conventional architecture is
`that, because it is primarily software-based, it is relatively
`high overhead. However, precisely because it is software-
`based, it is quite flexible.
`What is desired is a policy architecture has the flexibility of
`present flow classification systems, but that also has lower
`overhead.
`
`BRIEF DESCRIPTION OF THE FIGURES
`FIG. 1 is a block diagram illustrating conventional flow
`classification and action processing.
`FIG. 2 is a block diagram illustrating the a broad aspect of a
`policy architecture in accordance with an embodiment of the
`invention.
`FIG. 3 is a block diagram illustrating details in accordance
`with one embodiment of FIG. 2.
`FIG. 4 illustrates more details of how the FIG. 3 architecture
`is employed to process network data.
`FIGS. 5 and 6 illustrate headers added to the packets by the
`stream classification module for use by the action processors.
`DETAILED DESCRIPTION
`As shown broadly in FIG. 2 and in greater detail in FIG. 3, in
`accordance with one embodiment of the invention, an
`architecture 100 for applying policies to network data traffic
`allocates the application of policies between software and
`hardware such that the system is flexible yet efficient.
`Yu, 2:51-54:
`
`U.S. Provisional Application No. 60/112,859
`power requirement that simply can not be achieved with off-
`the-shelf general purpose machines.
`
`
`
`Ex. __ (’859 Provisional), 2:
`
`EX 1047 Page 7
`
`

`

`Yu Disclosures
`The architecture 100 includes three major components—a
`Policy-Based Application 102, a Policy engine API 104 (“API”
`stands for Application Program Interface”) and a Policy engine
`106.
`
`Yu, 2:54-3:12:
`As can be seen from FIGS. 2 and 3, the policy-based
`application 102—such as a firewall, virtual private network
`(VPN), or traffic management—is typically a “legacy” software
`program residing on a host, equipped with its own policy
`database 202 and flow classifier logic 204.
`The policy engine API 104 serves as an interface between the
`policy application 102 and the policy engine 106 (via a system
`bus 105). The policy engine 106 is a purpose-built hardware
`(preferably running at wire speed) that operates on input network
`traffic and network policies and that outputs regulated traffic
`flows based upon the network policies.
`In a typical embodiment, the policy engine API 104 provides
`the policy-based application 102 access to all the media I/O
`through a generic operating system driver interface. In addition,
`the API 104 allows the application 104 to invoke acceleration
`functions (shown in FIG. 3 as application processors 206, or
`“AP’s”) provided by the policy engine 106. The application
`processors 206 operate based on the stream classifier 207 of the
`policy engine 106 determining that a packet belongs to a
`particular stream and activating the appropriate action processors
`206 according to action specifications 210 in a policy cache 209.
`That is, overall system performance is enhanced by virtue of the
`appropriate acceleration functions (action processors 206) of the
`policy engine 106 being activated to regulate the network traffic.
`
`U.S. Provisional Application No. 60/112,859
`The architecture includes three major components – Policy -
`Based Application, Policy Engine API and a Policy Engine. Of
`course, each of these components may be inventive in and of
`itself.
`
`Ex. __ (’859 Provisional), 2:
`Policy-Based Application: A policy-based application such as
`firewall, VPN, or traffic management is typically a software
`program residing on a host, equipped with its own policy data
`base and flow classification logic. The policy-based application
`typically has access to the media through an OS driver interface.
`It examines every packet coming in from the network along the
`data path, compares it against the flow classification criteria, and
`performs the necessary actions based upon the policies defined
`in the policy database.
`Policy Engine API (PAPI): This API serves as an interface to
`the policy engine. It allows the policy-based application to
`access to all the media I/0 through a generic OS driver interface.
`In addition, the API allows the application to invoke the
`acceleration functions provided by the policy engine. The
`application can speed up the overall system performance by
`turning on the appropriate acceleration functions (action
`processors) on the policy engine.
`Policy Engine: A Policy Engine is a purpose-built hardware
`engine that takes in two inputs - network traffic and network
`policies. It then outputs regulated traffic flows based upon the
`specifications of the network policies. The Policy Engine
`preferably runs at wire speed.
`
`
`EX 1047 Page 8
`
`

`

`Yu Disclosures
`
`Yu, 3:13-3:49:
`Before proceeding, several terms are defined in the context
`of FIGS. 2 and 3. The definitions provided herein are meant to
`be explanatory, and not necessarily limiting when a similar or
`identical term is used in the claims.
`Service
`A service in a policy-based network defines a network
`application 102 that is controlled and managed based on a set of
`policies. Typical services are firewall, VPN, traffic management,
`network address translation, network monitoring, etc.
`Policy
`Policies (normally defined by network managers) are
`collectively stored in a policy database 202 accessible to the
`policy-based applications 102 (even conventionally) and
`describe network traffic behaviors based upon business needs. A
`policy specifies both what traffic is to be subject to control and
`how the traffic is to be controlled. Thus, a policy typically has
`two components—a flow classification specification 203a and
`an action specification 203b.
`Flow Classification Specification 203a
`A flow classification specification 203a provides the
`screening criteria for the flow classifier logic 204 to sort network
`traffic into flows. A flow classification specification 203a can be
`very elaborate, as detailed as defining a specific pair of hosts
`running a specific application. Alternately, a flow classification
`specification 203a can have a simple wildcard expression.
`Action Specification 203b
`An action specification 203b describes what to do with
`packets that match an associated flow classification specification
`203a. The action specification 203b can be as simple, for
`
`U.S. Provisional Application No. 60/112,859
`Ex. __ (’859 Provisional), 2-3:
`Before describing a detailed embodiment, several terms are
`defined.
`Service
`A Service in a policy-based network defines a network
`application that is controlled and managed by a set of
`policies. Typical services are firewall, VPN, traffic
`management, network address translation, network
`monitoring, etc.
`Policy
`A Policy is defined by network managers to describe network
`traffic behaviors based upon business needs. It specifies what
`types of traffic are subject to policy control and how to
`control them. A policy has two components: Flow
`Classification Spec and Actions Spec.
`Flow Classification Spec
`Flow Classification Spec provides the screening criteria for
`a classifier to sort the packets of network traffic into flows.
`The Flow Classification Spec can be very elaborate. They
`can be as detailed as defining a pair of hosts running a
`specific application. Alternately, they can have a simple
`wildcard expression.
`Action Spec
`Action Spec is to describe what to do with packets that match
`the Flow Classification Spec. The Action Spec can be as
`simple as a discard or forward decision in the firewall case. It
`can also be as complicated as IPSec encryption rules based
`on SA (Security Association) spec.
`Flow
`
`EX 1047 Page 9
`
`

`

`Yu Disclosures
`example, as a discard or forward decision in the firewall case. It
`can also be as complicated as IPSec encryption rules based on a
`SA (Security Association) specification.
`Flow
`All packets that match the same flow classification
`specification 203a form a flow.
`Yu, 3:50-62:
`Flow Classifier
`Referring again to FIG. 3, a policy decision is at least initially
`derived by a policy-based application from the policy database
`202. As discussed above, a flow is a stream of correlated packets
`to which policy decisions apply. With the described
`embodiments in accordance with the invention, referring again
`specifically to FIG. 3, for at least some of the packets, a flow
`classifier 204 classifies the packet according to one or more
`classification specifications 203a and finds one or more
`corresponding action specifications 203b. The found action
`specifications 203b are then provided to the policy cache 209 for
`later execution by the policy engine 106 to enforce the policy.
`
`U.S. Provisional Application No. 60/112,859
`All packets that match the same Flow Classification Spec
`form a Flow.
`
`Ex. __ (’859 Provisional), 3-4:
`Flow Classifier
`In a typical conventional policy-based network, a policy
`decision is typically derived from a policy database. As
`discussed above, a flow is a stream of correlated packets to
`which policy decisions apply.
`When a packet arrives, a flow classifier typically classifies
`the packet and finds a action spec according to some
`predefined matching criteria. The found action spec is then
`passed to a action processor for policy enforcement. The
`process of flow classification and action processing may
`repeat for many iterations as multiple policies are activated at
`the same time as shown in the Fig 2. For example, a VPN
`(virtual private network) application may comprise Firewall
`Policy, IPSEC Policy, IPCOMP (IP compression) policy,
`NAT (Network Address Translation) Policy, QoS (Quantity
`of Service)policy, Monitoring Policy, L2TP/PPTP (L2
`Tunnel Protocol/Point To Point Tunnel Protocol) Tunnel
`Policy, and so on.
`
`EX 1047 Page 10
`
`

`

`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`
`
`
`The flow classification is a rule based operation can be very
`flexible to tune to application needs. For example, it may
`define a rule to identify packets with a pattern of any random
`bytes within a packet, and/or across many packets. The flow
`classifiers may also differ per action processor for
`performance optimization.
`As a result the matching criteria used by a flow classifier to
`classify a flow may include a specific value, a range, or
`wildcard on interface port numbers, protocols, IP addresses,
`TCP ports, applications, application data, or any user
`specifiable criteria. The distinctions of various
`implementation makes it difficult to cache a flow with its
`decision in many ways.
`Ex. __ (’859 Provisional), 4:
`Policy Binding
`Policy Binding is the process to bind a stream with its
`associated action specs.
`
`
`
`Yu, 3:63-67:
`Policy Binding
`Policy binding is the process of the flow classifier 204
`binding a stream with its associated action specification and
`loading the appropriate entries (stream specification 208 and
`action specifications 210) into the policy cache 209.
`
`EX 1047 Page 11
`
`

`

`Yu Disclosures
`
`Yu, 4:1-36:
`Stream
`A stream is an “instantiation” of a flow—packets that have
`the same source and destination address, source and destination
`port, and protocol type. (Optionally, the application can add the
`input and output media interface to the stream classification
`criteria in addition to the packet header if desired.) Packets may
`be sorted into streams, and a flow may include one or more
`streams. All packets belonging to the same stream are to be
`regulated by the same policy.
`Policy Cache 209
`At the completion of the policy binding process, an entry for
`a given stream is created on the policy engine which contains all
`the policy information required to subsequently process data of
`the stream
`Integrated Services
`When multiple network services are to apply to the same
`flow, this is called “Integrated Services”. Integrated Services
`simplify the management of various service policies, minimize
`potential policy conflicts and reduce TCO (Total Cost of
`Ownership).
`Stream Specification
`A stream specification 208, shown in FIG. 3 held in policy
`cache 208 is the criteria used by the stream classifier 207 to
`uniquely identify a stream. In one embodiment, the stream
`specification 208 is compared to a 5-tuple in a packet header—
`source and destination address, source and destination port, and
`protocol type.
`Action Processor 206
`
`U.S. Provisional Application No. 60/112,859
`Ex. __ (’859 Provisional), 3-4:
`Stream:
`A Stream is a stream of packets that have the same source
`and destination address, source and destination port, and
`protocol type. (Optionally, the application can add the input
`and output media interface to the stream classification
`criteria in addition to the packet header if desired.)
`RapidStream policy engine sorts packets into Streams. A
`flow may include of one or more Streams. All packets
`belong to the same Stream share the same policy.
`Stream Spec
`A Stream Spec is the criteria used by the Stream Classifier to
`uniquely identify a stream. In one embodiment, it is the 5-
`tuple in a packet header- source and destination address,
`source and destination port, and protocol type.
`Integrated Services
`When multiple network services are to apply to the same
`flow, it is called “Integrated Services”. Integrated Services
`simplify the management of various service policies,
`minimize potential policy conflicts and reduce TCO (Total
`Cost of Ownership).
`Stream Classifier
`Stream Classifier is the component that classifies packets into
`Streams based upon the packets’ header info.
`Action Processor
`Action Processor is the component that executes the action
`based upon the action spec.
`Policy Cache
`
`EX 1047 Page 12
`
`

`

`Yu Disclosures
`Each action processor 206 executes an action based upon an
`action specification 210 in the policy cache 209.
`Packet Tagging
`Certain applications (e.g. Network Monitoring) would like to
`receive flows based on the flow classification specification and
`would prefer that flow classification be performed for them.
`Packet tagging is a way of tagging all incoming packets with an
`application specified “tag [sic]
`
`Yu, 4:37-4:45:
`Policy-based Application
`A policy-based application provides a service to the network
`users. This service is managed by a set of policies. Firewall,
`VPN and Traffic Management are the most typical policy-based
`applications. As the industry evolves, policy-based applications
`are likely to consolidate onto a single platform called Integrated
`Services. Integrated Services has the benefits of centralized
`policy management and lower cost of ownership.
`Yu, 4:46-5:34:
`Referring still to FIG. 3, the population and use of the policy
`cache 209 is now discussed in greater detail. As discussed
`above, the policy-based application 102 (typically a legacy
`application) is equipped with its own policy database 202 and
`flow classifier logic 204. Some of the packets of a stream are
`provided (via a data path shown logically as 401 in FIG. 3) to
`the flow classifier 204. The flow classifier 204 uses the policy
`database 202 to determine the action specifications 203b that
`correspond to the policies of the flow to which the stream
`belongs. The action specifications are provided (via the path
`
`U.S. Provisional Application No. 60/112,859
`At the completion of the policy binding process, an entry for
`a given Stream is created on the policy engine which contains
`all the policy info (Action Specs, etc.). The collection of all
`active entries is called Policy Cache.
`Packet Tagging
`Certain applications (e.g. Network Monitoring) would like to
`receive flows based on the flow classification spec and would
`prefer the policy engine to do the flow classification for
`them. Packet Tagging is a way of tagging all incoming
`packets with an application specified “tag”.
`Ex. __ (’859 Provisional), 5:
`Policy-based Application
`A policy-based application provides a service to the network
`users. This service is managed by a set of policies. Firewall,
`VPN and Traffic Management are the most typical policy-based
`applications. As the industry evolves, policy-based applications
`are likely to consolidate onto a single platform called Integrated
`Services. Integrated Services has the benefits of centralized
`policy management and lower cost of ownership.
`Ex. __ (’859 Provisional), 5-8:
`A policy-based application is typically equipped with its own
`policy database and flow classifier. A policy database contains a
`list of policies. Each policy has two fields – the flow
`classification spec and the action spec. The flow classification
`spec is used by the flow classifier to sort the incoming network
`traffic into flows. The action spec is to instruct the application
`what to do with the packets associated with that flow. The
`application performs the proper actions against the packets based
`upon the policy database for each flow. The massaged packets
`are then forwarded to the destination.
`
`EX 1047 Page 13
`
`

`

`Yu Disclosures
`shown logically as 402 in FIG. 3) to the policy cache 209. It
`should be noted that multiple packets may be required for more
`sophisticated flow classification (stateful packet inspection),
`since the policy decisions (action specifications) may come from
`different applications which may have implemented different
`flow classifiers. In those cases, the application’s flow
`classification logic keeps track of the flow’s state until a
`matching criteria is met. Preferably, though, just enough packets
`of a stream are provided to the flow classification logic 204 via
`theological path 401 to properly determine the action
`specifications 203b for the stream. At the end of the “learning
`phase”, the application software 102 has uniquely identified a
`policy for the incoming packet stream
`Subsequent packets of the stream are then provided directly
`to the stream classifier 207 of the policy engine 106 via the
`logical data path 403. Using the policy cache 209, the stream
`classifier 207 determines which action processors 206 are to be
`activated for the packets of the stream. Specifically, the stream
`classifier 207 matches the packets to a particular stream
`specification 208 and then, using the corresponding action
`specifications 210, activates the proper action processors 206.
`Significantly, these “subsequent packets” can be acted upon
`without. any interaction to the “host” policy-based application
`102. The application need not “see” any packets belonging to
`that stream after the binding (unless the stream is actually
`destined for the host.). The action processors are specialized in
`executing specific action specifications, preferably at the wire
`speed.
`Thus, in summary, upon the completion of the policy binding
`“learning” process, the policy engine 106 may immediately take
`control of the bound stream and execute the appropriate actions
`in accordance with the action specifications 210 in the policy
`
`U.S. Provisional Application No. 60/112,859
`This is shown to a different level of detail in Fig. 4:
`
`
`
`Policy Engine
`The policy engine has a built-in Stream Classifier and multiple
`of special purpose Action Processors. The stream classifier
`works in concert with the application’s flow classifier to
`accelerate the classification process. The action processors are
`specialized in executing specific action specs at the wire speed.
`Each of the action processors can be enabled or disabled on a per
`stream basis. The policy engine uses a data structure called
`Policy Cache to keep track of all the active streams and the
`action specs associated with the streams. The policy cache is
`created on the fly by the policy engine and they are referenced
`by the stream classifier and the action processors for acceleration
`
`EX 1047 Page 14
`
`

`

`U.S. Provisional Application No. 60/112,859
`of action execution. This data structure can be managed and
`controlled by the application through the policy engine API.
`
`Yu Disclosures
`cache 209 without any intervention from the “host” (policy-
`based) application. This method also relieves the policy engine
`106 hardware from doing complicated pattern matching because
`it can simply compute a hash value (or use some other
`identification function) from the well known fields (which
`uniquely identify a stream) of the packet to find its
`corresponding policy decisions (action specifications 210). The
`classification need not be done more than once for each packet
`even though there may be multiple applications. As a result,
`massive computing power is not required to do the classification
`on an ongoing basis. A benefit is inexpensive hardware cost for
`very high performance policy-based applications.
`
`
`The policy engine is enabled through the policy binding process.
`This process is to bind an incoming stream with its associated
`action specs. This process may be broken down into 3 phases:
`Phase 1 – Policy Learning
`When the first packet of a new stream arrives, it is passed up to
`the policy-based application (generally a legacy application) for
`flow classification. The application classifies the flow by
`matching the incoming packet against the policy database. If the
`packet matches one of the policy’s classification spec, the
`corresponding action spec is then retrieved and thus completes
`the policy learning phase. More packets may be used. In fact, it
`may take multiple packets for more sophisticated flow
`classification (stateful packet inspection), since the policy
`decisions (action specs) may come from different applications
`
`EX 1047 Page 15
`
`

`

`Yu Disclosures
`
`U.S. Provisional Application No. 60/112,859
`which may have implemented different flow classifiers. In those
`cases, the application’s flow classification logic keeps track of
`the flow’s state until a matching criteria is met.
`As shown in Fig. 5, in one particular implementation, a stream
`oriented table is implemented as the policy cache to cache the
`policy (action specs) on a per stream basis. A network stream
`has a finer granularity than flow criteria used by flow classifiers
`to uniquely identify a traffic. As the first packet of a flow
`arrives, the hardware forwards the packet to the host software
`module and requests for policy decisions (action specs). After
`having the packet classified by flow classifiers, the Agent
`collects the policy decisions and offloads them to the policy
`engine along with a stream spec which is used to identify a
`stream. Policy engine then creates a stream entry according to
`the stream spec and records it and its action specs in the entry.
`Phase 2 – Policy Binding
`At the end of phase 1, the application software has uniquely
`identified a policy for the incoming packet stream. The
`application can then accelerate the execution of the actions
`associated with the stream by offloading the action spec from the
`application to the policy engine. This process is called policy
`binding – it binds a unique stream, which is identifiable with the
`packet’s header (e.g., 5-tuple), with the action specs retrieved
`from the policy database. The action specs activate the
`corresponding action processors to execute the actions for the
`specified stream.
`Phase 3 – Policy Execution
`Upon the completion of policy binding process, the polic