WO2017174499A1

WO2017174499A1 - Optimized storage of service definitions in common policy and charging control rule space

Info

Publication number: WO2017174499A1
Application number: PCT/EP2017/057841
Authority: WO
Inventors: Ulf Mattsson; Ibon Gochi Garcia; Hans Mattsson; Miguel Angel MUÑOS DE LA TORRE ALONSO; Maria Belen PANCORBO MARCOS; Linus ANDERSSON
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-04-04
Filing date: 2017-04-03
Publication date: 2017-10-12

Abstract

A method performed in a packet inspection node (101, 203) and a packet inspection node including a common area (103) for storing service definitions wherein the stored service definitions are partitioned into separately accessible sub-libraries (107-1-107-N) and a user space (105) for storing a link (111-1, 111-2, 111-M) to a sub-library (107-1, 107-2, 107-N ) comprising the service definition. The method comprising: receiving (1) a request from an application (201) indicating a requested service definition; detecting (2) whether the requested service definition is stored in the common area (103); forwarding (3) the request comprising the service definition after determining that the service definition is not stored in the common area (103), or update the link in the user space to the sub-library in the common area (301) associated with the service definition if the requested service definition is stored in the common area (301).

Description

OPTIMIZED STORAGE OF SERVICE DEFINITIONS IN COMMON POLICY AND CHARGING CONTROL RULE SPACE

TECHNICAL FIELD

Embodiments presented herein relate to a method and node for handling service definitions in a communication system network. BACKGROUND

Users of various types of equipment (e.g., mobile user equipment, personal computers, etc.) are able to access a variety of different services via communications networks. For example, providers of information content (e.g., audio, and/or video) and or applications (e.g., messaging services) are more and more making such content/applications available in so-called Over The Top

(OTT) arrangements, in which the traditional intermediary distribution channels (e.g., cable television providers) that are able to impose their own control over the content/applications are eliminated, with the content/applications being provided essentially directly to the end user via an operator's communications network.

The network operator nonetheless still needs to impose and enforce rules on the data flow between the content/application provider and the end user, and this is the role of the Policy and Charging Control (PCC) function, with policy enforcement being implemented in the user space via its Policy and Charging Enforcement Function (PCEF).

In order to be able to differentiate between the various services running in an operator's network, the service has to be identified. The identification is done by means of packet inspection performed by a Deep Packet Inspection (DPI) module or similar (further called Packet Inspection Classification Engine - "PICE") within the operator domain. To identify services (e.g. such as information content and/or applications etc), service definitions such as server

Internet Protocol (IP) addresses, hostnames, Universal Resource Locators (URLs) or parts of the mentioned are provisioned into the packet inspection classification engine. The service definition may e.g. correspond to a Packet Flow Description (PFD), which is a set of information enabling the detection of application traffic provided by a 3rd party service provider, see 3GPPP TS 23.203. A PFD is further defined in 3GPP TS 23.682 as a set of information including PFD (Packet Flow Description) is a set of information enabling the detection of application traffic including: PFD id; and a 3-tuple including protocol, server side IP address and port number; or the significant parts of the URL to be matched, e.g. host name; or a Domain name matching criteria. Moreover, based on agreements, the PFD can be designed to convey proprietary extension for proprietary application traffic detection mechanisms.

Today, service definitions are often provided to the operator by the content provider that runs the service. Then the service definitions are provisioned out to all packet inspection classification engines inside the operator's network. There is presently work ongoing in 3GPP Rel. 14 standardization to support provisioning of a large amount of service definitions (Reference "Sponsored Data Connectivity Information" - SDCI).

An alternative approach presently under consideration is to have service definitions pulled from servers, either in the content provider domain or in the operator domain. Doing a pull of service definitions instead of provisioning them demands a carefully planned architecture in the packet inspection service classification engine, in order to avoid having too high a load in it. For example, one potential problem is that, if service definitions are pulled from a server, they might be stored in a user space, taking up too much memory if many users have their own copy.

Another area of concern is that, if a common space is used to store service definitions, this common space must be handled with care so as not to introduce errors into it. Two problems are seen:

- Corruption of the database caused when dynamic change is performed by a write command. Possible introduction of overlapping rules for different applications. Further, the related protocol that conveys the service definitions must be adapted to effectively make use of the architecture. BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings in which:

FIG. 1 depicts aspects relating to the storage of PCC rules.

FIG. 2 is a signaling/flow diagram of an exemplary pull sequence, carried out in aspects of some but not necessarily all embodiments.

FIG. 3 is a block diagram of elements for carrying out various aspects of the invention as described above, such as in connection with FIGS. 1 and 2.

DETAILED DESCRIPTION

The various features of the invention will now be described with reference to the figures, in which like parts are identified with the same reference characters.

The various aspects of the invention will now be described in greater detail in connection with a number of exemplary embodiments. To facilitate an understanding of the invention, many aspects of the invention are described in terms of sequences of actions to be performed by elements of a computer system or other hardware capable of executing programmed instructions. It will be recognized that in each of the embodiments, the various actions could be performed by specialized circuits (e.g., analog and/or discrete logic gates interconnected to perform a specialized function), by one or more processors programmed with a suitable set of instructions, or by a combination of both. The term "circuitry configured to" perform one or more described actions is used herein to refer to any such embodiment (i.e., one or more specialized circuits alone or in combination with one or more programmed processors). Moreover, the invention can additionally be considered to be embodied entirely within any form of nontransitory computer readable carrier, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Thus, the various aspects of the invention may be embodied in many different forms, and all such forms are contemplated to be within the scope of the invention. For each of the various aspects of the invention, any such form of embodiments as described above may be referred to herein as "logic configured to" perform a described action, or alternatively as "logic that" performs a described action.

It should be emphasized that the terms "comprises" and "comprising", when used in this specification, are taken to specify the presence of stated features, integers, steps or components; but the use of these terms does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Moreover, reference letters may be provided in some instances (e.g., in the claims and summary) to facilitate identification of various steps and/or elements. However, the use of reference letters is not intended to impute or suggest that the so-referenced steps and/or elements are to be performed or operated in any particular order.

In an aspect of exemplary embodiments, service definitions for a service are pulled from a server.

Further, aspects of exemplary embodiments introduce a way to optimize the handling of dynamically updated Service Definitions (SDs) storage in common space in Packet Inspection Classification Engines by a version handling mechanism.

Aspects relating to the storage of PCC rules will now first be discussed with reference to FIG. 1. A Packet Inspection Classification Engine (PICE) 101 node includes a common area 103 and a user space 105 in its storage. The common area 103 includes storage for service definitions for content/applications that may use the operator's network. In one aspect, the service definitions are partitioned into a number, N, of sub-libraries 107-1, 107-2, ..., 107-N. Each sub- library includes service definitions for a particular application (or version of an application), and preferably additionally includes the corresponding Application Module ID and/or a version indicator (when applicable).

The user space 105 stores information related to users of the network (in this example, M users), with each user having its own stored information 109-1, 109-2, ..., 109-M. Each user's information 109-x includes a list of Application Module IDs (optionally with corresponding version indicators) of the applications that that particular user is using. The list also includes, for each active

Application Module ID, a link 111-x (e.g., one of the illustrated links 111-1, 111- 2, ..., 111-M) that is used to access one of the sub-libraries 107-1, 107-2, ..., 107- N. In this way, the correct set of Service Definitions for a particular

application/version may be retrieved and used. It will be seen that each of the sub-libraries 107-1, 107-2, 107-N has a corresponding link 111-1, 111-2, 111-M.

In one aspect, this arrangement provides for efficient storage of Service Definitions because, if several users are running the same version of the same application, they can each have links that point to the same single copy of the sub- library 107-x stored in the common area 103. Thus, it is not necessary (although not precluded) to store an individual copy of the same Service Definitions for each user that requires the Service Definition in question. If the users should have had their own copy of the Service Definition that would occupy much more memory in the PICE 101 , particularly in case many users have their own copy of the same Service Definition. As a non-limiting example, FIG. 1 shows an instance in which two users (User 2 and User M) are both running version "y" of

Application Module ID "b". Consequently, each has a link 111-2 that points to the same sub-library 107-2 in the common area 103.

As a non-limiting example, each link 111 -x can be implemented as an HTTP URL or some other pointer or label or similar structure indicating a sub- library and/or set of one or more service definitions for one or more

contents/ applications .

An advantage of this arrangement is that, if an error occurs while storing the data (e.g., service definitions), only that particular sub-library 107-x will be corrupted, not the complete common area 103. Also, only the users that have the links activated will be exposed to possible overlapping rules.

In another aspect of some but not necessarily all embodiments consistent with the invention, a parameter is provided that indicates the version of the data provided in a request and/or a response to a service definition pull from the server. This parameters supports the handling of common rules for all users or a group of users. The version parameter is stored together with the service definitions in the sub-libraries 107-x within the common area 103. If the version received in a request/response is the same as the version of service definitions already available in the packet inspection classification engine 101, it only updates the links in user space 105 to point to the existing sub-library 107-x. But if the version indicated in a request/response is different from the stored one, the new version is stored in the common area 103 (e.g., a new sub-library 107-x is created) and the link 111-x pointing to this is updated in user space 105-x for those applications that need to access the service definitions.

In yet another aspect of some but not necessarily all embodiments consistent with the invention, a Time-To-Live parameter (TTL_sd) is present, which describes the time -period during which a service definition is considered valid in the common space. When TTL_sd has timed out, a new pull of service definition is needed. The value of TTL_sd might be set by the content provider or by the operator. The TTL_sd parameter for each sub-library 107-x can be stored in the common area 103, but this is not an essential aspect of embodiments consistent with the invention.

Since the links reside in user space 105, they can be activated and terminated independently and dynamically for each user. One might for instance introduce a TTL_USer parameter that is valid for a particular user (e.g., one of the illustrated users 1, ..., M). When the time period TTL_USer has timed out, the link 111-x in user space 105 to the sub-library 107-x is removed. The TTL_USer can be set by the content provider or by the operator.

FIG. 2 is a signaling/flow diagram of an exemplary pull sequence, carried out in other aspects of some but not necessarily all embodiments. The illustrated steps and signaling are performed by hardware/nodes associated with respective ones of application(s), operator space (e.g., PICE), and server(s).

In step 1, an application 201 (e.g., run in a User Equipment - UE) sends a trigger request to the PICE 203 node in operator space. The trigger request includes a parameter, Application-module-ID, that uniquely indicates and/or describes the application and/or application properties (e.g., some but not necessarily all properties) and in some embodiments even what part within an application a user is using at the moment. In some but not necessarily all embodiments, the trigger request may also include an optional user time to live parameter, TTL_USer, that specifies for how long this user's link to the service definitions should remain valid.

Although the example of step 1 depicts an Application 201 itself triggering the request and, via a predefined protocol, sending the request to the PICE 203, this example is not intended to be limiting. Rather, the various aspects illustrated by the example are applicable in other cases as well, such as when the illustrated request (e.g., shown in step 1) is triggered by some sort of packet inspection (e.g., Deep Packet Inspection - DPI) without the Application 201 (e.g., in the UE) explicitly being aware of it.

In step 2, in response to receiving the trigger request, the PICE 203 in some embodiments simply forwards the request to the intended server 205

(step 3). But in some alternative embodiments, an optimization is included, herein referred to as "fast path." The fast path optimization is intended to circumvent the round trip time to the server 205 and back, and operates by having the PICE 203 read the Application-module-ID presented in the trigger request and then use it to detect if the service definitions related to the indicated version are already present in the common area 103 of the PICE 203. The detection may, for example, be based on a version parameter (e.g., a Service Definition - SD - version or other) included in or with the Application-module-ID. If the service definitions do exist in the PICE 203, links 111-x to the service definitions 107-x are added in user space 105 or updated if already available, and the PICE 203, instead of forwarding the trigger request to the server 205, jumps to step 7. In step 4, the server 205 responds to receipt of the Application trigger request received in step 3 by obtaining the applicable service definitions (e.g., locating them based on the Application-module-ID and retrieving them from storage) and producing a response that contains the applicable service definitions. The response also includes the SD version parameter(s) (when applicable). In some but not necessarily all embodiments, the response also includes one or more of the above-mentioned time to live parameters, TTL_sd and a TTL_USer.

In step 5, the Application trigger response is sent by the server 205 to the PICE 203.

It is noted at this point that, in the illustrated example, a single server 205 is depicted, and this is shown being outside of operator space 203. However, this is not the case in all instances. The server 205 can, for example, reside within the operator space. In yet another example, the server 205 may actually itself comprise a plurality of servers (not shown), one or more of which are within the operator space and one or more others of which are outside of operator space.

In step 6, the PICE 203 examines the Application-module-ID and the SD version parameter that it received in the Application trigger response sent in step 5, and checks to see if the service definitions related to the version already exist in the common area 103. If it exists, a link 111-x to the service definitions 107-x is added in user space 105 or updated if already available. If the service definitions are not already stored in the common area 103, then the service definitions are fetched and stored in the common area 103 as described earlier. Then, links 111-x to the service definitions 107-x are created in user space 105.

To complete this aspect of the protocol, the PICE 203 may send an Application trigger response (step 7) into back to the application 201 (or other entity) that sent the initial Application trigger request. The Application trigger response includes, for example, the Application-module-ID, information indicating the outcome of the trigger.

In some but not necessarily all embodiments, the PICE 203 might also create or use incoming TTL_sd and TTL_USer parameters. The TTL_USer parameter can optionally be included in the Application trigger response that is sent to the application 201. As mentioned earlier, the parameters TTL_sd and TTL_USer indicate respectively how long a set of service definitions and how long a user's access to a set of service definitions will remain valid. This can be implemented by means of a timer that is set for the amount of time indicated in the parameter (step 8). When TTL_sd has timed out, the service definitions and the SD version parameter are removed from the common area 103. All links 111-x to the removed sub- library 107-x are removed as well. When TTL_USer has timed out, the link 111-x to the related sub-library 107-x of service definitions is erased, but only for that particular user. The link to that sub-library 107-x of service definitions may remain valid for other users.

If the Application 201 intends to keep the link 111-x to the Service Definitions for a longer time period than specified by the TTL_USer parameter, then it issues a new Application trigger request (step 9) before the TTL_USer time period expires. The Application 201 will have been informed of the actual effective lifespan of its link to the Service Definitions by the inclusion of the TTL_USer parameter in the Application trigger response (step 7).

Looking at further aspects of embodiments consistent with the invention, FIG. 3 is a block diagram of elements for carrying out various aspects of the invention as described above, such as in connection with FIGS. 1 and 2. In particular, any of the nodes described above (e.g., PICE, Server) can be provisioned with a controller 301 that includes circuitry configured to carry out any one or any combination of the various functions described above with respect to those elements. Such circuitry could, for example, be entirely hard- wired circuitry (e.g., one or more Application Specific Integrated Circuits - "ASICs"). Depicted in the exemplary embodiment of FIG. 3, however, is programmable circuitry, comprising a processor 303 coupled to one or more memory devices 305 (e.g., Random Access Memory, Magnetic Disc Drives, Optical Disk Drives, Read Only Memory, etc.) and to an interface 307 to other elements within the same or a different space. The interface 307 enables bidirectional communication with those other elements. The memory device(s) 305 store program means 309 (e.g., a set of processor instructions) configured to cause the processor 303 to control other node elements so as to carry out any of the aspects described above, such as but not limited to those described with reference to FIGS. 1 and 2. The memory device(s) 305 may also store data (not shown) representing various constant and variable parameters as may be needed by the processor 303 and/or as may be generated when carrying out its functions such as those specified by the program means 309. The memory device(s) 305 may store, for example, the common area database illustrated in FIG. 1.

The proposed solutions have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the disclosure, as shown by the below list of enumerated embodiments denoted items. 1. A packet inspection node 101, 203 that includes a common area 103 for storing service definitions wherein the stored service definitions are partitioned into separately accessible sub-libraries 107-1 to 107-N and a user space (105) for storing a link 111-1, 111-2, 111-M to a sub-library 107-1, 107-2, 107-N respectively comprising a relevant service definition.

2. The packet inspection node according to item 1 , wherein the link 111-1, 111-2, 111-M includes an indicator of a specific user for which the specific sub- library it is to be used. 3. The packet inspection node according to any one of item 1-2, wherein one or more version parameters, associated with respective ones of the service definitions, are stored in the common area.

4. The packet inspection node according to any one of item 1-3, wherein the packet inspection node is configured to operatively receive (1) a request from an application (201) indicating a requested service definition. 5. The packet inspection node according to item 4, wherein the packet inspection node is configured to operatively compare the requested service definition with service definitions stored in the common area 103 to determine whether the requested service definition is present in the common area.

6. The packet inspection node according to items 4 and 5, wherein the packet inspection node is configured to operatively forward (3) the request comprising the service definition only after determining that the service definition is not already stored in the common area 103.

7. The packet inspection node according to item 5wherein the packet inspection node is configured to operatively update the link in the user space to the sub-library in the common area 301 associated with the service definition if the requested service definition is already stored in the common area (301), then.

8. The packet inspection node according to any one of item 1-6, wherein one or more of the stored service definitions is associated with a time to live parameter, TTL_sd, that specifies how long the service definition is to be valid in the common space.

9. The packet inspection node according to item 8, comprising a timer associated with each of the one or more of the stored service definitions that is associated with the service definition time to live parameter, wherein the timer is programmed to timeout upon expiration of the service definition time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node is configured to send (3) a request for a service definition to replace the expired service definition. 10. The packet inspection node according to any one of item 1-9, wherein at least one of the stored service definitions is associated with a user time to live parameter, TTL_USer, that specifies how long the service definition is to be valid for a particular user.

11. The packet inspection node according to item 10, comprising a timer associated with each of the stored service definitions that is associated with the user time to live parameter, wherein the timer is programmed to timeout upon expiration of the user time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node is configured to remove, from the user space, a link to the service definition associated with the user time to live timeout.

12. A method performed in a packet inspection node 101, 203 which node 101, 203 includes a common area 103 for storing service definitions wherein the stored service definitions are partitioned into separately accessible sub-libraries 107-1-107-N and a user space 105 for storing a link 111-1, 111-2, 111-M to a sub-library 107-1, 107-2, 107-N respectively comprising the relevant service definition. The method comprises:

- receiving (1) a request from an application 201 indicating a requested service definition;

detecting (2) whether the requested service definition is stored in the common area 103;

forwarding (3) the request comprising the service definition after determining that the service definition is not stored in the common area 103, or update the link in the user space to the sub-library in the common area 301 associated with the service definition if the requested service definition is stored in the common area 301.

13. The method according to item 12, wherein the link 111-1, 111-2, 111 -M includes an indicator of a specific user for which it is to be used. 14. The method according to any one of item 12-13, wherein one or more version parameters, associated with respective ones of the service definitions, are stored in the common area.

15. The method according to any one of item 12-14, wherein one or more of the stored service definitions is associated with a time to live parameter, TTL_sd, that specifies how long the service definition is to be valid in the common space. 16. The method according to item 15, wherein the packet inspection node comprises a timer associated with each of the one or more of the stored service definitions that is associated with the service definition time to live parameter, wherein the timer is programmed to timeout upon expiration of the service definition time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node sends (3) a request for a service definition to replace the expired service definition.

17. The method according to any one of item 12-16, wherein at least one of the stored service definitions is associated with a user time to live parameter,

TTLuser, that specifies how long the service definition is to be valid for a particular user.

18. The method according to item 17, wherein the packet inspectioOn node comprises a timer associated with each of the stored service definitions that is associated with the user time to live parameter, wherein the timer is programmed to timeout upon expiration of the user time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node removes, from the user space, a link to the service definition associated with the user time to live timeout. The variously described embodiments provide a number of advantages over earlier technology. These include decreased load and memory utilization in the packet inspection classification engine by having a common space architecture for the service definitions. Another advantage is that the PICE/operator will be aware of when the user actually is actively using the application and is able to use this information to beneficially adapt the functionality of the PICE/operator.

Further, embodiments consistent with the invention provide a structured protocol to utilize the architecture in an efficient way.

Still further, embodiments consistent with the invention provide an easy and dynamically controlled way to activate and terminate rules utilizing the service definitions individually per user.

The invention has been described with reference to particular

embodiments. However, it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than those of the embodiment described above. Thus, the described embodiments are merely illustrative and should not be considered restrictive in any way. The scope of the invention is further illustrated by the following listed aspects, and all variations and equivalents which fall within the range of these aspects are intended to be embraced therein.

Claims

1. A packet inspection node (101, 203) that includes a common area (103) for storing service definitions wherein the stored service definitions are partitioned into separately accessible sub-libraries (107-1-107-N), and a user space (105) for storing a link (111-1, 111-2, 111-M) to a sub-library (107-1, 107-2, 107-N ) comprising a service definition.

2. The packet inspection node according to claim 1, wherein the link (111-1, 111-2, 111-M) includes an indicator of a specific user for which it is to be used.

3. The packet inspection node according to any one of claim 1-2, wherein one or more version parameters, associated with respective ones of the service definitions, are stored in the common area.

4. The packet inspection node according to any one of claim 1-3, wherein the packet inspection node is configured to operatively receive (1) a request from an application (201) indicating a requested service definition.

5. The packet inspection node according to claim 4, wherein the packet inspection node is configured to operatively compare the requested service definition with service definitions stored in the common area (103) to determine whether the requested service definition is present in the common area.

6. The packet inspection node according to claims 4 and 5, wherein the packet inspection node is configured to operatively forward (3) the request comprising the service definition only after determining that the service definition is not already stored in the common area (103).

7. The packet inspection node according to claim 5 wherein the packet inspection node is configured to operatively update the link in the user space to the sub-library in the common area (301) associated with the service definition if the requested service definition is already stored in the common area (301), then.

8. The packet inspection node according to any one of claim 1-6, wherein one or more of the stored service definitions is associated with a time to live parameter, TTL_sd, that specifies how long the service definition is to be valid in the common space.

9. The packet inspection node according to claim 8, comprising a timer associated with each of the one or more of the stored service definitions that is associated with the service definition time to live parameter, wherein the timer is programmed to timeout upon expiration of the service definition time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node is configured to send (3) a request for a service definition to replace the expired service definition.

10. The packet inspection node according to any one of claim 1-9, wherein at least one of the stored service definitions is associated with a user time to live parameter, TTL_USer, that specifies how long the service definition is to be valid for a particular user.

11. The packet inspection node according to claim 10, comprising a timer associated with each of the stored service definitions that is associated with the user time to live parameter, wherein the timer is programmed to timeout upon expiration of the user time to live time duration,

12. A method performed in a packet inspection node (101, 203) which node (101, 203) includes a common area (103) for storing service definitions wherein the stored service definitions are partitioned into separately accessible sub- libraries (107-1-107-N) and a user space (105) for storing a link (111-1, 111-2, 111-M) to a sub-library (107-1, 107-2, 107-N) comprising the service definition, the method comprises:

receiving (1) a request from an application (201) indicating a requested service definition;

- detecting (2) whether the requested service definition is stored in the common area (103);

forwarding (3) the request comprising the service definition after determining that the service definition is not stored in the common area (103), or update the link in the user space to the sub-library in the common area (301) associated with the service definition if the requested service definition is stored in the common area (301).

13. The method according to claim 12, wherein the link (111-1, 111-2, 111-M) includes an indicator of a specific user for which it is to be used.

14. The method according to any one of claim 12-13, wherein one or more version parameters, associated with respective ones of the service definitions, are stored in the common area.

15. The method according to any one of claim 12-14, wherein one or more of the stored service definitions is associated with a time to live parameter, TTL_sd, that specifies how long the service definition is to be valid in the common space.

16. The method according to claim 15, wherein the packet inspection node comprises a timer associated with each of the one or more of the stored service definitions that is associated with the service definition time to live parameter, wherein the timer is programmed to timeout upon expiration of the service definition time to live time duration,

17. The method according to any one of claim 12-16, wherein at least one of the stored service definitions is associated with a user time to live parameter, TTLuser, that specifies how long the service definition is to be valid for a particular user.

18. The method according to claim 17, wherein the packet inspectioOn node comprises a timer associated with each of the stored service definitions that is associated with the user time to live parameter, wherein the timer is programmed to timeout upon expiration of the user time to live time duration,

wherein in response to the timeout of the timer, the packet inspection node removes, from the user space, a link to the service definition associated with the user time to live timeout.