WO2004002062A1 - Procede et systeme de gestion des politiques - Google Patents

Procede et systeme de gestion des politiques Download PDF

Info

Publication number
WO2004002062A1
WO2004002062A1 PCT/EP2002/006975 EP0206975W WO2004002062A1 WO 2004002062 A1 WO2004002062 A1 WO 2004002062A1 EP 0206975 W EP0206975 W EP 0206975W WO 2004002062 A1 WO2004002062 A1 WO 2004002062A1
Authority
WO
WIPO (PCT)
Prior art keywords
policy
event
rule
rules
events
Prior art date
Application number
PCT/EP2002/006975
Other languages
English (en)
Inventor
Peter Braun
Ponnappan Appan
Yang Linghia
Radhakrishna Pillai
Original Assignee
Siemens Aktiengesellschaft
Laboratories For Information Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft, Laboratories For Information Technology filed Critical Siemens Aktiengesellschaft
Priority to PCT/EP2002/006975 priority Critical patent/WO2004002062A1/fr
Priority to AU2002316998A priority patent/AU2002316998A1/en
Publication of WO2004002062A1 publication Critical patent/WO2004002062A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Definitions

  • the invention relates to a policy management method for managing the distributed network elements of a computer network as well as to a corresponding system.
  • Policy Based Network Management is the industrial choice to manage the distributed network elements at a central station using human understandable languages.
  • a typical architecture of policy-managed network is depicted in Figure 1.
  • Policies encode the high-level goals and requirements of management.
  • Policy servers (identified as
  • PS- [1,2, 3] in Figure 1) which are also called Policy Decision Point (PDP) , translate the high-level policies into the lower-level device configuration information and then transport them to the network devices which are called Policy Enforcement Points (PEP) .
  • PDP Policy Decision Point
  • Each policy server serves one network administrative domain (identified as Network- [1, 2, 3] in Figure 1) .
  • a policy server can communicate with the adjacent domain policy servers for proper establishment of the device configuration requirements in the adjacent domains.
  • the policy rules are authored using an editor in the policy management console and stored in the directory server for immediate or later enforcement.
  • DMTF Distributed Management Task Force
  • the CIM describes management information and offers a framework for managing system elements across distributed
  • CIM is not bound to a particular implementation, and this flexibility allows different systems and applications to exchange and interpret management information.
  • An object-oriented information model for representing policy information is currently under joint development in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the DMTF.
  • CIM Common Information Model
  • the policy classes and associations defined in the model are sufficiently generic to allow them to represent policies related to anything.
  • US 5,889,953 describes a method and apparatus for determining an enforceable policy applicable to one or more network devices.
  • the method includes attaching one or more rule elements to one or more domain elements to create policies, the domain elements representing network devices and groups of network devices, and the rule elements defining actions, a method for determining whether a conflict exists between the polices, and a method for resolving the conflicts to produce one or more enforceable policies.
  • This patent groups network devices into domain elements.
  • Our invention groups network devices using classes, and class associations, which is a totally different concept.
  • WO 01/19031 proposes a policy-based network management (PBNM) architecture that can extend network capabilities for a network.
  • the method includes sending a first message from a policy enforcement point (PEP) to a policy decision point (PDP) in response to an external action, and sending a Java object in a second message from the PDP to the PEP in response to receiving the first message.
  • the Java object may be executed on the PEP to implement a policy.
  • Java is the enabling technology for this patent.
  • WO 00/78004 shows a unified policy management system for an organization including a central policy server and remotely situated policy enforcers.
  • a central database and policy enforcer databases storing policy settings are configured as LDAP databases adhering to a hierarchical object oriented structure. Changes in the policy settings made at the central policy server are automatically transferred to the policy enforcers for updating their respective databases.
  • Each policy enforcer collects and transmits health and status information in a predefined log format and transmits it to the policy server for efficient monitoring by the policy server.
  • the policy enforcement functionalities of the policy enforcers are effectively partitioned so as to be readily implemented in hardware.
  • policy server and policy enforcers may be configured for high availability by maintaining a backup unit in addition to a primary unit. The backup unit becomes active upon failure of the primary unit.
  • US 6,301,613 describes a method and apparatus which are provided for verifying policies that govern a policy-based system.
  • the method and apparatus may be implemented as a policy verifier that acts upon one or more policies.
  • Each policy comprises a condition and a consequent.
  • the policy verifier acquires configuration information about the system under management, thereby acquiring an understanding of the system.
  • the policy verifier determines whether all the policies can be satisfied by the system, and if not, reports problems or errors in the policies that cause the policies to be non-satisfiable.
  • the policy verifier determines whether all the policies are feasible for the system, and if not, reports problems or errors that cause the policies to be non-feasible.
  • the policy verifier also verifies that a configuration required by a particular policy consequent can be actually carried out by the managed system.
  • the policy verifier operates on network management policies, of a policy-based network management system. As a result, this document improves the accuracy and safety of policies prepared for a network that previously did not use policy-based management.
  • the managed network elements are modeled using object oriented approach. They are abstracted into a group of classes, called schema. The classes are related to each other by one of the following relationships: inheritance, associations or aggregation. The managed network elements are instance of the classes.
  • Event server is used for distributing events among components in the system. The events must be constructed using the classes and the classes' properties defined in the schema. Components that have something need r to notify other components construct events and forward the events to Event server. Event server is responsible for the delivering of events to the listening components according to their interests. Each component reacts on the event they received according to the event attributes.
  • Fig. 1 shows the network architecture of a general PBNM system
  • Fig. 2 a component diagram of an event driven distributed PBNM system
  • Fig. 3 a deployment diagram of an event driven distributed PBNM system
  • Fig. 4 a policy creation scenario which is adapted to a system according to Fig. 1 and 2,
  • Fig. 5 a flow diagram for policy creation and modification for PCC
  • Fig. 6 a simple network typology in an embodiment of the invented system
  • Fig. 7 a flow diagram showing the procedure of PAC for the case of lock with no weight
  • Fig. 8 the flow diagram for a procedure of PAC for the case of lock with weight.
  • Section 2 gives an overview on all the components that are part of the event based distributed policy network management system.
  • Section 3 illustrates a process that determines the related policy rules from the received events.
  • Section 4 presents an apparatus for checking the conflicts among policy rules and the applicability of the rule with the help of schema and network element information. It also shows a method for coordinating access of policy rules amongst a plurality of processes in a distributed system.
  • a Policy Rule Consistency checking mechanism fro checking of inconsistency and conflicts using the policy rules, the management information model and managed object instances, - Policy Repository Adapter that manages the read and write access to an IETF compliant policy repository including a Policy Consistency Checker and an efficient Policy Access Controller,
  • EDDPNMS manages network domains that comprise of one or more PEPs.
  • Figure 2 shows the component diagram of the EDDPNMS architecture.
  • the EDDPNMS comprises of the following components:
  • Event Server which is involved in the distribution of events between components. Each component can publish the event types that it is capable of generating and other components can subscribe to the events that they are interested in. Event server acts as a forwarder of events between the set of components acting in event generator role to the set of components acting as event consumers. Policy Repository Adapter - is used for the storage and retrieval of the policy rules from the policy repository.
  • Policy consistency checker checks for the consistency of a newly created policy rule with the existing rules.
  • Policy Access Controller manages the concurrent access to the policy repository by different clients.
  • PEP Manager - is in charge of managing one or more PEPs. It maintains and monitors the Status of each PEP. It maintains the list of capabilities of each PEP device and converts the device-independent requests for creation/deletion/modification of management objects to device-specific commands. It communicates with the PEPs using one of the standard management protocols like Simple Network Management Protocol (SNMP) or Common Open Policy Service (COPS) .
  • SNMP Simple Network Management Protocol
  • COPS Common Open Policy Service
  • Policy Decision Engine - is responsible for the evaluation and execution of the policy rules.
  • Policy Rule Cache stores the sets of policy rules that have recently been retrieved by PDEs to reduce the policy rules retrieval time.
  • a hierarchical distributed caching mechanism should be implemented; caches should be placed in Policy Repository Adapter (PRA) and Policy Decision Engines (PDE) .
  • PRA Policy Repository Adapter
  • PDE Policy Decision Engines
  • the goal of caching is to reduce the time taken for policy decisions.
  • the time taken to retrieve the policy rules from the rule repository contributes the most to the delay in the rule retrieval process.
  • the PDEs make decisions based on the related policy rules, the information model and states of the object instances. To avoid the frequently access of the rules in PRA, a local cache for policy rules is required.
  • Rule Scheduler responsible to trigger events to notify the installation or de-installation of the policy rules with time period condition.
  • the scheduler can be either a standalone component or part of the PDE and/or PRA.
  • the benefit of being a standalone component is that the scheduler can perform other tasks than rule scheduling, e.g. housekeeping task like backing up of database, used as an alarm clock by other components for periodic tasks.
  • this solution increases network traffic and it is not accurate enough for time critical tasks. If the scheduler is a subcomponent of PRA, this will reduce the network traffic, however, it loses the flexibility of serving for other purposes at the same time.
  • the scheduler is part of PDE, it can reduce network traffic and network delay. This approach is ideal for time critical policy rules.
  • Another aspect to improve the performance of the rule scheduler is to register the rules only when they are retrieved by an event. Instead of scheduling all the rules with time condition, only those rules that required by the system are scheduled. This can reduce the system load and improve scalability if there are a lot of policy rules with time period condition.
  • the event driven architecture makes the design extensible and flexible for adding policy based management of new domains. It provides a uniform interface for interfacing with PEP manager. It is also efficient since the policy rules are processed only at the reception of events.
  • Figure 3 shows a possible deployment of the proposed architecture. The components communicate with each other using Middleware.
  • the elements managed by the EDDPNMS are depicted using a schema.
  • the schema provides the actual model descriptions along with a set of classes with properties and associations that establish a well understood conceptual framework, within which it is possible to organize the available information about the managed environment.
  • One of the possible technologies to be used is a CIM Schema.
  • Classes can contain properties, which describe the data of the class, methods, which describe the behavior of the class, and constraints, which describe the rules that the instances of the class have to follow. They define the basic unit of management.
  • Each class is a template for a type of managed object; all instances of the type use the template.
  • Classes are related to each other by the following means: inheritance, associations or aggregation. Associations are represented using classes too.
  • Each policy rule consists of a conditions part and an actions part.
  • the conditions part specifies the conditions under which the actions have to be executed.
  • the conditions part is made up of one or more simple conditions combined by logical operators and each simple condition contains a variable name and a value related by a relational operator.
  • Evaluation of policy rules is triggered by internal or external events (e.g. from network devices or from internal time scheduling events which occur due to scheduling of policy rules) .
  • the type of the events can be classified into the following categories:
  • the object can be a new user, a new flow or a new network device, etc.
  • - Object Deletion Reports the deletion of an object within the management system.
  • the object can be a logout user, a terminated flow or a faulty network device, etc.
  • - State Changed Reports the changes of state of an object within the management system. It can be a change of priority of user, an enabling of policy rule, or a network device changed to standby state.
  • Attribute value changed Reports the changes in the attribute of an object.
  • An example is a network device with a change of current bandwidth usage.
  • Threshold crossed Reports the threshold crossing events happened in the objects in the management system. Some of the examples are congestion in a link or hard disk space available for the repository is below a safe level.
  • Each event has a field to defined which category it belongs to and a list of attributes which describe the event in more detail.
  • attributes which describe the event in more detail.
  • PEP startup event with the PEP ID and PEP device inventory information (one manifestation of this is a COPS- PR REQ message that is sent with the interface role combination information) . It belongs to object creation event.
  • PEP device operational status events (one example is a COPS RPT or SNMP TRAF message that is generated by the PEP for removal or insertion of a new device) It belongs to state changed event.
  • PEP access event by a particular user using a particular application (one example is an RSVP outsourcing message request while the bandwidth reservation for a new flow is done) . It belongs to object creation event.
  • PEP de-access event (one example is an RSVP outsourcing message request while the bandwidth reservation for a flow is torn down) It belongs to object deletion event.
  • the eventCategory specifies category the event belongs to.
  • the objectClassName states which class does the object instance belong to.
  • the oid is the object instance's ODD.
  • the attribute list contains a list of attributes that defines the event. For every attribute item, qpVariableNa e corresponds to the attributes of the classes in the schema which can be made unique by specifying the full path like:
  • the qpValue field contains the value that characterizes the attribute.
  • variable name for the policy rule condition should be one of the properties defined in the management element schema.
  • the event generators should attach a list of attributes that can help the PDE to make a decision.
  • the event generators should also send information on the role combination of the created rule and the conditions of the rule, so that PDE can decide whether to retrieve the rule. This can improve the efficiency of the PDE.
  • the event generators could also provide the policy rule domain as an attribute item in the AttributeList. This would speed up the policy rule retrieval process as it narrows down the scope of search space.
  • the disadvantage of this method is that it reduces the extensibility and maintainability of the system.
  • the event generators have to have the knowledge of how the policy rules are arranged in the rule repository and how the events are related to the type of policy rules, changes in the policy rule organization have to be reflected in the event generators as well.
  • Policy rules could be classified as shown below: - User or application related policies. These are to be applied when resource requests happen (e.g. a new traffic flow is initiated or terminated) .
  • Example events are 4 and 5 identified above.
  • PEP - Device policies. These are applied when a new PEP Starts up or is shutdown (example event is 1 identified above) .
  • time-based policies could be used, for example, for setting up a video-conferencing call during certain period of time.
  • the conditions of policy rules can specify a time period during which the policy rule is valid.
  • the types of policy rules can be easily extended by defining a new policy rule format using schema and adding the rules belonging to the new type into a new branch.
  • the PDE also need to be extended to understand how to evaluate and enforce the new type of rules.
  • the policy decision engine listens to significant events that are required for policy rule processing.
  • the event server can be combined with the PDE when there is only one PDE in the system, since the PDE is sole listener for the event server. This can reduce some network delay at the cost of reduced flexibility.
  • PDE does the following:
  • the relevance of the policy rules can be determined from the event's attribute list.
  • the event attribute variables in the attribute list should satisfy the conditions in the policy rules or the corresponding attributes of the policy rule.
  • the PEP manager can be Multi-threaded for parallel installation of the PRs to multiple PEPs.
  • One of the embodiment can be to provide a status report to the creator of the policy on the status of enforcement.
  • the performance of the event processing can be enhanced by mapping policy rules to event categories.
  • the components that generate events specified the corresponding eventCategory for the event and the set of attributes; the PDE can restrict the search scope only to the rules that has same eventCategory, and retrieves and enforces the matching rules accordingly.
  • the event handling process is very generic, it can handle any kind of events so long as the PDE knows how to enforce the retrieved rules.
  • a PR might not be immediately enforceable because of time constraints .
  • a PR might not be enforceable at a particular device because of the conflict between the capability of the device and the actions expressed in the policy rule. This kind of inconsistency are NOT analyzed by the policy consistency checker in the rule repository adapter but has to be done by the PEP manager before installing the configuration objects at the PEP.
  • Event 2 Device Startup Event with the link type information
  • Scheduler in the Repository Adapter will send out a notification event when the time period condition is satisfied, and another notification when the time period has expired.
  • Event 3 User-flow access event
  • Scheduler in the Repository Adapter will send out a notification event when the time period condition is satisfied, and another notification when the time period has expired.
  • the Policy Repository Adapter ( PRA ) is responsible for the management of the policy rules. Apart from the subcomponent that interacts with the directory or database, the PRA also consists of two sub-components: the Policy Consistency Checker ( PCC ) and the Policy Access Controller ( PAC ) .
  • PCC Policy Consistency Checker
  • PAC Policy Access Controller
  • the PCC is responsible for detecting the policy conflict and consistency violation.
  • the PAC is used to make sure that the policy rule can only be modified when nobody else is reading or modifying it, and can only be read when no one is trying to write on it.
  • Policy Editor sends the policy rule that the user is going to create to PRA by calling operation createPolicyRuleO .
  • PRA sends the policy rule to PCC for conflict checking by calling operation checkConflict () .
  • Caching at the PCC can speed up the consistency checking algorithm.
  • PCC calls the getPolicyO of the PRA to retrieve all policies stored in directory if its policy rule cache is empty.
  • PCC uses Operation findRelatedPolicies () to get all the related policies for the requesting rule.
  • PCC issues read locks for all the related policies by calling the lockRelatedPolicies () of the PAC.
  • the Policy Editor should provide a StatusMonitor object to the PRA. So that the PRA can release the all the Locks associate with the Policy Editor in the case of policy editor crash.
  • PCC checks for the conflicting policies and finds out the possible solutions using operation determinePossibleSolutions () In the case of policies that needs to be modified the policy consistency checker also provides a range of parameters that is consistent with the policy created. For rules that are not conflict with the requesting rule, the locks issued on them will be released. 7. It is also assumed that the user of the policy management has to approve the deletion/modification of existing policies. Therefore FCC returns the list of possible solutions to PRA. PRA returns the list to policy editor.
  • Policy editor displays the list of possible solution to the user. The user has to adopt one of the solutions before he/she is able to create the policy rule. Policy Editor calls the updatePolicyRules () of PRA to update all the policy rules modified in order to adopt the suggestion.
  • PRA calls checkConformity() of PCC to check for whether the client's solution conforms with the suggestion it made before.
  • the PRA updates all the policies accordingly using updatePolicyRules () and unlock all the locks associate with this creation request using unlockRelatedPolicies () of PAC.
  • PRA notifies PDE about the creation of the new policy and the modification and the deletion of policies, if any by using the policyRuleEventPush 0 Operation of PDE.
  • This section presents a Policy Rule Consistency checking mechanism for checking of consistency and conflicts using the existing policy rules, the management information model and managed object instances.
  • a policy rule When a policy rule is created or modified, it will first be checked by the general conflict checking process which checks the conflicts based on existing rules. If the rule is able to pass the first level of checking, it will be further checked using schema and the managed object instance information. The following two sections describe the two level of checking accordingly.
  • Figure 5 shows how the FCC checks for conflicts in the case of creation or modification of policies:
  • the FCC retrieves all the related rules. Rules that are related to the requesting rule
  • RR if they have the same, subset or superset of key attributes that are used in RR.
  • Role is a key attribute that scopes the rule applicability domain.
  • Rule 1 has the role “Edge + DiffServ”
  • rule 2 has the role “DiffServ”
  • rule 3 has the role "Edge +
  • the role of rule 2 is a subset of the role of rule 1.
  • the PDP obtains the information of managed elements and instantiates to object instances using the network information and the schema.
  • the PDP simulates the execution of the rule and its related rules, and checks whether the execution violates the constraints specified in the schema.
  • the example below illustrates how the algorithm works. To simplify it, only the checking of the bandwidth conflicts is shown.
  • the network information includes how the interfaces are interconnected, the egress BW of each interface, the role and the IP address. Take the example of CR in Figure 6. It has the following properties:
  • the maximum egress BW of interface ethO : 10.27.0.1 is 150 Mbps .
  • the maximum egress BW of interface ethl: 10.24.0. 1 is 150 Mbps .
  • the maximum egress BW of interface eth2 : 10.25.0.1 is 150 Mbps .
  • each interface object should have the following information:
  • ManagedDevice It consists the list of interfaces in the same device. It contains information about the device and the list of OIDs of the interfaces in the device.
  • COI The immediate interfaces in other device that receive packets from this interface to the destination, i.e. connected output interface (COI) . It contains the referred interface's OID and the list of the associated OIDs. It also has the following constraint: the sum of the diffserv bandwidth of the associated interfaces is greater than or equals to the bandwidth of referred the interface.
  • PDE have created an interface object for one of the interface in CR as following
  • every DiffServQueue in the DiffServQueueList must have a corresponding DiffServQueue in MyOID.
  • DiffServ BW + OID2. DiffServ BW > MyOID. DiffServ BW
  • every DiffServQueue in the DiffServQueueList must have a corresponding DiffServQueue in the DiffServQueueList.
  • DiffServQueue in MyOFD DiffServQueueList or MyOID. ReserveList, and the sum of the corresponding DiffServQueue bandwidth should be greater than or equal to the bandwidth of the corresponding queue in MyOID.
  • the PDE evaluates the new or modified rules.
  • this PDE is newly setup and all the policy rules are imported from somewhere else.
  • the following rules are arranged according to their priorities, that is the following rules will be executed in sequence.
  • Each managed object instance does the following when a policy rule is executed.
  • rule 5 a conflict will be detected as the total number of DiffServ BW in the Edge+Intserv interface will exceed the 70Mbps defined by rules with higher priority. The user will be informed.
  • the PDE finds that after all the rules are executed, the CR interfaces still have some reservation pending, all the related rules will be notified to the user and suggest that all the CR interface should have at least 35Mbps for EF queues, 15Mbps for AF queues and 30Mbps for BE queues. And three rules will be formed automatically.
  • the 23 and 24 are derived by the (maximum egress BW of the CII of core router interfaces - total number of BW should at least reserved) /the number of queues should be created.
  • Policy Access Controller is an apparatus for coordinating access of policy rules amongst a plurality of processes in a distributed system. It supports many read and one write locking mechanism. It also supports hierarchical locking, so that the clients of PAC have the flexibility to choose the granularity of the lock.
  • the client creates a key according to the granularity of the object it wants to lock, it then issues a lock request to the lock server.
  • the lock server Upon the reception of the request, the lock server checks whether there is an existing lock in the write lock list that has a key that is the same as the requesting key? Or subset of the requesting key? Or super set of the requesting key?
  • PolicyRuleName SampleRule 1
  • PolicyGroupName DiffServPolicy
  • qpDomainName QoSTestBedDomain
  • dc qospbn.
  • the request will be granted if the above listed keys are only belong to read locks, or no such keys exist at all.
  • Figure 8 shows the procedure of PAC for the lock with wait case.
  • the client creates a key according to the granularity of the object it want to lock, it then issue a lock request to the lock server.
  • the lock server Upon the reception of the request, the lock server checks whether there is an existing lock in the write lock list that has a key is: the same as the requesting key? Or subset of the requesting key? Or super set of the requesting key? 3. If such a write lock exists, put the key along with the callback object provided by the client into the waiting list, return the status to the client.
  • the lock request will be put into a waiting list, and the policy editor will be notified when the key has been released.
  • PolicyRuleName SampleRule 1
  • PolicyGroupName DiffServPolicy
  • qpDomainName QoSTestBedDomain
  • dc qospbn.
  • the request will be granted if the above listed keys are only belong to read locks, or no such keys exist at all.

Abstract

L'invention concerne un système de gestion des politiques, comprenant une première pluralité de générateurs d'événements, une seconde pluralité de consommateurs d'événements, au moins un serveur d'événements, et un mécanisme de communication reliant les générateurs d'événements aux consommateurs d'événements par l'intermédiaire du serveur d'événements et permettant la génération et la réception d'événements.
PCT/EP2002/006975 2002-06-24 2002-06-24 Procede et systeme de gestion des politiques WO2004002062A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/EP2002/006975 WO2004002062A1 (fr) 2002-06-24 2002-06-24 Procede et systeme de gestion des politiques
AU2002316998A AU2002316998A1 (en) 2002-06-24 2002-06-24 A policy management method and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2002/006975 WO2004002062A1 (fr) 2002-06-24 2002-06-24 Procede et systeme de gestion des politiques

Publications (1)

Publication Number Publication Date
WO2004002062A1 true WO2004002062A1 (fr) 2003-12-31

Family

ID=29797090

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2002/006975 WO2004002062A1 (fr) 2002-06-24 2002-06-24 Procede et systeme de gestion des politiques

Country Status (2)

Country Link
AU (1) AU2002316998A1 (fr)
WO (1) WO2004002062A1 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1592168A1 (fr) * 2004-04-27 2005-11-02 Microsoft Corporation Système et procédé permettant la verification de la conformité de règles dans des réseaux de communication
WO2006070054A1 (fr) 2004-12-31 2006-07-06 Nokia Corporation Procede et systeme destines a l'application d'une politique dans un systeme de communication
EP1913485A2 (fr) * 2005-07-29 2008-04-23 Mci, Llc. Moteur de strategies
US7526677B2 (en) 2005-10-31 2009-04-28 Microsoft Corporation Fragility handling
US7533407B2 (en) 2003-12-16 2009-05-12 Microsoft Corporation System and methods for providing network quarantine
WO2009060266A1 (fr) * 2007-11-06 2009-05-14 Telefonaktiebolaget L M Ericsson (Publ) Mécanisme et procédé de détection de collision dans le protocole d'accès rapide à l'annuaire (ldap)
WO2010076550A1 (fr) 2008-12-30 2010-07-08 British Telecommmunications Public Limited Company Contrôle d'accès
US7793096B2 (en) 2006-03-31 2010-09-07 Microsoft Corporation Network access protection
US7827545B2 (en) 2005-12-15 2010-11-02 Microsoft Corporation Dynamic remediation of a client computer seeking access to a network with a quarantine enforcement policy
US8127336B2 (en) 2007-03-01 2012-02-28 Bridgewater Systems Corp. Systems and methods for policy-based service management
US8132181B2 (en) 2006-11-30 2012-03-06 Dell Products L.P. Method, apparatus and media for indication management in an information model environment
FR3007865A1 (fr) * 2013-06-26 2015-01-02 France Telecom Systeme et procede de controle d'acces a un ensemble de ressources d'un systeme informatique en nuage
US20150120898A1 (en) * 2013-10-28 2015-04-30 Bae Systems Information And Electronic Systems Integration Inc. Policy managed system and method thereof
US9225684B2 (en) 2007-10-29 2015-12-29 Microsoft Technology Licensing, Llc Controlling network access
KR101782390B1 (ko) 2011-06-30 2017-10-23 에스케이텔레콤 주식회사 네트워크 정보 수집 시스템 및 그 방법
CN110908642A (zh) * 2018-09-14 2020-03-24 亿阳信通股份有限公司 一种策略生成执行方法和装置
CN112243003B (zh) * 2020-10-13 2023-04-11 中移（杭州）信息技术有限公司 访问控制方法、电子设备及存储介质
US20230112579A1 (en) * 2021-10-11 2023-04-13 Hewlett Packard Enterprise Development Lp Automatic policy engine selection

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1026867A2 (fr) * 1998-12-22 2000-08-09 Nortel Networks Corporation Système et procédé de support de politiques configurables pour des services d'annuaires en réseau
US20020050926A1 (en) * 1995-03-29 2002-05-02 Lundy Lewis Method and apparatus for distributed object filtering

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020050926A1 (en) * 1995-03-29 2002-05-02 Lundy Lewis Method and apparatus for distributed object filtering
EP1026867A2 (fr) * 1998-12-22 2000-08-09 Nortel Networks Corporation Système et procédé de support de politiques configurables pour des services d'annuaires en réseau

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
REARDON M: "MAKING POLICY IS AS EASY AS PLUG AND PLAY", DATA COMMUNICATIONS, MCGRAW HILL. NEW YORK, US, vol. 28, no. 10, July 1999 (1999-07-01), pages 29 - 30, XP000846704, ISSN: 0363-6399 *

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7533407B2 (en) 2003-12-16 2009-05-12 Microsoft Corporation System and methods for providing network quarantine
JP2005318615A (ja) * 2004-04-27 2005-11-10 Microsoft Corp ネットワーク検疫を提供するためのシステムおよび方法
EP1592168A1 (fr) * 2004-04-27 2005-11-02 Microsoft Corporation Système et procédé permettant la verification de la conformité de règles dans des réseaux de communication
EP1832141A4 (fr) * 2004-12-31 2011-11-23 Nokia Corp Procede et systeme destines a l'application d'une politique dans un systeme de communication
EP1832141A1 (fr) * 2004-12-31 2007-09-12 Nokia Corporation Procede et systeme destines a l'application d'une politique dans un systeme de communication
WO2006070054A1 (fr) 2004-12-31 2006-07-06 Nokia Corporation Procede et systeme destines a l'application d'une politique dans un systeme de communication
EP1913485A4 (fr) * 2005-07-29 2009-04-01 Mci Llc Moteur de strategies
EP1913485A2 (fr) * 2005-07-29 2008-04-23 Mci, Llc. Moteur de strategies
US8635324B2 (en) 2005-07-29 2014-01-21 Verizon Patent And Licensing Inc. Policy engine in an internet protocol multimedia subsystem
EP2448214A1 (fr) * 2005-07-29 2012-05-02 Mci, Llc. Moteur de stratégies
US7975037B2 (en) 2005-07-29 2011-07-05 Verizon Patent And Licensing Inc. Policy engine in an Internet Protocol multimedia subsystem
US7526677B2 (en) 2005-10-31 2009-04-28 Microsoft Corporation Fragility handling
US7827545B2 (en) 2005-12-15 2010-11-02 Microsoft Corporation Dynamic remediation of a client computer seeking access to a network with a quarantine enforcement policy
US7793096B2 (en) 2006-03-31 2010-09-07 Microsoft Corporation Network access protection
US8132181B2 (en) 2006-11-30 2012-03-06 Dell Products L.P. Method, apparatus and media for indication management in an information model environment
US8127336B2 (en) 2007-03-01 2012-02-28 Bridgewater Systems Corp. Systems and methods for policy-based service management
US9225684B2 (en) 2007-10-29 2015-12-29 Microsoft Technology Licensing, Llc Controlling network access
WO2009060266A1 (fr) * 2007-11-06 2009-05-14 Telefonaktiebolaget L M Ericsson (Publ) Mécanisme et procédé de détection de collision dans le protocole d'accès rapide à l'annuaire (ldap)
EP2207126A1 (fr) * 2008-12-30 2010-07-14 BRITISH TELECOMMUNICATIONS public limited company Contrôle d'accès
US8533782B2 (en) 2008-12-30 2013-09-10 British Telecommunications Public Limited Company Access control
WO2010076550A1 (fr) 2008-12-30 2010-07-08 British Telecommmunications Public Limited Company Contrôle d'accès
KR101782390B1 (ko) 2011-06-30 2017-10-23 에스케이텔레콤 주식회사 네트워크 정보 수집 시스템 및 그 방법
FR3007865A1 (fr) * 2013-06-26 2015-01-02 France Telecom Systeme et procede de controle d'acces a un ensemble de ressources d'un systeme informatique en nuage
US20150120898A1 (en) * 2013-10-28 2015-04-30 Bae Systems Information And Electronic Systems Integration Inc. Policy managed system and method thereof
US10057356B2 (en) * 2013-10-28 2018-08-21 Bae Systems Information And Electronic Systems Integration Inc. Policy managed system and method thereof
CN110908642A (zh) * 2018-09-14 2020-03-24 亿阳信通股份有限公司 一种策略生成执行方法和装置
CN110908642B (zh) * 2018-09-14 2024-04-05 亿阳信通股份有限公司 一种策略生成执行方法和装置
CN112243003B (zh) * 2020-10-13 2023-04-11 中移（杭州）信息技术有限公司 访问控制方法、电子设备及存储介质
US20230112579A1 (en) * 2021-10-11 2023-04-13 Hewlett Packard Enterprise Development Lp Automatic policy engine selection

Also Published As

Publication number Publication date
AU2002316998A8 (en) 2004-01-06
AU2002316998A1 (en) 2004-01-06

Similar Documents

Publication Publication Date Title
US9386040B2 (en) Policy-based service management system
WO2004002062A1 (fr) Procede et systeme de gestion des politiques
US7752296B2 (en) Device management system and device management command scheduling method thereof
Wang et al. Integrated quality of service (QoS) management in service-oriented enterprise architectures
US6718380B1 (en) Method and apparatus for storing policies for policy-based management of network quality of service
US8593968B2 (en) Quality of service management for message flows across multiple middleware environments
Bauer et al. IoT reference architecture
US8046464B2 (en) Quality of service resource management apparatus and method for middleware services
US20150350053A1 (en) Method and system for policy-based control in a distributed network
EP1026867A2 (fr) Système et procédé de support de politiques configurables pour des services d'annuaires en réseau
EP1766866B1 (fr) Programmation de commande de gestion de dispositif de réseau
CN112789832A (zh) 动态切片优先级处理
US8095959B2 (en) Method and system for integrating policies across systems
JP2005506016A (ja) ポリシーに基づくシステム管理
Kryftis et al. Policy-Based Management for Federation of Virtualized Infrastructures
Follows et al. Application driven networking: Concepts and architecture for policy-based systems
Omari et al. Policies in snmpv3-based management
Shen et al. Policy control and traffic aggregation for M2M services in mobile networks
Huang et al. QoS Policy Framework and its implementation
Magaña et al. Autonomic management architecture for flexible grid services deployment based on policies
Chen et al. Obtaining resource controllability in service cooperation environments
Ok et al. The design of service management system based on policy-based network management
Zebiane et al. Active network and policy based management
Kang et al. A Multilevel Policy-Based Network Management System for Differentiated Services Network
Meyler Distributed Coordination of Policy Execution across Autonomous Elements

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP