AN ENVIRONMENT FOR STUDYING SWITCHING SYSTEM SOWWARE ARCHITECTURE
`
`S. Agganval, F. S. Dworak, and P. Obenourf
`
`Bellcore
`Morristown, NJ, USA 07960-1961
`
`ABSTRACT
`
`The focus in switching systems is increasingly on the design
`and development of the software needed to implement the
`desired user and system level functions. The cost of this
`software development is now a major cost in a new system.
`In
`this paper, we describe
`the design and
`initial
`implementation of a switching system software environment
`that can be used to study a variety of problems in software
`development. Problems that can be studied include the
`correct functional decomposition of user-level services, the
`appropriate distribution of control functions at different
`places
`in
`the network, and
`issues of
`reliability and
`robustness. We show how
`the switching
`software
`environment is built using the IC* model of parallel
`the design of
`the
`computation, and we emphasize
`abstractions needed to implement call processing functions
`and switch resource management.
`
`1. INTRODUCTION
`The cost of software development is a major cost in a new
`system, and the failures of the system can generally be
`traced to problems with the software. Part of the problem
`is that software development is still an art. There are few
`guidelines or tools that one can use to more effectively
`build the needed software components. In this paper, we
`describe the preliminary design and implementation of a
`switching system modeling environment. We feel that a
`more elaborate environment based on this approach (for
`example, modeling a network) would be useful in studying a
`variety of problems in software development such as
`prototyping o f user-level services and the protection of
`system resources.
`Several technological advances have influenced our abstract
`design and approach. First, because of processor
`technology, there is a tremendous increase in computation
`capability that can be distributed in a switching system and
`switching network. Second, because of the increase in
`communications capabilities through the rapid introduction
`o f fiber in the network, there is an increasing interest in
`providing a variety o f services, such as video and data
`to voice,
`in a uniform and
`in addition
`capabilities
`integrated way. And
`third, the architectural
`trend
`is
`towards more distributetl/concurrent capabilities at all
`levels of hardware design.
`t
`P. Obenour
`the Dept. of Electrical
`is a graduate student with
`Engineering and Center for Telecommunications Research, Columbia
`University. NY. NY 10027. This work has been supported in part by the
`National Science Foundation under Grant #CDR-84-21402.
`
`~
`
`There are several software problems associated with these
`hardware trends that we intend to investigate when our
`environment
`is more
`fully developed.
`First, can
`components be structured so that computation capability
`can be added to modules without disrupting other software
`components. For example, if tomorrow one introduced a
`more sophisticated telephone with additional capabilities,
`could a "small part" of the switch software be changed to
`take advantage of this? Secondly, can the switch software
`be designed to access the appropriate hardware resources
`in a uniform way. This requires being able to monitor
`resource allocations, and being able to adapt to program
`changes in a real-time environment. And thirdly, how can
`we efficiently write software modules,
`in a parallel
`language, that operate in parallel and coordinate as needed.
`In the next section, we describe the IC* model of
`computation and environment over which we develop our
`switching software environment. IC* supports a parallel
`programming language, and the IC* environment provides
`the ability
`to specify, simulate and analyze system
`descriptions.
`In section 3, we describe our switching
`software environment. We have initially focused on two
`aspects. First, we show how the call processing function
`can be decomposed, and we also discuss the abstractions
`of the hardware switch functions and the abstractions of
`the terminal equipment. Second, we discuss the design of
`explicit
`resource managers
`that are
`responsible
`for
`resources provided by the switch. Since all resource
`requests must be made through these managers, this
`provides a level of protection in an environment where
`untested software modules are being introduced. Finally,
`in section 4, we discuss future directions of this uork.
`
`2. THE IC* MODEI.
`IC* is a model of parallel computation 11 ,?,3,4]. An
`environment based on this model supports specification
`and simulation of complex systems. A system is described
`in terms of constraints on its states and the cause/effect
`implications that guide its state transitions.
`IC* can support a variety o f languages, including a research
`language called L.O. Users can model complex systems
`incrementally,
`specifying
`component
`behaviors,
`by
`assembling the behaviors, and linking the components by
`equating names.
`An overviea of IC* and 1,.0 is given here; they are
`described more thoroughly in the referenced papers.
`The language lends itself to both the furic-rional sprcificariori
`of a system and the sirnulatiori of an ahsrracr rm~chinr. 'l'he
`
`42.1.1.
`CH2535-3/88/0000-1365 $1 .OO 0 1988 IEEE
`
`1365
`
`GTL 1009
`IPR of U.S. Patent 7,324,637
`
`

`

`functional specification describes desired system behavior;
`the abstract machine represents a universal high level
`design intended to exhibit this functional behavior. By
`successive refinement, the abstract machine may be evolved
`into a specific design that we expect to simulate and test
`against a set of assertions from the functional specification.
`We are interested in exploring this process, defining a
`switching system abstraction, representing it in L.0, and
`using it for software architecture studies.
`IC* supports the description of large systems in terms of
`its components. These
`the
`invariant properties of
`properties represent patterns or laws of behavior called
`invariants. Invariant expressions define the allowed system
`states and state transitions. An L.0 list of invariants does
`not imply a sequential order of execution; rather, members
`of the list can be executed in parallel.
`At each step of a simulation,
`invariants define
`the
`constraining relationships among state variables and their
`history. Differential invariants specify conditional changes
`in these relationships. These differential invariants are
`expressed in L.0 as
`:> <effect>
`whenever <cause>
`Causes and effects are expressed as predicates. A state
`space predicate is a relation among variables in the state
`space.
`It
`is evaluated as either TRUE or FALSE,
`depending on whether
`the system state satisfies the
`predicate. Predicate expressions may include references to
`past system states.
`A simulation advances by testing whether the system state
`satisfies any cause predicates and by triggering associated
`effects when a cause condition is found to be satisfied.
`When an effect is triggered, the IC* model demands action
`that forces the effect predicate to become TRUE.
`A triggered effect can force a change in the system state,
`consistent with constraints defined
`in
`related
`static
`invariants. Static invariants are expressed in L.0 as
`maintain <constraint>
`A triggered effect can also modify the behavior of a
`activating or deactivating
`simulated
`component by
`invariants.
`Inactive
`invariants have no effect on the
`computation. There are several kinds of activation effect
`predicates. In I d , the simplest is stated as
`activate <set of invariants>
`The set o f active invariants is said to compose the
`activation space.
`Another kind of activation effect predicate conditionally
`activates a set of invariants until a cause predicate in an
`associated deactivator invariant is satisfied. Conditional
`activation is written as
`cond {
`
`{activate <set of invariants>},
`{<set of deactivators>}
`
`1
`Each L.0 deactivator begins with the until kelword.
`The sequence of successful computations affecting the state
`space and the activation space is shown in Fig 1. Execution
`
`occurs in sequential steps indexed by the positive integer
`values of x. At each step, the execution environment
`increases the value of a global time variable which can be
`referenced in cause predicates.
`
`STEP X+1
`
`I
`I I
`
`I
`
`PART OF
`STEP X
`x = step number
`A[x] = set of active invariants at step x
`St[x] = history of system states at step x
`S[x] = system state (part of St[x])
`C[x] = set of satisfied cause predicates
`EA[x] = set of triggered activation-effects
`ES[x] = sets of interdependent state-effects
`
`I
`I I
`I
`I
`
`Figure 1. IC* MODEL OF COMPUTATION
`Active differential invariants in A[x] are examined for
`cause predicates that are satisfied by St[x], the history of
`system states. Cause predicates can be tested in parallel.
`The set of
`satisfied cause predicates, C[x],
`triggers
`activation effects and state effects that must be satisfied at a
`subsequent step.
`When x advances, the triggered activation effects EA[x+l]
`change the activation state to A[x+l]. Then the triggered
`state effect predicates are examined. They are grouped
`with related static constraints in A[x+l] and partitioned
`into disjoint sets of interdependent constraints. A new
`system state S[x+l] is chosen from candidate state
`assignments that satisfy the constraints. The disjoint sets
`of constraints can be satisfied in parallel. If, at any time,
`the execution cannot find a state assignment that satisfies
`all triggered effect predicates and related static constraints,
`it halts.
`Delayed effects are also permitted, but not shown in Fig 1.
`They are scheduled at n steps after the triggering cause
`predicate is satisfied. The I,.O construct is
`whenever <cause> :n :> <effect>
`
`3. ARCHITECTURE STUDY ENVIRONMENT
`Our aim in building a switch environment is to provide a
`testhed fnr the study and evaluation of alternative switching
`system
`software
`architectures and principles.
`The
`development o f the switch environment involves two tasks:
`
`1366
`
`42.1.2.
`
`

`

`assumed to be fast enough so that any input lag between
`states of abstract and physical objects can usually be
`ignored by call handling programs.
`On the other hand, the state of a controlled physical object
`may lag the desired state. An autonomous periphery reads
`the desired state, compares it with the current state and
`orders in progress, generates any new messages needed to
`effect the state change, and records successful completion.
`This approach isolates the call processing software from
`the network elements it must control, hiding differences
`among various subsystem implementations.
`
`q
`
`SWITCH
`PERIPHERY
`
`CALL
`PERIPH
`SEGMENT
`HANDLERS HANDLERS ALLOCATORS
`
`VIRTUAL
`RESOURCE
`
`the creation of a switch system model that satisfies certain
`design goals and the precise specification of the model in a
`suitable language.
`A second goal is to investigate use of the L.0 language in
`this application because of its useful properties: (1) easily
`expressed parallelism in independently specified invariants;
`logical
`time for specifying
`(2) explicit referencing of
`intervals, scheduling future effects, and referencing past
`states in the history of execution; and (3) support for non-
`intrusive observation of the execution.
`In the design of our switch system model and specification,
`we
`strive
`to provide a degree of modularity and
`intermodule protection which enables modules to be added,
`removed, or changed with ease and without an undesired
`effect on other existing modules. In addition, we aim to
`facilitate the observation, analysis, performance evaluation,
`and control of the specified switching system model. The
`model evolves from a high level abstraction that is intended
`to be consistent with many alternative implementations.
`To aid study of design issues concerning modularity and
`intermodule protection, the switch environment provides:
`(1)a uniform way of specifying interactions, connections,
`and communications between
`switch
`system model
`components, (2) the specification of constraints on the
`the
`interactions of
`component behaviors,
`and
`(3)
`specification of a resource allocation strategy aimed at
`protecting components from each other. In the future, we
`intend to provide a fourth feature - the specification of a
`uniform data management scheme.
`3.1 Abstract Call Processing Components
`We design a high level abstraction of switching system
`software, seeking a modular, extensible structure that
`represents
`the
`functionality
`common
`to different
`implementations. Some of its components lend themselves
`replacement by
`autonomous
`subsystems or by
`to
`procedures
`that control
`interaction with
`equivalent
`functions in external network systems.
`Recognizing that some switching system software must be
`machine-specific, and cannot be part of a vendor-
`independent abstraction, we focus on user-level concerns
`and isolate them from concerns at the physical and
`operating system' levels.
`Issues relating
`level
`low
`t o
`peripheral communications are also avoided or deferred by
`initially describing the peripheral interface at a higher
`logical level.
`We also isolate the common user-level structure from
`potentially different
`implementations
`peripheral
`of
`subsystems which we assume to have a high degree of
`autonomy. This approach
`separates
`time-dependent,
`machine-specific control activity from the software that
`decides what actions should occur. It also separates time-
`critical event monitoring activity from the software that
`decides how to react to those events.
`The abstract machine's view of the periphery is through its
`representation
`in the states o f abstract objects. These
`objects- are -in &e h e r f a c e with- h autonomous switch
`periphery
`that gathers peripheral
`inforniation
`through
`hardwarelsoftware scanners and message handlers and
`updates current state information. The updating process is
`
`I I
`
`SERVER
`
`I
`I I
`INTE'RFACE
`Figure 2. SOME CALL PROCESSING ENTITIES
`i conversational circuit path through a switch comprises
`an originating segment and one or more terminating
`segments linked by a connector segment. All activity
`associated with these call segments is described by one of
`three types of call segment handler: an originating call
`handler, a terminating call handler, or a connector.
`A peripheral handler detects asynchronous inputs from the
`periphery, decodes them if necessary, and determines
`which entities should be notified. It may notify a per-port
`terminal handler that finds out "who" is making the request.
`and "what"
`is being requested, and then acts as an
`appropriate call segment handler.
`Call segment handlers may call server routines which, in
`turn, invoke lower level primitives. For example, if dial
`tone is required, an originating segment handler may
`invoke a user dialog server to control direct interaction
`between the user and the network. Following a script, it
`issues prompts and collects the user's responses. A simple
`script would return dial tone and collect dialed destination
`digits. A complex script might guide a user in changing
`service parameters.
`The originating terminal handler oversees activities that
`authenticate the calling user's identity and determine what
`the user is authorized to do on the line serving the call. A
`simple authorization
`sequence would examine stored
`complex
`privileges
`associated with
`the
`line. A
`authentication sequence could involve a locdy executed
`dialog or temporary diversion
`to another system that
`dialogs with the user, compares user-provided information
`
`42.1.3.
`
`1367
`
`

`

`returns a measure of
`
`information, and
`with stored
`confidence in the user’s identity.
`The terminal handler stays in control of the call segment
`dealing with an originating entity until
`the request is
`analyzed and found to be valid. Then control is passed to
`a connector that knows about all segments of the call and
`oversees all activities conducted by the terminal handlers.
`The connector
`links originating and
`terminating call
`segments. It is the focal point for all activity associated
`with the completed path through a switching machine. It
`invokes address translators
`that
`translate
`the dialed
`address and determine where the call should be routed.
`Note that this is initially a simple table look up but it may
`be replaced by a complex process for passing the dialed
`address to an intelligent network data base node that
`returns the answer.
`The connector checks the busyhdle status of the called
`line. If the call is between offices, this otherwise simple
`function may be omitted or, in common channel signaling,
`it may be replaced by the more complex sequence dealing
`with look-ahead-for-busy.
`Several types of terminal handlers will be neeeded. An
`ISDN line handler may need to invoke a message analyzer
`to decode messages from ISDN lines. For example, it must
`get the call reference number generated by the user, check
`for information elements, determine the requested bearer
`capabilities, determine or select a channel, retrieve any data
`the destination
`the CPE-type, and collect
`identifying
`address.
`We identify other entities called resource allocators that
`handle allocation, removal from service, and interact with
`entities that read and write the busyhdle state information.
`The connector may have to invoke a particular allocator
`called the channel allocator that deals with the fact that
`any of several lines, channels, or trunks may be selected on
`the terminating segment. The connector may also request
`reservation of connecting circuits, channels, and fabric
`paths (except in non-blocking fabrics) for the ensuing
`conversation.
`The terminating terminal handler checks terminating line
`privileges, handles alerting, receives reports of answer, and
`deals with
`any post-answer
`authentication of
`the
`terminating party.
`If the requestor seeks to be added on to an existing call,
`the connector for that call would be asked to oversee the
`addition.
`When a stable call is abandoned, the connector coordinates
`the disconnect and release activities of the originating and
`terminating handlers. It also ensures that system resources
`are returned to the resource pools. The connector also
`handles complex reconfiguration requests that may be
`received from the user or from network management
`processes, but these must be handled later.
`We will need a path server that uses a set of path
`primitives for generic operations on the periphery. For
`example, it needs to accept a well-defined set of requests
`for connecting logical entities through a transmission path
`with specified properties. It may, in turn, interface with
`
`different fabric control programs for various network
`fabrics while presenting a uniform interface to the higher
`level routines. It could be called by a handler that oversees
`final connection between call segments or by a handler that
`is dealing with the application of switched audible ring on
`an originating call segment.
`3.2 The Specification as a Collection of Behavior
`Definitions
`The switch model specification is developed by describing
`the abstract design as object and function behaviors in L.O.
`Examples of human, hardware, and software objects in the
`model
`are phone users, phones, and connectors,
`respectively. Examples of call processing functions are
`digit analysis and verification. Corresponding to each
`object or function is a set of behavior definitions. The
`switch model specification consists of the collection of
`behavior definitions associated with the component objects
`and functions.
`Note that objects and functions may be nested. For
`example, contained within a switch periphery is a switching
`fabric. The nesting of components in
`the model
`is
`paralleled by the nesting of behavior definitions in the
`specification. Thus, the organization of the model and its
`specification is hierarchical.
`3.3 Behavior Definitions
`A behavior definition consists of a set of predicates that
`specify the behavior of a given object or function. Consider
`the excerpt shown in Figure 3 and taken from a line
`handler behavior definition. The line handler referred to in
`Figure 3 services a subscriber line connected to an ordinary
`phone, The predicates partially specify the behavior of the
`line handler during call set up. The effect predicate
`specifies the first function performed during call set up -
`the provision of dial tone and digit collection. The activate
`predicate
`that
`follows effects
`the activation of
`two
`differential invariants that determine the response of the
`line handler to several events.
`The first differential invariant shown in Figure 3 specifies
`that if the periphery handler reports to the line handler that
`the call originator has placed the phone on-hook, the call
`set up procedure must be
`terminated. The second
`differential invariant specifies that if the line handler is to
`provide dial tone and digit collection, a command must be
`issued to the periphery handler (which will respond by
`requesting the allocation of a service circuit providing dial
`tone and digit collection). The second invariant also
`effects
`the conditional activation of
`three differential
`invariants
`that
`specify
`the appropriate
`line handler
`responses to reports or responses issued by the periphery
`handler and related to dial tone and digit collection.
`A behavior may be composed from other behaviors by
`using
`the
`the behavior
`include predicate. Consider
`definitions shown in Figures 4 and 5.
`3.4 Interconnection of Switch Sysrem Model Components
`A connection between a pair of switch system model
`components is specified by one or more static invariants
`that maintain equivalences
`in value between names
`associated with the different component behaviors. The
`
`1368
`
`42.1.4.
`
`

`

`define {
`thing :- behavior;
`name :- terminaljnitiating_calLset-up;
`des :- {
`effect
`
`activate {
`whenever
`periphhandl .reportfrom = #CUSTOMERON-HOOK
`
`when
`
`supervisor - #LINEJIANDL &
`function - #PROVIDEDIAL-TONEDIGIT-COLLECTION;
`:> terminal.initiating - #FALSE &
`call.stage - #NONE &
`supervisor - #LINEHANDL;
`function - #PROVIDEDIAL-TONEDIGITCOLLECTION
`:> (periph_handl.command-to -
`
`#PROVIDEDIAL~TONEDIGIT~COLLECTION) &
`cond {
`{
`activate {
`whenever
`
`#CUSTOMERON-HOOK
`
`#STOPDIAL~TONEDIGIT_COLLECTION) &
`
`whenever
`
`#C ANT_PROVIDEDIAL~TONEDIGIT~COLLECTION
`
`whenever
`
`#DIAL-TONE-DIGIT-COLLECTION_COMPLETED
`
`periphhandl .reportfrom -
`:> (periph-handl.command-to -
`(function - #NONE);
`periphhandl .responsefrom -
`: > function - #PROVIDE-CIRCUITSBUSYNESSAGE;
`periph-hand1 .response-from -
`:> (digits - peripLhandl.reportfrom.digits’) &
`(function - #ANALYZE-DIGITS)
`>
`}, { until
`>>>
`function = #PROVIDEDIAL-TONE-DIGIT-COLLECTION
`>>: ’ ’ _
`Figure 3. LINE HANDLER BEHAVIOR EXCERPT
`define {
`thing := behavior;
`name := switch-system;
`des := {
`include {[components]};
`include { [component-connections]}
`>I
`Figure 4. SWITCH SYSTEM BEHAVIOR DEFINITION
`define {
`thing := behavior;
`name := components;
`des := {
`include {[users]}; include {[phones]};
`include { [ subscr-lines]} ; include {[switches]}
`I>
`Figure 5. COMPONENTS BEHAVIOR DEFINITION
`component-connections behavior definition referred to in
`Figure 4 specifies the connections between phone users,
`phones, subscriber lines, and switches. Figure 6 depicts
`some of
`the components and component connections
`corresponding t o a single switch system.
`In Figure 7, a
`more detailed illustration of the connection between a
`phone and a subscriber line is shown. L.0 code specifying
`the connection is listed in Figure 8.
`Each o f thc two static invariants shown in Figure 8
`maintains an equivalence in value between a pair of nanies
`associated u.ith different behaviors. The first pair
`-
`phone. .vu hscrditir . outpur
`and
`suh.rcr-litie.phone. input
`-
`
`I
`
`SWITCH
`BEHAVIOR
`
`I
`- -
`-
`- -
`-
`-
`-
`
`PHONE
`BEHAVIOR
`
`SUBSCRIBER
`LINE
`BEHAVIOR
`
`-
`
`PHONE
`BEHAVIOR
`
`-_ -*
`
`SUBSCRIBER
`LINE
`BEHAVIOR
`
`PHONE
`USER
`BEHAVIOR
`
`PHONE
`USER
`BEHAVIOR
`
`Figure 6. COMPONENT CONNECTIONS
`
`BEHAVIOR
`
`BEHAVIOR
`
`subscr-line .output
`
`phone.input
`
`subscrJine.input
`
`phone.output
`
`Figure 7. PHONE AND LINE CONNECTION
`activate {
`maintain
`phone. subscr_line.output = subscr-1ine.phone .input;
`maintain
`phone.subscr-1ine.input = subscrJine.phone.outpu1
`I
`
`Figure 8. CONNECTION SPECIFICATION
`represents the phone output that is also the subscriber line
`input. The second pair - subscr-1ine.phone.ourpur and
`phone.subscr-1ine.input
`- represents the subscriber line
`output that is also the phone input. The names prefixed by
`phone correspond to the phone behavior. Similarly, the
`names prefixed by subscr-line correspond to the subscriber
`line behavior.
`To specify asynchronous intercomponent communicalion
`using message passing, a communication channel over
`which a switch system component may send messages is
`modeled. Messages transmitted over
`the channel are
`buffered or queued and delivered to the receiver in the
`order specified by the queue discipline (for example, FIFO
`or LIFO). Although our model currently includes only
`error-free channels, other types of channels can be easily
`modeled.
`A FIFO communication channel behavior can be
`instantiated an arbitrary number of times and used to
`specify the connection between many different pairs of
`component
`behaviors.
`The
`behavior
`definitions
`t o FIFO channel communication are
`corresponding
`included in a library of behavior definitions relating to
`component connections. By the establishment and use of
`connection conventions and the formation of the library of
`connection behavior definitions, n-e provide a uniform way
`of
`specifying
`interactions,
`connections,
`and
`communications betueen components. The development of
`
`42.1.5.
`
`1369
`
`

`

`a standard way of specifying component connections
`increases the ease with which component behaviors can be
`added, removed, and modified and aids the study and
`development of ways of simplifying the addition, removal,
`and modification of the simulated components themselves.
`3.5 Protection and Resource Allocation
`A software component is said to be protected with respect
`the addition,
`to a particular group of components if
`removal, or modification of any component in the group
`does not
`inappropriately affect
`the behavior of
`the
`protected
`component. The protection of
`software
`components involves the constraint of interactions between
`the components and the control of
`the allocation of
`resources shared among the components. In Section 3.6,
`we discuss the specification of constraints on component
`behavior
`interactions. In Section 3.7, we describe the
`specification of a resource allocation strategy aimed at
`protecting components.
`3.6 Specifying Constraints on Behavior Interactions
`Several different constraints on software component
`interactions can be modeled. For example, the values of
`component inputs and outputs can be restricted to specified
`domains. In addition, the set, or even the sequence, of
`commands to which a software component responds can be
`constrained.
`Consider the restriction of component input or output
`values to a particular domain. Figure 9 contains an excerpt
`the phone_input_output_value_constraints behavior
`from
`definition.
`effect
`domain.user.input = #
`{ ON-HOOK; IDLE; CONVERSE;
`DIAL.POUND; DIAL.STAR;
`DIAL.0; DIAL.l; DIAL.2; DIAL.3; DIAL.4;
`DIALS; DIAL.6; DIAL.7; DIAL.8; DIAL.9 };
`activate {
`whenever
`clones {
`for := {?i};
`suchthat := {exists( domain .user .input .?i)} ;
`des := {user.input = #?i}
`}
`:> error.user.input = user.input’
`}
`
`Figure 9. PHONE 110 CONSTRAINTS
`first predicate defines
`the value of
`the name
`The
`do,nairz.user.input.
`The second predicate generates an
`the name user.input,
`the value of
`error message
`if
`representing the input to the phone from the phone user,
`falls outside the domain.
`that a
`the commands
`Consider now
`restrictions on
`component can issue or respond to. As an example,
`suppose we wish to specify the domain of commands to
`which a resource allocator responds. We may choose to
`select a domain consisting of two commands, the first of
`which requests the use of the resource and the second of
`which requests the release of the resource. Note that
`constraining
`the set o f commands responded to by a
`component is analogous to restricting the set of messages
`
`reponded to by an object in an object oriented system.
`It is also possible to describe input or output value domains
`that change with
`time. By specifying event-triggered
`changes
`in command domains, acceptable command
`sequences can be represented.
`3.7 Resource Management
`An essential part of an intercomponent protection strategy
`is a resource management scheme that controls access to
`resources, guards against the improper use of resources,
`and prevents an entity from hogging resources and
`consequently degrading the service provided (and possibly
`guaranteed) to other entities. The resource management
`scheme developed for the switch environment specification
`has features aimed at providing component protection. For
`example, resource allocators are designed in such a way
`that they always retain control over the use of allocated
`resources,
`regardless of whether
`resource users are
`cooperative. Thus, a resource allocator can monitor the
`use of allocated resources and, if necessary, rescind the use
`of the resources.
`In addition to providing protection features, the resource
`management
`strategy
`incorporates standard ways of
`requesting, granting, and releasing resources. Through the
`development of a uniform resource management scheme,
`we aim to simplify the development and maintenance of the
`switching
`environment.
`Included
`in
`the
`resource
`management specification are conventions regarding the
`formatting of
`resource
`requests,
`the communication
`between
`resource requesters and allocators, and
`the
`connection between a resource requester and the requested
`resource.
`Corresponding to each resource or pool of resources (such
`as service circuits, switch paths, and connectors) is a
`resource allocator component, which fields and filters
`requests for resources, determines whether to allocate
`resources, establishes connections between an allocated
`resource and a requester granted use of the resource,
`monitors the use of the resource, and reclaims the resource
`when necessary.
`The set of behavior definitions corresponding to a resource
`allocator includes a specification of the interface between
`the
`resource allocator and
`resource
`requesters. A
`command domain specifies the set of commands to which
`the resource allocator responds. The appropriate format
`for a given command is defined by a template specifying the
`command parameters (and possibly parameter values) that
`must be included in the command. A template functions
`as a form that a component issuing a resource allocator
`command must copy and fill out to have its command
`processed. Refer, for example, to the template depicted in
`Figure IO.
`resource.type =
`#I~IAL,-TON~-CrENERATOR_SERVLCE_CIRCUIT;
`requesterid =
`;
`line-requiring_service.id =
`
`;
`
`Figure 10. DIAI, TONF, RkQUEST TEMPLATE
`‘rhe template tletineu the correct format of a command
`reque<ting the iiw o f ;I dial tone generator senice circuit.
`
`1370
`
`42.1.6.
`
`

`

`The template parameters include the type of resource being
`requested, the requester ID, and the ID of
`the line
`requiring service.
`In addition to the command templates, other types of
`resource allocation information may be made available to
`resource requesters. For example, a resource allocator
`may provide information about the number of requesters
`pending or the expected time a requester must wait before
`acquiring the use of a resource. Such information may be
`used by a potential resource requester in determining
`whether to request the resource.
`To request a resource, a requester creates a copy of the
`command template corresponding to a resource request
`and fills in appropriate values for the template parameters.
`The request
`is fielded by a
`resource allocator, which
`detects
`the existence of
`instances of appropriately
`formatted request commands. From the fielded request
`commands, the resource allocator selects those commands
`with appropriately set p