WO2007096591A2 - Procédé de configuration de dispositifs dans un réseau de télécommunications - Google Patents

Procédé de configuration de dispositifs dans un réseau de télécommunications Download PDF

Info

Publication number
WO2007096591A2
WO2007096591A2 PCT/GB2007/000565 GB2007000565W WO2007096591A2 WO 2007096591 A2 WO2007096591 A2 WO 2007096591A2 GB 2007000565 W GB2007000565 W GB 2007000565W WO 2007096591 A2 WO2007096591 A2 WO 2007096591A2
Authority
WO
WIPO (PCT)
Prior art keywords
configuration
service
script
devices
instructions
Prior art date
Application number
PCT/GB2007/000565
Other languages
English (en)
Other versions
WO2007096591A3 (fr
Inventor
Luca De Matteis
Mark Robert Gisbon
Adan K. Pope
Original Assignee
Cramer Systems Limited
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
Priority claimed from GB0603360A external-priority patent/GB2435362B/en
Application filed by Cramer Systems Limited filed Critical Cramer Systems Limited
Publication of WO2007096591A2 publication Critical patent/WO2007096591A2/fr
Publication of WO2007096591A3 publication Critical patent/WO2007096591A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13109—Initializing, personal profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management

Definitions

  • the present invention relates to methods of configuring network devices in telecommunications networks to provide services.
  • telecommunications networks grow in complexity and the range of telecommunications services expands, the process of provisioning services - configuring the network to provide new services - is also becoming ever more complex.
  • Existing approaches to service provisioning can be inflexible and inefficient, which can have a negative impact on a service operator's ability to provide a wide range of services, and to quickly implement new services.
  • the definition of provisioning processes for new network services can be cumbersome and often requires detailed knowledge of network structures and device configuration. Service provisioning itself can, for complex services, involve many network configuration steps, which often results in slow turnaround of provisioning requests.
  • a method of configuring a telecommunications system to provide a service involving a plurality of devices comprising: receiving a configuration script specifying a sequence of configuration instructions for configuring at least two of the plurality of devices to provide the service; and concurrently executing an instance of the configuration script for each of the at least two devices to configure the at least two devices to provide the service.
  • the telecommunications system typically includes one or more telecommunications networks.
  • the term 'telecommunications network' or 'telecommunications system' preferably refers to a network or system of interconnected devices (and possibly associated software) which provides telecommunications services.
  • other types of services may additionally be provided by or using the telecommunications network or system, for example data processing, storage, and retrieval services (e.g. application services). Examples of such services include a mailbox, web space, an interactive travel booking system, a multimedia content delivery system or an online game.
  • the invention may also be applied to any other suitable type of communications system (for example a local area network) or information processing system comprising distributed interconnected devices which can be configured to provide communication functionality or other services.
  • configuration script preferably refers to a collection of configuration instructions.
  • a script may define one or more sequences of configuration instructions. Sequences of configuration instructions may specify configuration operations in the order in which they are to be performed; however, control structures may also be provided to vary the execution order and execution options. Alternatively, instruction sequences may be executed in some other order, for example determined by efficiency considerations.
  • a script may be in human-readable form, for example using a scripting language using defined terms and/or keywords, or using a mark-up language such as XML. Alternatively, a script may be in a form which is not easily human- readable, for example in the form of byte code or some other machine- readable encoding.
  • concurrative execution preferably includes both true parallel processing (for example on a multi-threaded or multi-core processor, multiprocessor computer, or on multiple connected computers) and virtual parallel processing or multitasking, as performed, for example, by many multitasking operating systems, for example using time-sliced (interleaved) execution and context switching. Combinations of the two approaches may also be used to achieve concurrent execution.
  • the term "service” preferably refers to a telecommunications function or combination of telecommunications functions which may be provided or made available to a user (for example, an Internet access service, a video telephony service or a Virtual Private Network service).
  • the script specifies one or more synchronization points for synchronizing execution of multiple instances of the script, the method comprising synchronizing the concurrent instances of the script at the synchronization point or points. In this way, multiple devices can be configured concurrently while still maintaining sequential control, so enabling a good balance between speed and reliability to be achieved.
  • the script preferably specifies a synchronization point dividing the instruction sequence into a first instruction block and a second instruction block, each instruction block comprising zero or more instructions, the method comprising: executing, in a first executing instance of the script, the first instruction block; and executing, in the first executing instance of the script, the second instruction block only after a second executing instance of the script has executed the first instruction block, to thereby synchronize execution of the first and second script instances at the synchronization point.
  • This can allow configuration operations on different devices to be performed in a desired sequence where necessary.
  • the method preferably comprises executing, in the first executing instance of the script, the second instruction block only after all other executing instances of the script have executed the first instruction block, to thereby synchronize execution of all executing script instances at the synchronization point.
  • a simple synchronization mechanism can be provided which does not limit all instructions to be strictly sequenced but can allow concurrent processing where possible and sequencing only where necessary. This can be achieved without the need for the script author to code complex synchronisation procedures manually.
  • the script may specify multiple synchronization points, in which case the method preferably comprises synchronizing execution of the script instances at each synchronization point.
  • the instruction sequence may comprise one or more synchronization instructions specifying one or more synchronisation points at which multiple concurrent script instances are to be synchronised.
  • the synchronization points may be specified in any other suitable way, for example using an index, pointer, instruction reference, marker or keyword.
  • the at least two devices may each be associated with a device type, in which case the script may specify a first sequence of configuration instructions associated with a first device type and a second sequence of configuration instructions associated with a second device type. Executing an instance of the script for a given device may then comprise selecting one of the first and second instruction sequences in dependence on the device type of the given device, and executing the selected instruction sequence.
  • Devices may be associated with types in dependence on the roles which they perform within a service.
  • executing an instance of the script for a given device may comprise selecting one of the first and second instruction sequences in dependence on a role associated with the given device.
  • Other type classifications may alternatively or additionally be used, for example classifications by device manufacturer, device class, software version, hardware version or model. Different type classifications may also be combined. In certain embodiments described in more detail below, a role-based approach is used.
  • Each of the first and second instruction sequences may comprise one or more corresponding synchronization points, the method comprising synchronizing a first instance of the script for which the first instruction sequence is being executed with a second instance of the script for which the second instruction sequence is being executed using the specified corresponding synchronization point or points.
  • a first instruction sequence may comprise one or more synchronisation points
  • a second instruction sequence may comprise one or more synchronisation points each corresponding to one of the one or more synchronisation points of the first instruction sequence.
  • Synchronization points in different instruction sequences may be identified as corresponding by way of matching synchronisation point identifiers (such as numbers or labels), or simply by the order of synchronisation points (e.g., the third specified synchronisation point in one instruction sequence may be considered to correspond to the third specified synchronisation point in another instruction sequence).
  • the method may further comprise, for a sequence of configuration instructions or corresponding sequences of configuration instructions not having associated synchronisation points or corresponding synchronisation points, executing the instruction sequence or corresponding instruction sequences in multiple concurrent instances of the configuration script independently of each other.
  • independent execution preferably means asynchronous execution, i.e. execution of instances without synchronisation (in time).
  • each instance preferably executes at its own speed.
  • the method further comprises storing a plurality of configuration scripts, each defining configuration operations for a respective service type, receiving a configuration request specifying a service to be provided, selecting one of the plurality of stored configuration scripts in dependence on the specified service, and executing the selected configuration script to configure the network to provide the specified service.
  • This can enable efficient provisioning of services.
  • the configuration request may specify one or more devices to be used to provide the service, and the method may comprise executing an instance of the selected configuration script for each device specified in the configuration request to configure the device.
  • the script is preferably defined independently of the actual devices used to provision a given service (though the script may be specific to a class of devices and/or a service type or class), so that the same script can be re-used, preferably without requiring modification, to provision multiple services of the same service type (and using devices of the same or similar type).
  • This can greatly simplify provisioning of new services, and can allow the provisioning process to be largely automated.
  • a configuration script acts as a device- independent template for specifying a configuration control process which includes the configuration operations needed to provision services of a given service type.
  • configuration scripts are therefore also referred to as Control Templates.
  • the configuration request preferably specifies a device type associated with a device, the method comprising selecting one of a plurality of instruction sequences specified by the configuration script in dependence on the specified device type, and executing the selected instruction sequence in the script instance for the device.
  • the device type may be inferred or otherwise derived.
  • the method preferably comprises creating a separate processing context for each executing script instance, and executing each script instance within the respective processing context. This can enable efficient and reliable concurrent execution. Multiple concurrent script instances may be executed as multiple concurrent threads, tasks or processes in a multi-threading, multitasking or multi-processing system, and/or may be executed by a virtual machine.
  • the method preferably comprises signalling completion of the configuration script upon completion of all executing script instances.
  • the method set out above can allow for efficient provisioning of new services using configuration scripts. Alternatively or additionally, the method may be applied to the removal of existing services from the network.
  • the method may accordingly further comprise: receiving a configuration request specifying a service and an action indicator specifying whether a service is to be added or removed; retrieving a configuration script in dependence on the service type of the specified service, the configuration script specifying a first set of configuration instructions for configuring the network to provide a new service of the service type and a second set of configuration instructions for configuring the network to no longer provide a service of the specified type which is currently being provided; selecting one of the first and second sets of instructions in dependence on the action indicator; and executing the selected set of instructions to either add a new service or remove an existing service of the specified type.
  • This can allow configuration operations for adding a service and operations for removing a service to be specified in the same script. This can improve user convenience and efficiency.
  • the different sets of configuration instructions may each comprise synchronisation points and/or multiple instruction sequences for different devices/device types as set out above.
  • the method may alternatively or additionally comprise: receiving a configuration request specifying a service and an action indicator specifying a configuration action relating to the service; retrieving a configuration script in dependence on the service type of the specified service, the configuration script specifying at least a first set of configuration instructions for performing a first configuration action and a second set of configuration instructions for performing a second configuration action for a service of that type; selecting one of the first and second sets of instructions in dependence on the action indicator; and executing the selected set of instructions to perform the specified configuration action.
  • a method of configuring services in a telecommunications system comprising: receiving a configuration request specifying a service and an action indicator specifying a configuration action relating to the service; retrieving a configuration script in dependence on the service type of the specified service, the configuration script specifying at least a first set of configuration instructions for performing a first configuration action and a second set of configuration instructions for performing a second configuration action for a service of that type; selecting one of the first and second sets of instructions in dependence on the action indicator; and executing the selected set of instructions to perform the specified configuration action.
  • a more flexible configuration method can be provided.
  • the first, second and specified configuration actions are preferably selected from a group comprising: addition of a service, modification of an existing service, and removal of an existing service.
  • the method of any of the above aspects comprises storing information defining a plurality of configuration operations, the configuration script comprising one or more configuration instructions each for invoking one of the stored configuration operations.
  • Configuration operations may, for example, define basic configuration actions, each relating to a given type of device or networking equipment.
  • the configuration script can then specify a configuration process in terms of the stored configuration operations. In this way, the configuration script can be expressed independently of low-level device details.
  • the stored operations can then be modified in view of the change in equipment (for example, if the new equipment uses a different command set to achieve the required configuration actions), without requiring every configuration script referencing those operations to be changed.
  • the stored information may define: at least two device-specific implementations of the configuration operation, each implementing the configuration operation for a different device type or model; and a device-independent interface usable for invoking each of the device-specific implementations of the configuration operation. This can allow configuration scripts to be expressed in a more device-independent manner.
  • the interface may, for example, specify one or more configuration parameters required by the device-specific implementations of the configuration operation and/or a name or label for the configuration operation.
  • the invention provides a method of configuring devices in a telecommunications network for a service, comprising storing information defining a plurality of configuration operations, the information defining for at least one of the configuration operations: at least two device-specific implementations of the configuration operation, each implementing the configuration operation for a different device type or model; and a device- independent interface usable for invoking each of the device-specific implementations of the configuration operation; the method further comprising executing a configuration script comprising one or more configuration instructions for invoking one or more of the stored configuration operations by way of the defined device-independent interfaces.
  • the configuration script may comprise one or more references to configuration operations; and executing the configuration script for a given device may comprise: identifying a reference to a configuration operation; selecting a device-specific implementation of the configuration operation in dependence on the given device; and executing the selected device-specific implementation of the configuration operation.
  • a configuration script can be coded without knowledge of the devices ultimately used.
  • the appropriate device-specific implementations of operations can be selected at the time of execution, allowing changes to be made to devices and to the device-specific implementations of operations without affecting configuration scripts already in use.
  • the configuration script may reference one or more configuration parameters, the method comprising receiving parameter values for the configuration parameters, and executing the configuration script using the received parameter values.
  • the method may comprise: receiving, for a parameter referenced in the configuration script, first and second parameter values; executing a first instance of the configuration script for a first device using the first parameter value; and executing a second instance of the configuration script for a second device using the second parameter value.
  • a method of provisioning a service in a telecommunications network comprising: receiving a configuration script comprising configuration instructions for configuring devices of the network to provide the service, the script including a first sequence of configuration instructions associated with a first device type and a second sequence of configuration instructions associated with a second device type; receiving information specifying a device to be used in providing the service, the device being associated with a device type; and selecting one of the first and second instruction sequences in dependence on the device type of the device, and executing the selected instruction sequence to configure the device.
  • the information may specify a plurality of devices to be used in providing the service, the method comprising performing the selecting and executing steps for at least two and preferably each of the specified devices.
  • This method may further comprise any of the features or steps of the previously described method.
  • a method of performing a configuration action in a telecommunications system for a service involving a plurality of devices comprising: receiving a configuration script specifying a sequence of configuration instructions for performing the configuration action for at least two of the plurality of devices; and concurrently executing an instance of the configuration script for each of the at least two devices to configure the at least two devices in accordance with the configuration action.
  • the configuration action may be one of: addition of a service, modification of an existing service, and removal of an existing service.
  • the configuration script may specify multiple sequences of configuration instructions for performing multiple different configuration actions.
  • the invention provides a computer program or computer program product for configuring a telecommunications system to provide a service involving a plurality of devices, comprising software code adapted, when executed on a data processing apparatus, to perform the steps of: receiving a configuration script specifying a sequence of configuration instructions for configuring at least two of the plurality of devices to provide the service; and concurrently executing an instance of the configuration script for each of the at least two devices to configure the at least two devices to provide the service.
  • the software code is preferably further adapted to perform a method as set out above.
  • the invention provides a network management system or service provisioning system for configuring a telecommunications network to provide a service involving a plurality of devices, comprising: means for receiving a configuration script specifying a sequence of configuration instructions for configuring at least two of the plurality of devices to provide the service; and means for concurrently executing an instance of the configuration script for each of the at least two devices to configure the at least two devices to provide the service.
  • the system preferably further comprises means for performing a method as set out above.
  • a configuration script for configuring a telecommunications network for a service the script specifying: a sequence of configuration instructions for configuring devices of the telecommunications network for the service; and one or more synchronisation points for synchronising multiple concurrent instances of the script.
  • the script may specify two or more sequences of configuration instructions, each instruction sequence being associated with a device type and comprising configuration instructions for configuring a device of that type for the service. At least two sequences of configuration instructions may each specify one or more corresponding synchronisation points for synchronising multiple concurrent instances of the script for which different ones of the at least two sequences of configuration instructions are being executed.
  • a synchronisation point may be specified by way of a synchronisation instruction.
  • an instruction sequence may be divided into two or more sub-sequences, the boundary or boundaries between sub-sequences forming one or more synchronisation points at which multiple concurrent instances of the script are to be synchronised. In this way, a sequence of configuration instructions can be divided into separate configuration steps, and multiple concurrent instances of the script can be synchronised on a step-by-step basis.
  • the configuration script may comprise multiple sections, each section comprising configuration instructions for performing a different configuration action, the configuration action preferably being one of: addition of a service, modification of an existing service, and removal of an existing service.
  • the configuration script may be encoded as an XML document, and may include one or more script portions expressed in a scripting language, preferably JavaScript.
  • the invention also provides an XML schema or XML document type definition (DTD) specifying an XML document format for a configuration script as described herein or for a configuration operation as described herein.
  • DTD XML document type definition
  • the invention provides a configuration controller (also referred to as an activation controller) for configuring network devices in a telecommunications network for services; the configuration controller being adapted to execute respective instruction sequences for each of a plurality of devices involved in a service; and wherein the configuration controller is adapted to provide a synchronised operating mode in which respective instruction sequences for at least two devices are executed in a synchronous manner.
  • the respective instruction sequences may be respective separate executing instances of the same set of instructions or may be executing instances of different sets of instructions. Thus, either the same or different sets of instructions may be executed for the at least two devices.
  • Execution in a synchronous manner preferably involves synchronising the executing instruction sequences at least at one point, so that a first of the instruction sequences continues execution past the synchronisation point only after the second instruction sequence has reached the same or a corresponding synchronisation point.
  • the controller is preferably adapted to synchronise execution of the respective instruction sequences for the at least two devices at one or more defined synchronisation points.
  • the instruction sequences may be divided into two or more defined steps, the controller being adapted to synchronise execution according to the defined steps.
  • the controller further provides an asynchronous operating mode in which instructions in the respective instruction sequences are executed asynchronously.
  • the controller is adapted to perform respective instructions for the at least two devices asynchronously between the defined (corresponding) synchronisation points or within the defined steps.
  • the configuration controller is preferably adapted to provide a symmetrical operating mode in which the same instructions are performed for the at least two devices.
  • the controller may provide an asymmetrical operating mode in which different instructions are performed for the at least two devices. This can provide greater flexibility in implementing complex configuration processes.
  • the synchronous/asynchronous modes may be combined with the symmetrical/asymmetrical modes to provide greater flexibility.
  • the configuration controller is preferably adapted to operate in one or more of, and preferably in each of: an asynchronous symmetrical operating mode, a synchronous symmetrical operating mode, an asynchronous asymmetrical operating mode, and a synchronous asymmetrical operating mode.
  • the configuration controller may be adapted to perform a method as set out above, and/or to process or execute configuration scripts as set out above.
  • the invention also provides a network management system comprising: a configuration controller as set out above; means for receiving a configuration request relating to a service; and means for invoking the configuration controller to configure a service in accordance with the request.
  • the configuration controller may be implemented as a software application, for example as a Java application executing on a Java virtual machine, and/or may comprise or be in the form of a programmed computer.
  • the invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
  • the invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
  • Figure 1 shows a service management system for a telecommunications network in overview
  • Figure 2 illustrates a Control Template thread control structure
  • Figure 3 illustrates asynchronous Control Template operation
  • FIG. 4 illustrates lock-stepped Control Template operation
  • Figure 5 illustrates basic asymmetric operation
  • Figure 6 illustrates asymmetric lock-stepped operation
  • FIG. 7 illustrates a symmetric service example (VRF)
  • Figure 1 illustrates a service management system for a telecommunications network in overview.
  • the system comprises a service inventory 12 storing information on services provided to users of network 20. Additionally, the inventory 12 preferably stores information on network resources of the network 20 in the form of a network model. Alternatively, the network model may be stored in a separate resource inventory.
  • the inventory or inventories are typically stored in a database.
  • a service management application 10 interacts with the service inventory 12 and allows network services to be added and removed (for example, under control of an operator).
  • an operator may use the service management application 10 to set up a new service for a user of the network (such as a new Internet access service).
  • network resources are identified in the inventory 12 for use in providing the new service, and the inventory is updated to reflect the new service.
  • an activation request is generated, specifying the identified network resources (in particular network devices involved in providing the new service) and any set-up parameters.
  • the activation request is passed to an activation controller 14, which is responsible for implementing the changes in the network, in particular by configuring the devices specified in the activation request to provide the new service.
  • the activation controller maintains a queue of activation requests and may process these in order of receipt or in some other order, for example based on efficiency considerations.
  • Each activation request may specify the addition, modification or removal of a service from the network, or the cancellation of a previously queued (but not yet implemented) activation request.
  • the activation controller 14 carries out the configuration operations necessary to configure the specified devices to provide the new service.
  • Agent Templates define the basic configuration operations available for configuring devices. Typically, a given Agent Template is associated with a particular device type and performs a specific configuration operation on a device of that type.
  • Control Templates are configuration scripts defining sequences of steps needed to configure complex services using the basic configuration operations defined in the Agent Templates.
  • Control Template is defined for each service type that is to be provisioned in the network.
  • Control Templates comprise sequences of configuration instructions. These most commonly take the form of Agent Template invocations, but other types of commands (including control structures such as "if/then/else") may also be used.
  • the activation request specifies the service to be provisioned and the devices to be used in provisioning the service.
  • the activation controller 14 identifies the Control Template associated with the given service and executes, for each device involved in the service, the configuration instructions specified by the template, in particular by invoking the Agent Templates specified in the Control Template.
  • the configuration instructions for the devices are generally executed in parallel.
  • the activation controller 14 concurrently executes a separate instance of the Control Template for each device being configured, creating separate processing contexts for each instance of the control template, and hence for each device.
  • These instances of the Control Template (CT) are referred to herein as CT Device Instances.
  • Processing contexts may, for example, be in the form of processes, tasks or threads in a parallel processing, multi-tasking or multi-threaded operating system.
  • the activation controller may provide a virtual machine (or similar control arrangement) and control execution of the templates within the virtual machine.
  • Agent Templates results in specific configuration instructions being transmitted to the relevant devices in the network 20, thereby configuring the devices to provide the service.
  • Configuring a device to provide a service is also referred to as activating the device for the service.
  • the activation controller preferably maintains a log of the configuration operations performed, and any error information generated. Preferably, a separate log is provided for each Control Template and/or for each activation request.
  • the controller 14 itself may, for example, be a standalone computer or a process executing on a network management server. Activation Request
  • the activation request transmitted to the activation controller 14 may specify the following information:
  • control template(s) may also be selected automatically based on the service type
  • Service parameters for example specifying service level or quality of service (QoS), service quantity e.g. bandwidth, or content selection (where e.g. a content delivery service is being provided) • Any other configuration parameters to be used in configuring devices (e.g. port settings).
  • QoS quality of service
  • content selection where e.g. a content delivery service is being provided
  • DII design invariant information
  • DVI design variant information
  • the activation controller executes the multiple CT Device Instances of the Control Template for the relevant devices using the parameter values associated with each device.
  • an Activation Request may also be used to modify or remove an existing service.
  • the Activation Request thus typically also specifies the activation action to be performed (e.g. add service, modify service, remove service).
  • the Activation Request is preferably encoded as an XML document.
  • Control Templates provide the logical control flow that governs the network configuration process.
  • a Control Template specifies a sequence of Agent Templates (AT) which, when invoked, configure the network in a sequential manner.
  • AT Agent Templates
  • the Agent Templates are invoked in the sequence specified by the Control Template.
  • the Control Templates use a scripting language that supports logical and control flow constructs to provide a sophisticated scripted control flow mechanism as described throughout this section.
  • Control Template may also invoke other Control Templates.
  • Control Templates can be modularised, and more powerful and flexible control structures can be used (such as recursion).
  • Control Template itself may pass these parameters to the Agent Templates being invoked as appropriate.
  • the Control Template may also use the device identifiers that are received in the Activation Request to query the inventory 12 for further information that may not be passed with the Activation Request, such as information on device software versions.
  • This section introduces the support infrastructure that the activation controller 14 provides for the processing of a Control Template. This infrastructure is used from the point that the controller begins processing an Activation Request to the point that it is completed. This process is outlined in
  • CT Control Template
  • Activation Request A new processing context is created on the controller within which all the processing of the Activation Request takes place. This processing context is referred to as the Activation Request
  • the Activation Request Instance is in effect the container for the processing of the Control Template invoked by the Activation Request and represents a single instance of the invocation of the Control Template.
  • Activation Requests may also be processed in parallel, in which case an Activation Request Instance is created for each Activation
  • each Activation Request Instance is distinguished using the Activation ID of the Activation Request that caused it to be created.
  • each Activation Request Instance a separate processing context is also created for each device that is being configured. This is illustrated in step (2).
  • This processing context for a device is referred to as a Control Template (CT) Device Instance.
  • CT Control Template
  • Each CT Device Instance controls the invocation of the Agent Templates specified in the Control Template on the device that the CT Device Instance is responsible for.
  • the Activation Request Instance is responsible for coordinating the separate CT Device Instances.
  • Each CT Device Instance in operation in the system is identified by the Activation ID of its parent Activation Request Instance and the Device ID of the device that it is activating. This pair is used by the system in each log entry for the operations that are performed within a CT Device Instance.
  • Controller may respond that the Activation Request has been processed; step
  • Every Activation Request Instance will have an entry in the inventory and will also have a specific log file. Where multiple Activation Requests are executed in parallel, conflict could occur between the corresponding Control Templates if these attempt to access the same device in the network, potentially resulting in incorrect configuration of devices, invalid configuration states or race conditions.
  • the Activation Controller therefore preferably only allows one CT Device Instance to execute for any given device at any time. Thus, if a CT Device Instance is created for a given device which is already associated with an executing CT Device Instance (typically in a separate Activation Request Instance), then the Activation Controller suspends execution of the new CT Device Instance until the earlier one has terminated. Control Template operational requirements
  • An Activation Request Instance is responsible for controlling the overall flow of activation for all the network elements (devices) included in the Activation Request that triggers its invocation. This process of control is not the same in all cases. For certain services and connections, the same basic operations will need to be performed at the same time. For others, there may need to be a certain order in which the operations are performed on the devices in the service.
  • Asynchronous operation permits each CT Device Instance to complete at its own speed - the CT Device Instance can invoke the next Agent
  • the Activation Request Instance simply waits for each CT Device Instance to complete before sending a success response for the Activation Request.
  • Asynchronous mode is used in cases where the same operations need to be performed on each device (though possibly with different configuration parameters).
  • the operation of an Activation Request Instance and associated CT Device Instances in asynchronous mode is illustrated in Figure 3.
  • CT_Service specifies three Agent Templates, "AT_1", “AT_2” and "AT_3”; a device being configured by executing the Agent Templates in the specified order for that device.
  • CT Device Instance For the defined devices.
  • One CT Device Instance is created for each of devices "device 1", “device 2" and “device 3", identified by the Device ID of the respective device.
  • Each CT Device Instance then executes the sequence of Agent Templates specified in the Control Template in parallel, independently of the other CT Device Instances. The sequence is the same for each CT Device Instance, but the instances are not synchronized, executing and completing at their own pace.
  • Lock-stepped operation provides for synchronization between CT Device Instances and can, for example, be used when a service is being created that requires certain configuration steps to be completed on all devices before the next configuration steps can be performed. It also permits services that require configuration to be carried out step-wise at either end of a connection to be created in strict order.
  • the Control Template may provide the configuration instructions for setting up both the MPLS tunnel and, subsequently, the IP service. However, before configuring the IP service on the router devices, the Control Template may specify that there must be a CHECK operation performed on the router to ensure that the tunnel has been correctly installed. There may be other control-related reasons why synchronised operation is desirable.
  • the configuration instructions (typically invoking Agent Templates) in a Control Template are grouped into instruction blocks referred to as "steps". Each step defines a sub-sequence of configuration instructions, which should be completed across all CT Device Instances before the next instruction block or step can be processed.
  • FIG 4. The right-hand side of Figure 4 again shows an XML fragment defining the devices for a service, and the Control Template itself.
  • the Control Template is divided into a number of steps using a "#STEP" control command with a numerical step identifier.
  • Each step has to be completed for all CT Device Instances in the Activation Request Instance (i.e. for all devices in the service) before the next step can be started, as shown in the main diagram of Figure 4.
  • each step specifies only a single AT. However, a step may also specify more than one AT (or other instructions) or may be empty (i.e. specifying no ATs/instructions).
  • the "#STEP" commands in the Control Template thus serve to define synchronization points in the control template. Multiple concurrent CT Device Instances of the Control Template are synchronized at the specified synchronization points so that each only executes instructions after the synchronization point once all others have completed executing instructions before that synchronization point.
  • the same instructions are performed for each device (either asynchronously or synchronously).
  • not all device activations require the same operations to be performed on all the devices that are being activated. Instead, in some cases, different device types may require their own activation sequences. This type of activation is referred to as asymmetric activation.
  • An example of a service which may require asymmetric activation is a service for providing user access to an authenticated server. The user end of the connection to the server will typically need some basic configuration to be applied to provide connectivity to the server. At the server end, similar configuration will typically be needed; however, additional configuration may be required to add the user's details to the authentication configuration of the server.
  • Control Template that is invoked to implement this service then selects and performs the appropriate actions on each device.
  • the Control Template specifies different instruction sequences for each Role (i.e different sequences of Agent Templates to be invoked). Within each Role, instruction sequences may be divided into synchronized blocks as described above (e.g. using the STEP control structure).
  • FIG. 5 again shows an XML fragment defining devices involved in a service.
  • each device is assigned a "Role” value (in this example, "customer edge” and “provider edge” respectively).
  • the main diagram of Figure 5 illustrates execution of the Control Template using the specified devices.
  • the correct activation sequence is selected and executed by matching the Role defined for the device to the Roles specified in the control template.
  • the first sequence defined in the Control Template (“AT_1 , AT_2, AT_3") is executed.
  • the second sequence is executed ("ATJ”, "AT_2”, “AT_4",”AT_5", “AT_6”).
  • Asymmetric activation may be combined with lock-stepped operation (synchronized operation) as described above to allow complex activation processes to be defined in which different devices require different activation sequences (i.e. activation is asymmetric), but some form of synchronization is nevertheless required between those different activation sequences.
  • An example is shown in Figure 6.
  • the Activation Request is implemented in a different manner by two or more devices providing the service.
  • This example makes use of both the Role and the Step concept that were introduced in the previous examples, roles being used to distinguish between different device types and specify different activation sequences for each device type, and steps being used to specify synchronization points for synchronizing execution of the CT device instances for the devices.
  • synchronization can be achieved even between the different activation sequences defined for different device roles or types.
  • a step may not specify any activation commands at all (i.e. an empty step can be specified) - this can be used, for example, where activation of one device needs to wait until other devices have reached a certain activation state.
  • corresponding synchronisation points should preferably be defined in each of the different instruction sequences.
  • the corresponding synchronisation points may, for example, be identified by way of a step identifier, or simply by way of the order in which the steps are specified.
  • VPN Virtual Private Network
  • the ADD Activation Request may include the router ID of the CE and PE device, the IP addresses and netmasks for the creation of IP interfaces on each device, the parameters for a rate-limit service on the CE device and the
  • VRF Virtual Routing and Forwarding table
  • the CE device requires the following AT calls:
  • CT_Make_Vpn_Leg ADD Role PE #STEP 1 //make interface on CE for mgmt VPN
  • the CE and the PE devices need different configuration. This is provided for using the Role construct.
  • both devices receive the correct set of AT invocations for their role in the network.
  • the same Control Template has been used.
  • a management VPN is created before the customer service VPN. What this means is that two MPLS VPN VRFs are created on the PE.
  • the management VPN is used to maintain reachability to the CE device once it has been put in the customer service VPN.
  • the management VPN should typically be installed first. Then the customer VPN can be created without the CE being unreachable to the Agent that controls it.
  • each Control Template should preferably have at least one Role section specified though there is no upper limit.
  • the Control Template may have a DEFAULT Role specified that describes what operation to take if no match for a Role section in the CT can be found to the Role of a device specified in the Activation Request.
  • the Agent Templates are invoked using a "CREATE
  • ATJMame represents the name of the Agent Template to be invoked.
  • Control Templates may contain as many STEPs as are deemed necessary.
  • all the ATs (and nested CTs) in a STEP must complete before the Controller can begin processing the next STEP, under the control of the Activation Request Instance.
  • IP interface on the CE device should be added before the VPN is created on the PE, so there is CE interface configuration performed in each odd STEP, before the corresponding VRF is created in each even STEP.
  • the CT designer need only include a single STEP, followed by the list of Agent Templates to call.
  • the CT designer may specify as many STEPs as there are Agent Template calls, so that each STEP contains a single Agent Template invocation.
  • STEPs extend across all Roles in the
  • each Role section in the Control template should preferably contain the same number of STEPs. In this way, asymmetric lock-stepped operation can be achieved.
  • the CT mini-example on the right side of Figure 6 illustrates this point. If a different number of
  • a STEP it is permissible for a STEP to contain no ATs or nested CTs (or other instructions). If an empty STEP is specified for a device role, configuration of the device simply pauses until the step has been completed across all devices. This can be useful where devices need to be in a certain state before configuration of other devices can continue. On the other hand, where configuration actions on two devices can safely proceed independently of each other, these actions can be specified in the same STEP. Invocation command sections
  • the Controller interface permits a Control Template to be invoked with an ADD, DELETE or CANCEL command in an Activation Request.
  • An ADD command is used to configure devices to create a new service.
  • a DELETE command is used to configure devices to remove an existing service.
  • the CANCEL command removes an unprocessed Activation Request from the Controller message queue.
  • a MODIFY command may also be provided to allow an existing service to be reconfigured.
  • Control Templates can preferably include separate ADD, DELETE and
  • the ADD section is used each time the Control Template is invoked with the ADD command.
  • Each Agent Template listed in this section will be paired with the appropriate Agent Template invocation command for the case where the service is being created (i.e. "CREATE AT_Name").
  • the DELETE section is used each time the Control Template is invoked with the DELETE command.
  • Each Agent Template listed in this section will be invoked by the appropriate Agent Template invocation command for the case where the service is being deleted (i.e. "DELETE AT_Name").
  • the MODIFY section is used if the Control Template is invoked with the MODIFY command, and Agent Templates may accordingly also be invoked with a suitable MODIFY command.
  • a modify section could perform DELETE and ADD actions to reconfigure the service as required. Modification of a service may involve changes to service parameters, such as a change in service quality, quantity or content, or may involve rearranging the service, for example by changing a termination location (e.g. in response to a service user relocating to new premises).
  • the Control Template may allow different types of modification to be specified, for example as multiple MODIFY sections or using a wider range of modification commands. Alternatively, different types of service modification may be specified in separate Control Templates.
  • Agent Templates may themselves specify different configuration operations to be performed depending on whether an Agent Template is invoked with a CREATE, MODIFY or DELETE command.
  • Agent Template invocations return a value indicating success or failure, and may also return more detailed information using appropriate response codes (for example error codes).
  • response codes for example error codes.
  • a Control Template provides a recipe of the ATs that need to be invoked to create a service (though as already mentioned, other commands may also be provided in addition to AT invocation). Simple activation operations can be performed by a simple ordered list of ATs. However, more complex services may require the Controller to make choices about which AT to use in a particular case. To allow more complex activation sequences to be encoded, Control Templates therefore preferably provide control structures such as "if/then/else", "switch” or loop constructs. For example, a Control
  • Template may specify a conditional choice of which AT to invoke next based on DVI/DII passed to the Control Template in the Activation Request.
  • the Control Template examines the type of card that is specified in the DVI of the device being configured. If it is an Ethernet port, then an AT that implements traffic shaping is invoked; if it is an ATM port, then an AT that implements CAR (Committed Access Rate) is used. If neither of these match, then an error code is returned. The error code may, for example, be written to the CT Device Instance log. In the following pseudo-code example, a "switch" statement is used to choose the AT call to make to set the Layer 2 encapsulation on a router. If the card is an ATM1 Port Interface Card (PIC), then the card-level encapsulation setting AT is called. If the card is an ATM2 PIC, then the port- level encapsulation setting AT is called. If the card is any other type, then the wrong type of card has been included in the DVI and an error is logged and the Control Template exits.
  • PIC Port Interface Card
  • control structures such as loops, may also be provided.
  • Agent Templates represent basic configuration operations, usually performed on a single device.
  • Control Templates represent more complex configuration actions or processes, typically consisting of a number of basic configuration operations, and often involving multiple devices.
  • the same configuration operation may be performed on different device types or models in a different way - for example, different device models may use different command sets and syntax, or require a different sequence of configuration steps to achieve essentially the same result.
  • the system may therefore store a different implementation of a configuration operation for each type or model of device for which the operation is used.
  • SATs device-specific Agent Templates
  • the system preferably allows configuration operations to be referred to in a device-independent manner. This is achieved by way of device-independent "placeholders", referred to as generic Agent Templates (GATs).
  • GATs generic Agent Templates
  • Generic ATs provide an interface definition for a configuration operation. This can include a name or other label for the operation and/or any configuration parameters required for performing the configuration operation.
  • one or more device-specific implementations of the AT are stored in the template library. These device-specific ATs conform to the interface definition provided by the generic AT, and specify the actual configuration commands required to perform the given configuration operation on a device of a certain type or model.
  • the interface definition provided by the generic ATs allows Control Templates to include references to ATs without specifying a particular device-specific implementation. The correct device-specific AT can then be selected during execution depending on the actual device being used.
  • a Control Template may invoke an Agent Template using a reference to a generic AT "GAT_configure_router (P1 , P2)" for performing a certain configuration task on a device of class "router", where P1 and P2 are configuration parameters.
  • the network may use various different models of router, possibly made by different manufacturers and using different command sets for configuration. Different device-specific ATs corresponding to the generic AT may then be provided for each router model, for example “SAT_configure_router_model_A (P1 , P2)” and “SAT_configure_router_ model_B (P1 , P2)", with the correct SAT being selected during execution of the Control Template.
  • Device-specific ATs may also define parameter conversion tables or rules for converting device-independent parameter values for given configuration parameters into device-specific parameter values suitable for a given device, and/or for formatting parameter values for the target device (for example by converting parameter values from a device-independent format into a device-specific format).
  • a GAT may have just a single SAT associated with it, typically where only a single device model is available in the network for performing a given role or function.
  • a single device-specific AT may perform different actions depending on circumstances (e.g depending on the target device model). This may, for example, be appropriate where the differences in configuration coding required are small (for example for different device models of the same device class from the same manufacturer).
  • the activation controller 14 replaces the generic AT references in the Control Template with calls to the correct device- specific ATs when creating a new CT Device Instance for a given device, based on the device information supplied in the activation request or on information obtained from the resource inventory using the device information supplied. In alternative implementations, the activation controller could determine the correct device-specific AT during execution of the CT Device Instance, at the point of invocation of the generic AT.
  • the activation controller 14 preferably stores a library of the device- specific ATs, along with generic AT definitions linked to associated device- specific ATs, to allow the matching of device-specific ATs to generic ATs at run-time as well as offline checking of Control Templates.
  • This example GAT defines the common parameters for a given configuration operation (in the example the configuration of a Martini pseudo- wire connection across an MPLS network).
  • the example is encoded in XML.
  • Command_l "interface %s%N/%N.%N", ⁇ Port_Type>, ⁇ Slot>, ⁇ port>, ⁇ subinterface>
  • Command_2 "encapsulation %S", ⁇ encapsulation>
  • Command_3 "mpls 12transport route %s %S", ⁇ peer-loopback>,
  • Command 1 "no interface %s%N/%N.%N", ⁇ i_2 Port ⁇ ype>, ⁇ Slot>,
  • Devi ce_Prompt Devi ce_Prompt_ ⁇ abl e (Devi ce ID)
  • the example includes both a CREATE section and a DELETE section for performing different steps depending on whether a service is being added or removed.
  • the SAT includes code to construct configuration commands in the format required by a given device and to transmit these commands to the device.
  • the activation controller 14 is implemented as a Java application executing on a Java Virtual Machine and uses the multitasking capabilities of the Java Virtual Machine to provide the necessary concurrency for executing multiple CT Device Instances in parallel. This is preferably achieved with a relatively small number of long-lived threads in the activation controller configured to spawn off activity in the Agent Templates and, having initiated an Agent Template, to move on to other tasks rather than wait for a response.
  • the solution is preferably event-driven, so that Agent Templates respond autonomously when complete. These events can initiate further activity in the activation controller.
  • a background 'clean-up' activity can also be provided that identifies Agent Templates, or whole Activation Requests, which have failed to respond (based on criteria such as a time-out), and which then initiates an appropriate recovery or rollback procedure.
  • Agent Templates can also make use of parallelism. For example, if a number of devices can use one device-specific
  • AT (if, for example, they are different instances of the same device type) then only one AT instance may be invoked and the AT instance then drives the multiple devices in parallel.
  • control templates and agent templates are encoded and stored in the template library 16 as XML documents. Additionally, for each distinct device type, an XML document is preferably stored specifying how to communicate with devices of that type. This information is then used to transmit the configuration commands defined in the device-specific ATs to the devices.
  • Templates are preferably designed for reuse, and different sets of templates can be defined for different environments.
  • the templates used in a given deployment of the system can be modified and new templates can be added to reflect changes in deployed network resources and equipment.
  • the system preferably provides XML schemas defining the document formats for the various types of template stored in the template library (e.g. Control
  • ServiceDelivery_schema used to describe the device-specific Agent Templates including translation tables used, for example, to translate generic parameters to device-specific ones
  • DTDs Document Type Definitions
  • Tools can be provided to support the management of the template library including, for example, the following functions:
  • Compiler for compiling JavaScript into object code (which provides syntactic validation) and converting or formatting data from XML documents into a data format suitable for loading into the inventory and/or activation controller;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé servant à configurer un système de télécommunications pour fournir un service impliquant plusieurs dispositifs. Ce procédé consiste à recevoir un script de configuration spécifiant une séquence d'instructions de configuration de manière à configurer au moins deux des dispositifs pour fournir le service et, parallèlement, à exécuter une instance du script de configuration pour chacun des deux dispositifs en vue de la configuration des deux dispositifs pour fournir le service. On peut utiliser ce procédé comme une partie d'un système de gestion de réseau ou un système de fourniture de services.
PCT/GB2007/000565 2006-02-20 2007-02-20 Procédé de configuration de dispositifs dans un réseau de télécommunications WO2007096591A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0603360.9 2006-02-20
GB0603360A GB2435362B (en) 2006-02-20 2006-02-20 Method of configuring devices in a telecommunications network
US11/473,003 US8380833B2 (en) 2006-02-20 2006-06-22 Method of configuring devices in a telecommunications network
US11/473,003 2006-06-22

Publications (2)

Publication Number Publication Date
WO2007096591A2 true WO2007096591A2 (fr) 2007-08-30
WO2007096591A3 WO2007096591A3 (fr) 2007-11-08

Family

ID=38027143

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2007/000565 WO2007096591A2 (fr) 2006-02-20 2007-02-20 Procédé de configuration de dispositifs dans un réseau de télécommunications

Country Status (1)

Country Link
WO (1) WO2007096591A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111988323A (zh) * 2020-08-24 2020-11-24 北京天融信网络安全技术有限公司 IPSec隧道建立方法、装置、网络***及电子设备
WO2022143572A1 (fr) * 2020-12-29 2022-07-07 华为技术有限公司 Procédé de traitement de message et dispositif associé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997040449A1 (fr) * 1996-04-22 1997-10-30 Motorola Inc. Procede et appareil de synchronisation de la mise en oeuvre d'informations de configuration dans un systeme de telecommunications
US20020035404A1 (en) * 2000-09-14 2002-03-21 Michael Ficco Device control via digitally stored program content
WO2002091209A2 (fr) * 2001-05-08 2002-11-14 Narad Networks, Inc. Systeme et procede pour la prestation de services de reseau

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997040449A1 (fr) * 1996-04-22 1997-10-30 Motorola Inc. Procede et appareil de synchronisation de la mise en oeuvre d'informations de configuration dans un systeme de telecommunications
US20020035404A1 (en) * 2000-09-14 2002-03-21 Michael Ficco Device control via digitally stored program content
WO2002091209A2 (fr) * 2001-05-08 2002-11-14 Narad Networks, Inc. Systeme et procede pour la prestation de services de reseau

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111988323A (zh) * 2020-08-24 2020-11-24 北京天融信网络安全技术有限公司 IPSec隧道建立方法、装置、网络***及电子设备
CN111988323B (zh) * 2020-08-24 2022-09-23 北京天融信网络安全技术有限公司 IPSec隧道建立方法、装置、网络***及电子设备
WO2022143572A1 (fr) * 2020-12-29 2022-07-07 华为技术有限公司 Procédé de traitement de message et dispositif associé

Also Published As

Publication number Publication date
WO2007096591A3 (fr) 2007-11-08

Similar Documents

Publication Publication Date Title
US8380833B2 (en) Method of configuring devices in a telecommunications network
KR100453824B1 (ko) 이기종 네트워크 장비의 구성 관리를 위한 엑스엠엘 기반망 관리 시스템 및 방법
US7177924B2 (en) Command line interface processor with dynamic update of attribute dependencies
JP3439337B2 (ja) ネットワーク管理システム
US20190324793A1 (en) Transaction control arrangement for device management system
EP2541868B1 (fr) Procédé et dispositif de gestion de terminal selon la commande des droits
US20060248145A1 (en) System and method for providing various levels of reliable messaging between a client and a server
EP2302864B1 (fr) Procédé pour traiter le format tlv pour des données de communication
AU2004216794A1 (en) Universal deployment tool
WO2003098462A1 (fr) Systeme et procede de transformation de commandes de configuration
EP3796667B1 (fr) Procédé et appareil de basculement de fibre optique, dispositif de commande sdn, système et support d'enregistrement
JPH08314825A (ja) コマンドスクリプトの実行制御方法
EP1612994B1 (fr) Procédés et dispositifs pour la génération de transactions de gestion en XML contenant une expression XPath
JP2006065811A (ja) リソース管理方法、装置及びプログラム
US6976263B2 (en) Mechanism for encoding and decoding upgradeable RPC/XDR structures
WO2007096591A2 (fr) Procédé de configuration de dispositifs dans un réseau de télécommunications
CN114640569A (zh) 动态消息管理装置、设备、***、方法及存储介质
WO2012069077A1 (fr) Gestion de configuration d'élément de réseau
Cisco Updating the Mainframe Application Software
Fleischmann et al. Specification and implementation of an ISO session layer
US20030212919A1 (en) Updateable event forwarding discriminator incorporating a runtime modifiable filter
Kimle et al. jOCCI–general-purpose OCCI client library in java
CN117908904B (zh) 一种k8s集群部署及运维管理的方法和***
CN114816675A (zh) 基于低代码平台的应用部署***及方法
KR20230165646A (ko) 네트워크 기능 가상화 환경에서 가상화된 네트워크 기능을 업그레이드하기 위한 전자 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07712742

Country of ref document: EP

Kind code of ref document: A2