CA2380263A1 - A development framework for efficient uniform control of heterogeneous communication networks - Google Patents

Abstract

As new Internet networking technologies appear, there is a growing need for efficient control of Network Elements (NE) (i.e. routers, switches, etc:).
However, today's NE control is largely a manual activity, therefore inefficient and unscalable, and the inherent heterogeneous nature of complex networks -that is, the fact that NEs are of different technologies and have different functionality and configuration-management interfaces- makes NE control even more difficult and challenging.
This thesis presents a solution that allows the development of automated, distributed web-based control of heterogeneous NEs through a common interface that hides the underlying NE-specific differences, allowing control of heterogeneous NEs in a transparent way. This solution consists in a software development framework oriented towards reliability -thus service availability-, performance -hence scalability-, and fast extensibility -hence easy integration and rapid adaptability to the ever-changing networking technologies-, without neglecting security.
General design requirements are first discussed. Next, particular attention is given to CLI (Command Line Interface) protocols, where issues related to the automation of CLI
interaction are extensively discussed. A real-time approach, using extended finite state machines, is proposed as a key element in this framework. Finally, a working and efficient implementation that supports CLI automation is presented, where emphasis is laid upon the short delays -typically a day- required to augment the application with a new set of NE
control operations -Traffic Conditioning operation set for example.

Description

A Development Framework for Efficient Uniform Control of Heterogeneous Communication Networks By Khaldoune ZINE EL-ABIDINE
A thesis submitted to the School of Graduate Studies and Research ' In partial fulfillment of the requirements for the degree of Masters of Applied Science Ottawa-Carleton Institute for Electrical Engineering Department of Electrical Engineering Faculty of Engineering University of Ottawa December 2001 Khaldoune ZINE EL-ABIDINE, Ottawa, Canada, 2001.

Table of contents ABSTRACT
...............................................................................
............................................................II
ACKNOWLEDGEMENTS
.......................................................................:.......
................................. III
TABLE OF CONTENTS
...............................................................................
..................................... IV
LIST OF
FIGURES...........................:............:..............:................
....................................................VII
LIST OF
TABLES:........................................................................
.......,............................................ VIII
GLOSSARY OF
TERMS.................................................:........................
.................................:........ IX
1 INTRODUCTION ..................... .......... ........
.....................................................................
i ' 1.1 MOTIVATION AND RESEARCH OBJECTNES
...............................................................................
..1 "~"'"'1.2 ORGANIZATION OF THE THESIS AND
CONTRIBUTIONS.................................................................6 WORK..................................................:........................
...,................................:..........9 2.1 APPLICATION
CONTROL......................................................."................
...........,........................
l O

2.2 NETWORK
CONTROL........................................................................
.............................:............12 2.3 NETWORK
MANAGEMENT.....................................................................
.,...................................17 2.4 OTHER RELATED
WORK............:..............................................................
..................................21 ,,.~ 2.4.1 A pattern system for network management interfaces ....................................................21 2.4.2 The "Expect"
Toolkit.........................:......:............................:..........
..............:..:............22 3 BACKGROUND: SOAP, WSDL; REGULAR EXPRESSIONS AND
UML.........................:26 3.1 THE SIMPLE OBJECT ACCESS PROTOCOL ............:......................
~..............................................27 3.1.1 Introduction ...............................................:....................:..........
.....................................27 3.1.2 Firewall issues.........................................................................
.......................................30 3.1.3 SOAP and Security.......................................................................
...................................31 3.2 WEB SERVICES DESCRIPTION
LANGUAGE............:..........................................................
..........32 3.2.1 Introduction: Web Services Defaned ......................................................:........:..............:

3.2.2 Web Services related protocols........:.............................................................
..........:......33 , .

3.2.3 WSDL...........................................................................
...................................................35 3.3 REGULAR EXPRESSIONS AND KLEENE'S
THEOREM...................................................................38 3.3.1 Regular languages...................................:.:................................
....................................38 3.3.1.1 Basic definitions..................................................................., ..................................38 3.3.1.2 Operations on languages ........................:.. ......
... ...39 3.3.2 Regular expressions...".............:...:..............................................
...................................41 IV

3.3.3 Finite automata..................:....................................................
.................................,..,...43 3.3.3.1 Deterministic finite automata ..........::.......................:...........................................
...44 3.3.3.2 Non-deterministic finite automata............................:..........................................
....47 3.3.3.3 Non-deterministic finite automata with A-transitions.............................................SO

3.3.3.4 Equivalence between DFA, NFA and NFA-A
.................................-.........:
.............5 I

3.3.4 Kleene's theorem ..:.............................:.....:........................................
...............:.............

3.4 I1ML FOR REAL-TIME COMPONENT-BASED DESIGN
........:..........................................:.............53 3.4.1 Elements...................................................:...................
..:................................................54 3.4.1.1 Structural elements...................................................:...................
.............:.............SS

...
3.4.1.2 Behavioral elements ...............................................................................
.........
.....57 3.4.2 Relationships..................................................................
...................................:.......:.....59 3.4.3 Diagrams ......................,..........................:.............................
.........................................60 ...............................................................................
.....:.................................61 4.1 THE PROBLEM OF DEFINING A COMMON VIEW OF NES
..............................................................61 4.2 HIGH-LEVEL
DESIGN REQUIREMENTS
.......:.......................................................................
........65 4.2.1 ClientlServer web-based architecture......:....................................................,.......
..........65 4.2.2 Extensibility ..............................................:.....................,..........
.....................................65 4.2.3 Reliability........................
......................:........................................................
.............66 4.2.4 Performance and Scalability.... .
............................................67 . ..............................,..

4.2.5 Securiy........................................................................
..,.................................................68 4.3 WEB-BASED DISTRIBUTED ARCHTfECTURE WITH
SOAP/HTTP.................................................69 4.4 SERVER-SII?E GENERIC
MODEL...........................:..............:.........,.....................
.......................70 C1.I-BASED CPA
DESIGN.......................................o.................................
.................. ...........76 S.1 CONTROL PROTOCOL
SELECTION....:.................................................................
.....:..................76 S.2 CLI-BASED CPA DESIGN ISSUES
...............................................................................
................BO
S.3 FSMS AND REGULAR EXPRESSIONS FOR CPA/CLI
INTERACTION.,........""..,.......,....................81 5.3.1 Introduction .........................:....................:................................
.................:...................81 5.3.2 The FSM
component..................................'...................................
..................................83 5.3.3 The Regular Expression Module......:.....................................................:............
............91 5.4 FURTHER ABSTRACTION: DYNAMIC TRIGGERING
FILTERS..........................,........,..,.................98 .......................:.......................................................
........103 6.1 THIRD-PARTY LIBRARIES AND TOOLS
...............................................................................
.......104 6.2 INFRASTRUCTURE UML DESIGN AND
IMPLEMENTATION...........,..........................,."...:....",." 1 O6 6.2.1 The Generic Control Server component..................................................................,.".

6.2.2 The Eternal Access Layer component......;:..............................................................
....109 .. . . .
6.2.3 The CPA component ....................:..........................................................
...................... I10 6.2.4 The FSM
component.................................:............,.......................
...............................113 6.3 IMPLEMENTATION OF A TRAFFIC CONDITIONING CONTROL FACILITY
.......,.,.....,.....,.,.........,... I 19 .. 6.4 TESTS AND
EVALUATION......"..............................:....................,..........
....................:..............125 V

RESEARCH..:::.:.::.::.:...,:.::................................................

7.I CONTRIBUTIONS OF THIS THESIS
..........................................................................._...
..............13O
7.2 FUTURE
RESEARCH..,.....:...........,..........................:....................,..
..............................:........_..132 gIBLIOGRAPHY.:.....................................................:...........
............................................................134 APPENDIX A: WSDL INTERFACE FOR THE TC SERVICE
....................................................139 vi List of Figures Figure 3-1: simplified SOAP-RPC packet layout (adapted from [5])...........................................................

Figure 3-2: an example of a deterministic finite automaton (DFA)..............................................................

Figure 3-3: an example of an NFA
................................:..............................................
................................

Figure 3-4: Layered UML
architecture...................................................................
.........
. ..................,..... 54 Figure 3-5: a capsule's structure...........................................:..........................
.:...........................................

Figure 3-6: an example state machine.
......................:........................................................
..........................

Figure 4-I : SOAPIHTTP for firewall-friendly web-based access. ..
................................. ........................ 69 Figure 4-2: Architecture of the generic control system. ... ..
...........................................:...........:.................71 Figure 5-1: General structure of a CLI-CPA.
..................:.................................,......................
............... 82 Figure 5-2: an FSM example.
:.........................................:....................................
........................:::..........:.:

Figure 5-3. FSM with internal REM................................:...........................................
........:........................

Figure 5-4: an FSM example with integer alphabet and attached ..
regular expressions. .............................. 90 Figure 5-5: the REM viewed as a dynamic filter controllable'uy ..
the FSM. .............................:................. 92 Figure 5-6: an inappropriate way of detecting late error printing.............................................
............... 94 Figure 5-7: impact of TTL on the FSM.
..........................:....................................................
........................

Figure 5-8: a FSM example involving an infinite TTL...............................:............................................
.....

Figure 5-9: the Factory Method pattern applied to DTFs.
........................................................:.................102 Figure 6-1: a general view of the working environment........................:...........................................
....:....105 Figure 6-2: Structure diagram of the Generic Control_Server 107 capsule...................................................,...

Figure 6-3: Simplified sequence diagram of the Generic Control_Server108 capsule.......................

Figure 6-4: ExternalAccessLayer containment hierarchy.
.............................................:................109 Figure 6-5: CPA class hierarchy.....................................111 ................................................:.... ..............

Figure 6-6: CLI CPA structure diagram.
.....................................:.........................................
....................112 Figure 6-7: Structure diagram of the FSM. ......................114 ....:..................................................................

Figure 6-8: Sequence diagram depicting FSM/R.EM
interaction..................................................................11 Figure 6-9: The base FSM
behavior.................................:.:..........:.:......................
....................................116 ,,, Figure 6-10: UML class diagram emphasizing containment relationships...............................................:.119 Figure 6-11: A common API for all NE classes.
....:.........:........................................................:.......
.........120 Figure 6-12: FSM class hierarchy for Foundry BigIron 4000.
..........................................:........................122 Figure 6-13: FSM class hierarchy for. Cisco 6505...........................................................................
......"...122 .
.
.

Figure 6-14: state-transition diagram for the state operational123 of the capsule FDRY_SetTC . .........

Figure 6-15: behavior diagram of the CreateTC
state..:....................................................,..........,.:...,.
..124 Figure 6-16: Test environment for the Generic Control Server...:..................................................,......,....127 vil List of Tables Table 3-1: transition table of the DFA of Figure 3-2..:..................................:........................................
...... 45 ............................
Table 3-2: transition table for the NFA of Figure 3-3................................................ .. 49 Table 6-1: response delays for createTC ( ) /deleteTC ( ) for BI4k. ......
....................................... 128 Table 6-2: response delays for createTC ( ) /deleteTC ( ) for C6505.......................:........................ 129 Vlll Glossary of Terms API Application Programming Interface ATM Asynchronous Transfer Mode CLI Command Line Interface CMIP Common Management Information Protocol CORBA Common Object Request Broker Architecture CPA Control Protocol Adapter DCOM Distributed Component Object Model FA Finite Automaton FCAPS Fault, Configuration, Accounting, Performance, and Security Management FSM Finite State Machine HTTP HyperText Transfer Protocol IDE Integrated Development Environment MIB Management Information Base MIME Multimedia Internet Mail Exchange NE Network Element (i.e. roofers and switches, etc. j NM Network Management OMG Object Management Group QoS Quality of Service Reg.Exp.Regular Expression REM Regular Expression Module RPC Remote Procedure Call SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol SONET Synchronous Optical NETwork SSH Secure Shell SSL Secure Sockets Layer TCP/IP Transmission Control Protocol/Internet Protocol UML Unified Modeling Language Web the Worldwide Web.

XML Extensible Markup Language ix 1 Lntroduction 1.1 Motivation and Research Objectives Today's communication network comprises many different transmission techniques and technologies. An IP packet might be sent over Ethernet, ATM, SONET, optical, etc.
to travel from one end to another. Multi-vendor network management and control, i.e. the management and control of "a network composed of elements from many different suppliers supporting different levels of functionality with different network architectures and protocols" [33], is setting up the grounds for a more performing and efficient QoS-capable network. For the communication industry; the capability of providing real-time control to different vendors' NEs is therefore becoming a crucial task and a difficult challenge at the same time. Indeed, one of the causes of the year 2001 downfall of the global economy was the lack of efficiency in the control of various communications networks. As a consequence, the control of NEs in general and of heterogeneous NEs in particular represents one of the hottest research subjects in communications area. It is related to traffic engineering, bandwidth managemem, admission control, QoS
and other research subjects. These researches are mostly motivated by the need of endowing audio and video stream transmissions with high quality.

The need for vendor-independent solutions emerged at least fifteen years ago.
Since then, significant progress in this field has been made. Today, CMIP and SNMP
are the results of this progress, although SNMP is considered to be the de facto standard [27, 31, 33] in Network Management (NM) given that most vendors offer SNMP-based products.
However, SNMP designers took a "minimalist" approach to NM, since "their design had to be effective for a broad range of devices, therefore requiring a low common denominator" [33]. As a result, there is always a remaining non-standard vendor-specific part for each NE, usually called "Enterprise MIB" [1], until anew update of the Standard covers the features supported by that proprietary segment.
Intensive research, briefly reviewed in Chapter 2, has focused on the above problem to allow integrated NM and provide uniform NM interfaces in order to release the full potential of the network. Because a manual type of intervention is still omnipresent in today's world of NM [26, 44], the previous efforts always implicitly assumed that the end manager is a human operator or a small number of collaborating human operators, thus characterized by slow activity. It was also implicitly assumed that the frequency at which a given network's configuration) changes today is typically low, that is, no more than a few times per month: Therefore, none of the previous research efforts focused on e~ciencyz in network control since it would have been rather irrelevant considering the ' That is, topology, architecture and settings of the different NEs composing the network Z In terms of response times for heavy and complex control operations that may involve a large number of end managers, as well as resource utilization implied by such activity.

actual situation. However, state-of the-art networking technologies tend to provide QoS
support, and thus new commercial services -possibly targeted towards mass-public- will eventually appear:
These services will have new and more stringent requirements. In particular, they will require frequent real-time configuration of the network, thus demand efficient and reliable control. With the inherent heterogeneity of the network introduced above, the development, of NE control applications that would bridge the gap becomes a tedious task. Meanwhile, the deployment of these commercial services is impeded and the network is not used to its full potential, resulting in important financial losses. As of this writing, no general software development framework for the control of heterogeneous NEs driven by performance and reliability concerns was found. Instead, most efforts in the literature are dedicated to high-level designs and architectures of integrated NM, where design and implementation details of leaf raanagers~ are usually left unspecified.
The development framework in question has to allow NE control which is:
~ E~cient: in terms of resource utilization and response delays.
~ Scalable: to be able to handle a large number of NEs simultaneously.
~ Reliable: it should never leave a NE in an inconsistent or unknown state.
~ Secure: to allow commercial-grade services.
' That is, software components communicating directly with NEs via wire management protocols.

~ Uniform and transparent: using a common control interface to deal with heterogeneous NEs. The underlying NE differences -such as control protocols, vendor, version, etc.- have to be hidden behind that common interface, and automatically detected and handled by the implementation.
~ Automated: it should be easy to automate long interaction sequences through simple operations.
~ Easily and rapidly extensible: in order to allow rapid integration of new networking software and hardware as they appear, hence minimize the impact '°"" time-to-market has on product costs. In particular, implementers of new control procedures need only to focus on network control logic without worrying about other implementation details of the framework.
~ Distributed: to allow remote control and configuration, preferably from any »~ client in the world. In particular, it should deal appropriately with firewalls and existing security infrastructure.
Note that it should not be the purpose of the framework to set a new standard in network management. Instead, it should offer a complementary solution for network element control rather than a replacement for existing protocols.
This thesis presents a framework that satisfies the above requirements.
Although the framework supports extensibility to any control protocol, particular analysis has been We agree to call "control protocol" any protocol used to control a network element.
,, 4 conducted regarding CLI interaction automation and issues related to its use for NE
control. There are several reasons for choosing CLI instead of SNMP or CMIP
that will be discussed later in Chapter 5, but which consist mainly in performance and reliability issues: CLI reveals to be more efficient in most scenarios and control with CLI can easily be made reliable.
A functional prototype that supports advanced features of CLI automation is presented as a fundamental starting point of the framework itself. Some of these CLI
features are:
a) Complex CLI interaction driven by NE responses. This interaction is modeled by UML extended finite state machines represented graphically.
b) Ability to parse multiple possible NE responses in parallel and make CLI
interaction decisions according to the received response.
c) Ability to detect "asynchronous text" (traps) and undertake appropriate actions to handle that "textual event" (typically an asynchronous error message for example).
d) Stream-based text parsing for best performance.
'~'" The undeniable power of distributed computing is incorporated to this framework making the uniform control interface securely accessible via the Web to insure firewall-friendliness. SOAP (Simple Object Access Protocol) [3] is the chosen middleware to '~" support web-based secure access. The framework remains, however, easily integrable to any other middleware (CORBA, for example).

1.2 Organization of the Thesis and Contributions This thesis is organized to provide an incremental understanding of the problem of uniform control of heterogeneous network elements in a distributed environment.
In Chapter 2, related work in the field of Network Management in general and Network Control in particular is briefly reviewed.
Chapter 3 presents an overview of the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), mathematical results in the field of regular expression matching, and the Unified Modeling Language (UML). Because UML
components and state diagrams are both the application environment and the foundation of many concepts proposed in this thesis, UML is reviewed in reasonable detail and emphasis is laid upon UML's real-time extensions. SOAP and WSDL are reviewed to justify their choice as the middleware for the web-based architecture of the framework.
Mathematical results related to regular expressions and finite automata are reviewed as well to demonstrate their efficiency since they are used in the implementation of the final ~..;, prototype.
,~", In Chapter 4, general issues related to the definition of a uniform NE
control interface are discussed. Next, design requirements for applications targeting uniform control of heterogeneous NEs are defined. Finally, the architecture of our framework is~
presented in two steps: The web-based architecture using SOAP and WSDL is presented, and a generic server-side model based on Control Protocol Adapters (CPA) is defined.

w~~
In Chapter 5, the problem of choosing a control protocol for a given NE is presented. The choice of CLI as , a starting point is justified. The particular case of CLI
interaction protocols is studied, and specific relevant issues are presented and addressed.
A component-based, real-time model is used to design the architecture. A new concept, called Dynamic Triggering Filter, is finally introduced as an evolution of regular-expression-based parsing in CLI interaction automation.
An implementation of the architecture introduced in the previous chapter is presented in Chapter 6. As a proof of concept, a limited uniform interface composed of two Traffic Conditioning (TC) operations is implemented. This interface handles two different types of NEs transparently. It is shown how fast and easy the augmentation of the prototype with these two operations was (typically a day), once the development framework was in place.
Finally, in ,Chapter 7, conclusions are presented on the costs and benefits of the presented framework for the deployment of uniform network control applications.
Recommendations are made for future design and implementation of this framework.
This thesis contains several research contributions, which can be summarized as follows:
"'" - Performance issues related to the control of network elements are specifically: - -considered for the first time.
,....

- A new methodology, which consists in uniform CLI interaction automation using a component-based real-time approach, is used for the first time in the field of network management and control.
- The requirements for uniform network control are presented. A generic framework that satisfies those requirements is presented.
- The technical aspects of the UML standard that are relevant to supporting the presented framework are examined. A tool that supports those aspects is briefly presented as well.
- The particular case of uniform CLI automation is studied extensively for the first time in Chapter 5, where the concept of "dynamic triggering filter" is also introduced.
- A fully functional prototype of the presented framework is constructed. A
test application is produced and tested.
- Recommendations are made for future research in uniform control of heterogeneous network elements.

a 2 Related work Despite the fact that the network control is one of the hottest research subjects in the area of computer communications, it received very little (if not at all) attention from the :f-- research and mainly from the industrial community. This fact is astonishing. There is common knowledge, and market analysts [41 ) confirmed it, that the present trend in the IT business is enhancing the mechanisms that allow providers to deliver real revenue, which means better, faster, easier to operate tools to provision, activate and control the network functionality. These desiderata cannot be accomplished without a complex service and network control platform able to define, create, and activate services in a dynamic way.
;,, The difficulties of approaching the subject are manifold where the main one is related to the fact that there is no prior work done in the area of using feedback principles ....
for controlling computer communications processes. It has to be mentioned, though, that in an invited talk M. Athans raised this issue even in a World Congress of IFAC in 1978 [40) and U. Warrier et al. [2b) in 1988 say that "the issue of system control is as crucial to network management as system monitoring, yet it has been largely ignored".
However, not too much work has been undertaken since for continuing this venue, and it is somehow strange in this research community that conjectures made about twenty years ago did not have any resonance at all till recently. Of course, there are reasons for this silence. There are a series of conceptual misalignments between the two fields. The computer communication, as whole, relies heavily on the fact that the network is stateless and on the ad-hoc and local resolution of the control decisions that have to be taken in ,order to eventually propagate the whole stream of data in an end to end fashion without errors. These were the very best assumptions made when designing it.
The~control system strategy, on the contrary, assumes the presence of the controller which makes centralized decisions for the whole process it controls. The assumptions made for the design of computer communication networks were more than satisfactory for the timeless transfer of data, and started to be a hindering as soon as this transfer related to the transfer of time sensitive data such as audio and video streams or to hard real-time communication processes such data storage in disaster times. Today, the idea of applying control methodology into the area of communications processes and protocols starts to get ground.
2.1 Application control Works related to the control of application resources can be found in [38], and in [39] one can find the conjecture about the analogy between the resource behavior in a communication network, related to QoS, and an automated control system controlling the level in a tank.
,~" 10 In order to guarantee an appropriate behavior of multimedia applications running ,.., over a computer communication network in [38] Baochun devised adaptive protocols in order to implement control strategies for compensating the variations of QoS
resource requests and consumption per host, per hop, and per network at the same time.
A
particular feature of the control strategies to be applied to these types of problems which has to be mentioned is that the communications processes do not impose hard real-time constraints. The control strategies explored span from using P1D controllers for controlling the resource requests and enabling process, to Kalman filters and eventually to fuzzy processes control techniques. The fuzzy control approach is a real contribution of the work done by the author. However, his research limited the area of control strategies to only OS of the host and to the control of resources managed at the host ,and at the application level, and although the word resource used within the scope of his document covered "network resources" (bandwidth, etc.) it was not specified how the control of such attributes on network devices would be materialized.
Another work in this area is a short paper of de Meer [39], where the author suggested an analogy between the level control processes and the allocation of resources in a QoS end-to-end communication. His work was inspired from another work of Alur et al. [43] in which the authors developed the paradigm of "water-level monitor"
for introducing and reasoning about continuous end-to-end QoS control.
Other works concentrate only on solving a centralized control problem to some local adjustment by using information or signaling from protocols such as RTP [45]
or others, though these attempts are not in the area of our exploits.
,~." 11 2.2 Network control A white paper of CISCO comes to establish a general strategy for implementing a network control infrastructure, especially for providing QoS sensitive applications with the guaranteed parameters and priorities [44]. The white paper argues for a centralized architecture which gives users and network managers the proper tools to interact with the network keeping at the same time the network in a very stable state. Instead of advocating ~, for a software which has the ability to signal QoS priority across the network, i.e.
"trusted" QoS controls, where users are responsible for conforming to QoS
policy when they launch certain applications, CISCO proposes to centralize QoS
implementation, removing the need for end-systems to police themselves and letting network managers set up and enforce the policy within the "trusted" network. It is also mentioned that the trusted and distrusted QoS control policies can be combined such that a consistent policy deployment and enforcement can be accomplished. In this way network managers can control network traffic and deliver mission-critical applications across the enterprise while still enabling traffic delivery for other applications. Despite the very solid positioning, in bringing some general points to the solution of the QoS
problem, the White Paper does not specify any methodology of achieving it in an engineering way.
Moreover, it targets specific next-generation CISCO elements that are qualified as "intelligent" and thus may not be applied to non-CISCO network elements even though:
they were QoS-capable.

due"

Another work in the area of network control can be found in [26]. In their paper, U.
Warrier et al. introduced a language for NM called Network Management Language (NML). This work is a thoughtful approach to network management and control, and is one of the few that explicitly stress the importance of network control in network management. Besides the nature and details of the language they introduce (an extension to the Structured Query Language that may be used under an embedded form in a regular programming language), this paper draws attention to the crucial role of an abstraction layer that sits between a MIXP (Management Information lExchange Protocol in the most .-general sense. SNMP and CMIP are two such MIXPs. Ire this Thesis, we will refer to them as control protocols) and an AU (Application Unit). NML would be such a layer that "reduces the gap between MIXP and application programmers", because the MIXP is a low-level communication protocol from the programmer point of view (even though CMIP is considered as an upper layer protocol in the OSI reference model).
Another '~ crucial advantage of the NML is that it can cope with multiple MIXPs transparently. 'The paper also formulates the requirements for a NML such as grouping of operands, procedural control facility and error handling, and finally a mapping from NML
to CMIP
is briefly presented. Although we share all the arguments presented in that paper, we find ~"' that using CMIP as a final MIXP is restrictive given that "solutions based on CMIP had been few and far between" [33]. NML is intended to use other MIXPs as well but they ~.p did not indicate how such mappings would be done. Adding support for another MIXP
may be costly and changes in the NML may require cascading and delicate implementation adaptations as well, which may limit the evolution of any NML
unless special care is given to design and implementation methods, for which a development ,~" framework for rapid implementation of control procedure:> is suitable -which we present in this Thesis. Finally, we reproach that performance considerations were completely absent in that paper and we argued previously how essential they are becoming today.
"The Tempest" is a network control framework developed in [46]. The authors of this paper propose a novel network control infrastructure driven by "the need for a single "~"
network supporting a large number of diverse services". First, they clarify what they consider as a blurred distinction between network management and network control;
"Management will be taken to refer to those functions concerned with the "well-being" of ~..
network devices, while control will refer to functions which try to manipulate network devices into doing something useful". Next, they define the paradigm in which they work: design and deploy control architectures function of desired services instead of thinking of how to achieve a desired service given the available control architectures. The core idea is the ability to control a switch with multiple (independent) controllers by ~, strictly partitioning the resources of that switch between the controllers.
Every such logical partition is called a switchlet and the set of switchlets possessed by a controller is called a virtual network. Accordingly, their infrastructure contains a component used to ~- divide a physical device into several logical ones (switchlets) so that distinct controllers can run multiple control architectures over the same physical node. Another required component in their infrastructure, called Caliban, adds a level of abstraction to the .
framework by exposing a small set of primitives which can be mapped to different underlying management protocols transparently. Therefore, controllers communicate with Caliban via those primitives instead of addressing switchlets directly.
Next; a Network builder module runs on top of the previous layers to actually specify and build virtual networks, and finally a control architecture endowed with basic building blocks is provided as a rich template for convenience. Once the infrastructure defined, this paper ,... explains the intent of it by further discussing the concept of service-specific control architectures (in particular): 1n summary, the desired service is the starting point and a control architecture is built to match the requirements of the service using Caliban's primitives and a virtual network. This was proposed as an alternative to the general purpose control architecture paradigm; a sort of one-size-fits-all solution that is arguably being abandoned.
Our understanding of network control ~ and management is compliant with their "" definition. We also find the service-specific control architecture principle interesting and adhere to it, as outlined in Section 4.1 (although our framework transcends this principle).
Their approach has numerous advantages, which include (but are not limited to):
""°' ~ Incrementable control architectures and architectures dedicated to a single service:
~., ~ Fine-grained access control policies can be implemented by the Caliban server.
Unfortunately, it also has some liabilities:
' We define network element control as the mechanism of sending a series of commands to an element in "., order to control its state. These commands are verified within a given formalism to be error free, and are endowed with transparent error handling features such that unpredicted NE
functional errors produce a roll back of the actions taken upon the NE thus leaving it in a consistent state.

~ The client controller is restricted to the set of control primitives offered by Caliban. An overhead in communication time can also be observed due the introduction of an additional indirection (acknowledged in the paper itself).
The described infrastructure targets ATM networks very specifically and some of the proposed techniques are not (yet) applicable to IP networks.
~ The service-specific approach allows service providers to customize their control architecture but requires them to actually write it and deploy it if it cannot be built with the basic building blocks. 'Therefore, this approach is only suitable for well-defined and common services.
In fact, the paper focuses on control architectures, not interfaces. More precisely, the control interface reflected by Caliban is fixed and later on control architectures are built on top of it: The control interface however remains fixed or typically rarely updated (compared to control architectures deployed over it that are intended to change more often). The Caliban thus seems, after all, to be another Tempest-specific form of a standard management protocol (or control interface) such as SNMP or CMIP, and ~. therefore it would encounter the same well-known problems, such as their being limited to a "common denominator" of functionality among heterogeneous network elements. It was explicitly acknowledged in their paper that -deployi.ng control architectures that would need specific switch features would be problematic with Tempest. As we argued. . .
earlier in this thesis, this inability to fully utilize the capabilities of a given network is an important obstacle.

The problem in Tempest is that only control architectures are customizable per-",~ service whereas Caliban's interface is service-unaware. What would fix the problem is .~.
Caliban's interface itself be service-dependant as well so that a different interface can be exposed to different controllers themselves providing for specific services.
Each of these ~., control interfaces would still map transparently to underlying NE control primitives. The difference is that since the interface is customizable per-service, the full range of NE
capabilities can be reached. Our framework allows flexible control interfaces to be designed seamlessly. Our work remains, however, more modest than Tempest in certain aspects since we do not define a global virtual networking architecture for example.
2.3 Net~rvork management Most work in NM found in the literature deals with network management -in contrast with element control - and only a few of the previous efforts explicitly refer to NE control.
Artificial intelligence was applied to network management several times in the past.
One can find applications of expert systems' in introducing semi-automation mechanisms !"" for network management in [24] and [25]. These mechanisms allow intelligent network fault management, network configuration validation, performance monitoring methods, Expert systems are used in the field of Artificial Intelligence (AI) to separate the knowledge base from the reasoning engine. They are used in the industry as decision-makers in situations such as train routing, etc.

etc. It is not our goal to discuss the quality of these papers. However, it has to be mentioned that while the former barely mentioned CMIP as a final control protocol, the latter left it unspecified and both papers do not indicate how abstract operations used in the rule base at the expert system level would be mapped to concrete control commands in a transparent and uniform way. Actually, they both assume the existence of a standard control protocol which makes us believe that SNMP or CMIP were implicitly targeted.
Using the latter wo protocols for element control (although they are indispensable for management) has at least two limitations: a) performance (see Chapter 5) and b) inability to manage non-standard features residing in Enterprise MIBs (since a common-denominator approach is usually adopted).
Ku et al. [36] focus on intelligent NM for gigabit routers. They propose a Java-based architecture (for platform independence) that consists of a complex server acting as a manager on behalf of a human manager GUI applet. The server contains several collaborating engines ~FCAPS). In particular, the engine responsible of submitting configuration changes to the routes uses importlexport to download/upload configuration files from the routes. More specifically, in order to perform a configuration task, a) a configuration file residing on the muter is downloaded to the server (the manager), b) it is imported to some format, c) configuration is made upon the imported file, d) the file is exported to the router's format and finally e) the configuration file is uploaded to the routes. This approach has several liabilities:
~ It requires a downloadlupload for each and every configuration. This operation is typically slow.

sew ~ It requires previous knowledge of the internal format in which the router stores its own configuration. This format is not always provided by the manufacturer of the muter or NE in general.
~ Assuming that the previous format is known, this approach requires implementing a parser for that format, which might be a tedious task. This affects the extensibility of the architecture since it makes the integration of a new router platform a difficult mission.
~ Uploading a configuration file to a router may require rebooting the °°" machine. The resulting interruption of service is usually undesirable.
Although we find that the global architecture they propose is interesting, due to the above limitations the resulting performance is poor. It is measured to 12 seconds for each import/export cycle. While configuration processing can generally be done efficiently offline and then submitted to the router, it can be anticipated that in the scenario described in the 'previous section configuration requests will typically be numerous and involve small incremental NE-configuration changes. Therefore, the benefit that might be obtained from offline processing is diluted by a relatively large delay required to importlexport a router's configuration file. Their architecture could have better ~,., performance if the importlexport module were replaced by an efficient implementation providing the same services to the upper layer in a vendor-independent manner.
Our.
framework is designed to allow this facility.

An original approach is introduced by Do-Hyeon Kim et al. in [35]. Their work aims at managing heterogeneous networks with a novel architecture that uses an application program interface and lower layer managers. The proposed architecture is compared to traditional ones such as manager-of managers and common platform ,~ '' architecture and is arguably interesting. We find, however, that the main contribution of their work resides in the fact that a clear separation between managing LANs and WANs ~'~- is made. This decision cam for along the "reality" factor into account, that is, the fact that most network management systems employed in LANs and WANs had been developed separately; LAN resources are usually managed in a standard way using ,, SNMP, and WAN resources are managed using proprietary protocols and only a few devices support CMIP. Accordingly, their integrated management architecture uses LAN
managers and WAN managers that transparently handle different protocols to provide a consistent interface. However, network control is very briefly mentioned regarding LAN
"" managers and SNMP is the used protocol; which have limitations that we mentioned above. Furthermore, no mechanism for mapping higher-level API operations to proprietary APIs is discussed and we find that too much attention is given to graphical user interface details.
Subjects in [27-30~ treat mainly of web-based interfaces that have become very trendy in NM. We will not detail much in this section because it would be rather irrelevant. In summary, these documents mostly outline the benefits of web=based NM, and propose different architectures to implement web-based management.
However, it is important to mention that they are all concerned with providing an end-user interface that ~,-eww is suitable for "manual" management: In other terms, these web-based interfaces were not ,~" meant to be used by any sort of control automation engine. This is clearly a limitation in the numerous scenarios where automated control is desired.
2.4 Other related work 2.4.1 A pattern system for network management interfaces Bochmann et al. [22] introduced an interesting pattern system for the builders of network management interfaces (NMI): They also developed a framework called "Layla"
that supports that system of patterns. Some of the patterns introduced in their paper are the Manager-Agent pattern and the Managed Object pattern. In the Manager-Agent pattern, the Agent (that can also be a manager' for other subagents) is usually the one ""' responsible of direct element management, this management being achieved through Managed Objects. The set of Managed Objects contained within a given Agent ,.~
constitutes the Management Information Base (MIB) of that Agent. One of the major advantages of Agents is that they provide a uniform interface to the Manager so that specific resource details are hidden.
Within the scope of their framework, our development framework would serve as a base to implement NE control operations in Managed Objects. Managed Objects would reflect a set of uniform (vendor-independent) interfaces to ,Agents. The details hidden by those interfaces are handled automatically by an application implemented within our .

mw framework using CLI interaction. Note that the fact that they use CMIP as a higher-level management protocol is not a problem here. The interface used for network management is orthogonal to our work, although its choice may affect overall runtime performance.
Note, finally, that a control portion implemented with our system can coexist with another implementation (say using SNMP) responsible of other management tasks, the whole functionality being hidden behind uniform Managed Object interfaces.
2.4.2 The "Expect" Toolkit "Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc." [14]. "Expect" is a popular tool that provides a scripting language ""' for automating terminal-based interactive programs. It basically spawns a process running the program to automate, sends textual commands to it and reads its textual output. That output is "analyzed" and appropriate actions are undertaken if the response is "expected". In-fact, it follows the scenario below:
a) Send a textual command to the terminal, b) Expect a certain number of replies, wait until an "expected" response is ~..
received, or timeout.
c) According to the result of the previous action, execute a certain action just like in a) and continue through b), etc.
In step b), the expected responses from the terminal are represented by regular . .
expressions [10, 12] to specify text patterns. According to the regular expression matched by the received response, a certain value is returned and the script author decides on the : .

next action according to that result. A timeout value can also be specified in order to exit the waiting loop if no pattern is matched after a certain time. Timeouts are useful to handle error situations for example.
Expect is powerful and used by many other popular utilities, such as DejaGnu [15].
Unfortunately, it suffers many drawbacks:
~~ - Yet another scripting language to learn.
- Embedded statements become very complex to read and understand. Embedded statements occur when complex interaction -involving loops for example- is to be described in Expect. Many undesirable "goto-like" statements become necessary. The verification of the script becomes tedious and moves the writer away from the main objective: to ensure correct interaction that might already be complicated enough.
- Some advanced -however indispensable- features are not supported by Expect.
For example, one cannot keep checking against a certain pattern for a whole session (or generally for more than one send-receive interaction) unless the ?~"~ pattern is re-submitted every time. This can reveal problematic in same cases discussed in Section 5.2. Our approach efficiently addresses this issue, as explained in Section 5.3.
- Expect is limited to regular expressions, which can only parse regular languages' [11]. Languages like XML are not regular languages. If the output is XML, it "~ 23 cannot be parsed with Expect. Our implementation supports extensibility to parse any desired NE output format.
Drawing a state diagram on a paper is natural and much easier and clearer than writing a script. By using graphical design with UML state diagrams, one can see clearly ,~" the logic followed by the state machine. This is why we argue that a UML-based approach is more suitable than a scripting language -at least for that reason.
"Expect" was not designed for uniform control of heterogeneous network elements, and reveals insufficient to handle complex and reliable CLI automation with NEs.
However, the idea of using regular expressions to trigger subsequent actions is a good starting point. We develop a more complete model suitable for uniform NE
control using CLI. The presented framework makes extensive use of real-time and object-oriented ,~,,, concepts that greatly facilitate implementation of new automated CLI
operations in a graphical environment.
We propose a distributed and centralized (from the network point of view the two are not antagonist) architecture which can supervise the network and control according to some control rules the network elements. This thesis deals with and presents a solution to what in [44] is called a "very complex task due to the many different network elements and to the many parameters required to successfully deploy and implement a QoS
policy °"'" end to end". We .do not define specific services or policies (such as QoS end-to-end).
Instead, we define a development framework that would allow rapid and efficient design and implementation of uniform network element control. This is what we call the horizontal deployment of the network control environment be it for providing QoS or any other service in the network. Our framework provides means for developing element control applications that provide uniform control interfaces. The obtained performance is superior to what has been achieved so far. Flexibility in element control is improved as well because no assumption is made regarding the nature of the uniform interface provided to the upper layer. It can be customized on a per-application basis according to the targeted NE categories and the service to be provided. Enterprise MIBs from multi-vendor NEs can thus be controlled provided that they offer a common desired functionality even if the interface to that functionality is not standardized by an existing NM protocol.

sr.°~
3 Background:
SOAP, WSDL, Regular expressions and UML
This chapter presents an overview of the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), mathematical results in the field of regular expression matching, and the Unified Modeling Language (UML). Because UML
components and state diagrams are both the application environment and the foundation of many concepts proposed in this thesis, UMI, is reviewed in reasonable detail and emphasis is laid upon UML's real-time aspects. SOAP and WSDL are. reviewed to justify their choice: as the middleware for the web-based architecture of the framework.
Mathematical results related to regular expressions and finite automata are reviewed as well to demonstrate their efficiency since they are used in the implementation of the final prototype.
This chapter can be skipped if the reader is already familiar with SOAP, WSDL, regular expressions and finite automata theory,- and UML real-time concepts and semantics.
,., 26 3.1 The Simple Object ACCess Protocol (NB: This section is inspired in part from [4] and [5]. For more about SOAP, please refer to [3-5]).
3.1.i Introduction For the most part, software component developers from opposite sides of the tracks stay as far away from each other's technology as possible. This polarity makes it difficult to achieve any level of interoperability. It would be great to find a component technology standard that everyone could agree on. It could be that a subset of minimal technologies '' is the best answer to this quandary.
XML and HTTP are two such minimal technologies. The Simple Object Access - Protocol (SOAP) defines the use of XML and HTTP t~ access services; objects;
and servers in a platform-independent manner. SOAP is a protocol that acts as the ,~hie between heterogeneous software components. If developers can agree on HTTP and XML, SOAP offers a mechanism for bridging competing technologies in a standard way.
The industry has accepted HTTP. It's used everywhere, on all platforms. XML is becoming as ubiquitous as HTTP. This ubiquity makes HTTP a good choice for an interoperable transport mechanism.
XML is a simple and extensible text markup language. Because XML is just text, any application can understand it as long as the application understands the character H , encoding in use.

Combining HTTP and XML into a single solution provides a whole new level of interoperability. For example, lathered with SOAP, clients written in Microsoft Visual Basic can easily invoke CORBA services running on UNIX boxes, JavaScript clients can easily invoke code running on the mainframe, and Macintosh clients can start invoking Perl objects running on Linux. The list goes on. While some interoperability is achieved today through cross-platform bridges for specific technologies, once SOAP
becomes standard, bridges will no longer be necessary.
SOAP is not an entirely new concept; it attempts to codify the main concepts behind existing practices into a simple and generic protocol that can serve as an industry standard.
SOAP can tae used in combination with a variety of existing Internet protocols arid formats including HTTP, SMTP, and MIME. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics;
rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules, which allows SOAP to be used in a Iarge variety of systems ranging from messaging systems to RPC.
Also, SOAP doesn't attempt to address the more complicated distributed object protocol services such as object activation, marshaling objectslreferences, garbage collection, or bi-directional communications. SOAP doesn't prohibit the use of any of these services; they are simply implementation details that can be layered on top of the x SOAP protocol.

Finally, although SOAP can be made easier to use through natural language "~, bindings, SOAP does not mandate an API of any kind; a language binding is strictly an implementation that makes SOAP more accessible and easy to use.
[Note: Although SOAP can be used in combination with virtually any transport protocol, it was originally designed to be layered on top of HTTP. Actually, the W3C
SOAP specification [1] mandates specific SOAP to HTTP bindings to stress the importance of using SOAP over HTTP. This point is so crucial that SOAP is sometimes -abusively- considered to be limited to HTTP. The specification also -defines a representation of RPC calls within SOAP. Note that using SOAP for RPC is orthogonal to the SOAP protocol binding (i.e. arthogonal to the transport protocol layered underneath SOAP).]
HTTP Header SOAPAction SOAP-ENV:EnVelope Header Element SOAP-ENV:Header Header Element SOAP-ENV:Body Method Call Element ~:a Figure 3-1: simplified SOAP-RPC packet layout (adapted from [5]).

Below is an example of SOAP/HTTP request used for RPC. Note how intuitive and simple is the syntax used to describe the request.
POST /bookSeat HTTP/1.1 Host: localhast:8080 Content-type: text/xml; charset=UTF-8 Content-length: XXX
SOAPAction:"/bookSeat"
<SOAP=ENV:Envelope xlns:xs="http://www.w3.org/19991XMLSchema"
x.:Ln:>:xNi.="http://www.w3.org/1999/XMLSchema-instance"
xr~~..ns:SOAP-E_FTC="http://schemas:xmlsoap.org/soap/encodingl"
xmlria::~0n~--F'aV="http: //schemas:xmlsoap.org/soap/envelope/"
:3~.AP-E~TC.T:er:c.odingStyle="http: //schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<Source ~'aluG="MIRLab"/>
<:SOAP-ENV:Header>
< SCWP- E NV : Body>
<rsl :bookSeat x~r,lns:n~1="http://localhost:8080/bookSeat">
<.seat xsi:typF="xsd:int">

<iseat>
</ra1: bookSeat>
< / S7AP-El~.~I : Body>
</SOAP-ENV:Envelope>
The "Body" part (called SOAP-ENV : Body) contains the method call element. In the example above, the method invoked is bookSeat with an argument called seat (of type xsd: int, that is, an integer).
3.1.2 Firewall issues Currently, developers struggle to make their distributed applications work across the Internet when firewalls get in the way. Since most firewalls block all but a few ports, such as the standard HTTP port 80, all of today's distributed object protocols like DCOM
",~ and CORBA suffer because they rely on dynamically assigned ports for remote method invocations. If the network administrator can accept to open a range of ports through the ,.:
firewall, then it may be possible to get around this problem as long as the ports used by ,, the distributed object protocol are included.
To make matters worse, clients of the distributed application that lie behind another corporate firewall suffer the same problems. If they don't configure their firewall to open the same ports, they won't be able to use the application. Making clients reconfigure their firewalls to accommodate to an application is just not practical.
When SOAP is used in combination with HTTP as the transport mechanism, and since most firewalls allow HTTP to pass through, there will be no problem invoking SOAP endpoints from either side of a firewall.
3.'1.3 SOAP and Security SOAP being a wire protocol, it does not implement security. However, SOAP can use the HTTP protocol, allowing the use of application-level security coupled with secure sockets or HTTPS. SOAP also mandates the use of the SOAPAction HTTP header field (see Figure 3-1 and the SOAP request example), which allows firewalls (or equivalent technology) to filter SOAP method invocations or deny SOAP processing entirely. The firewall would examine the SOAPAction header and filter the SOAP packet based upon the object name, the particular method (remotable or not), or a combination of the two f51.

,"""
Besides the firewall security benefits of designing SOAP using extended HTTP
headers, the SOAP specification does not define any protocol-specific security features.
SOAP may simply utilize any security feature offered by the transport protocol or any endpoint application-specific security feature.
3.2 Web Services Description Language (NB: Sections 3.2.1 and 3.2.2 are mostly extracted from [7]).
3.2.1 Introduction: Web Services Defined A Web Service is programmable application logic accessible using standard Internet ;;, protocols. Web Services combine the best aspects of component-based development and the- Web. Like components, Web Services represent black-box functionality that can be reused without worrying about how the service is implemented. Unlike current component technologies, Web Services are not accessed via object-model-specific protocols, such as the Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, Web Services are accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML). Furthermore, a Web Service interface is defined strictly in terms of the messages the Web Service accepts and generates. Consumers of the Web Service can be implemented on any platform in any programming language, as long as they can create and consume the messages defined for the Web Service interface.
3.2.2 Web Services related protocols There are a few key specifications and technologies that are likely to be encountered when building or consuming Web Services. These specifications and technologies address five requirements for service-based development:
~ A standard way to represent data ~ A common; extensible, message format ~- ~ A common, extensible, service description language o A way to discover services located on a particular Web site ~ A way to discover service providers XML is the obvious choice for a standard way to represent data. Most Web Service-related specifications use XML for data representation, as well as XML Schemas to ~"; describe data types.
SOAP (introduced in Section 3.1 above) defines a lightweight protocol for information exchange. Part of the SOAP specification defines a set of rules for how to ~'" use XML to represent data. Other parts of the SOAP specification define an extensible.
message format, conventions for representing remote procedure calls (RPCs) using the SOAP message format, and bindings to the HTTP protocol.

Given a Web Service, it would be useful to have a standard way to document what messages the Web Service accepts and generates-that is, to document the Web Service contract: A standard mechanism makes it easier for developers and developer tools to create and interpret contracts. The Web Services Description Language (WSDL) is an XML-based contract language jointly developed by Microsoft and IBM. It will be further discussed in Section 3.2.3 below.
Developers will also need some way to discover Web Services. The Discovery Protocol (Disco) specification defines a discovery document format (based on XML) and a protocol for retrieving the discovery document, enabling developers to discover services at a known URL.
However, in many cases the developer will not know the URLs where services can be found. Universal Description, Discovery, and Integration (UDDI) specifies a mechanism for Web Service providers to advertise the existence of their Web Services and for Web Service consumers to locate Web Services of interest.
In the context of the present work, service discovery and service provider discovery was not used nor was it necessary anyway. Indeed, the services provided by the application were not meant to be advertised for everyone but rather for users who have previous knowledge of the existence of the service. Therefore, we will only focus on WSDL in the rest of this section. Disco and UDDI were referred-to above on an informational basis only.

3.2.3 WSDL
~'" Over the past year Microsoft and IBM have proposed several contract languages:
Service Description Language (SDL), SOAP Contract Language (SCL), and Network Accessible Services Specification Language (NASSL).
Web Services Description Language (WSDL) is a more mature evolution of all a., these. It consolidates the efforts and ideas present in those previous attempts; for example, SCL was designed specifically for SOAP whereas WSDL has been designed such that it can express bindings to protocols other than SOAP. The .purpose of this section is to introduce WSDL and explain how it contributes in facilitating the use of SOAP.
As outlined previously, a language that describes the capabilities of Web Services (SOAP web services, in particular) -by providing a description of the messages a Web service is able to send and receive- is needed.
It has been argued that SOAP does not really need an interface description language to go with it. If SOAP is a standard for communicating pure content, then it needs a language for describing that content. SOAP messages do carry type information, and so SOAP allows for dynamic determination of type. But a function cannot be called correctly unless its name, the number of parameters and the types of each are known.
'~'" Without WSDL, one can determine the calling syntax from documentation that must be .
provided, or by examining wire messages. Either way, a human will have to be involved, and so the process is prone to error.

Other than describing web services to clients, with WSDL, one can automate the generation of proxies for Web services in a truly language- and platform-independent way. Like the II?L file for COM and CORBA, a WSDL file is a contract between client and server In fact, for every SOAP-RPC call, the call data is marshalled into a SOAP
message, sent over the Internet (using HTTP for example), de-marshalled orr the server side and finally dispatched to the right entity (the response follows the same logic).
Tn practice, however, this task is not done explicitly by the programmer for each SOAP-RPC
call, since it would clearly affect the readability of the code and the scheme is prone to error.
Instead, this task is usually handled by a set of proxy classes -called client stubs and server s;celetons- that are automatically generated by a WSDL compiler in some programming language such as JavaTM or C++. These classes implement the marshalling and de-marshalling functions, which are transparently called every time an RPC
call is ~'"" made.
,, By doing this, writing the client/server code becomes much easier since a SOAP-RPC call will have exactly the same syntax as a local method invocation. Note also that client stubs and server skeletons may be written using different programming languages.
Actually, since SOAP is XML based, it offers a high level of interoperability between heterogeneous software components. SOAP endpoints do not need to assume anything about the programming language other SOAP endpoints are written in. The only binding between the different endpoints consists in the abstract WSDL interface common to them, reducing coupling to its minimum.
Again, the above scheme is not a new idea specific to WSDL or SOAP; in fact, it has been used in software development for a long time. For example, the CORBA
Interface Description Language (IDL) plays the same role as WSDL. Most CORBA
implementations contain an IDL compiler (code generator) that maps the IDL
interface into a natural programming language. Stub and skeleton classes are created by the compiler, and the programmer only has to use them to invoke distributed services ~,, transparently.
Note, finally, that the SOAP layer does not have to be reflected under the form of a client stub and a server skeleton. It is just one common way, in software development, to implement RPC to SOAP mapping, and more generally services provided by a middleware such as CORBA or DCOM. The SOAP layer can be implemented by any other means provided that the consistency of the SOAP-RPC messages is preserved.
We will intentionally neglect, within this section, other WSDL-related details such as document structure and language bindings since it: would make the section unnecessarily heavy. For more about WSDL, please refer to [6-9].

3.3 Regular Expressions and Kleene's Theorem The purpose of this section is to review mathematical results related to the use of finite automata in regular expression matching, given that the final implementation of our framework relies in part on it.
Classical mathematical definitions about regular languages, regular expressions and finite automata are first reviewed. Next, I~leene's theorem -stating equivalence in a very precise sense between regular expressions and finite automata- is reviewed.
Proofs of the reviewed theorems are omitted in order to keep this section as light as possible, but these proofs can easily be found in literature (10-13].
3.3.x! Regular. languages A language is a set of strings of symbols. Formal languages are characterized by grammars whichvare essentially a set of rewrite rules for generating strings belonging to a language. Regular languages are just a specific kind of formal languages.
3.3.1.1 Basic definitions An alphabet is a finite set of symbols. { 0, 1 } is an alphabet and { a, b }
is another.
The set of ASCII characters is also an alphabet. A word is a finite sequence of symbols of a given alphabet. _ .
A language is a set of words (possibly infinite) over a given alphabet: {a;
ab, abba}
is a language (over the alphabet { a, b }). The English language is a language in the sense of the above definition over the alphabet { a, b, . . ., z, A, B, . . . , Z }
. The number of .~. symbols in a string is called the length of the string. For a string w its length is represented by Iwl. The empty string (also called null string) is the string with length 0, that is, it has no symbols. The empty string is denoted by t1 (capital lambda). Thus IAI=0.
The empty set Q~ is a language which has no strings. The set {t~} is a language which has one string, namely A. For any alphabet E, the set of all strings over E
(including the empty string) is denoted by ~*. Thus a language over alphabet E
is a subset of E*.
3:3.1.2 Operations on languages Since languages are sets, all the set operations can be applied to languages.
Thus the union, intersection and difference of two languages over an alphabet E are languages over E. The complement of a language L over an alphabet E is E*- L and it is also a language.
Another operation on languages is concatenation. Let L1 and L2 be languages.
Then the concatenation of LI with L2 is denoted as L1L2 and it is defined as L1L2 _ { uv I uE Ll and vEL2}. That is L1L2 is the set of strings obtained by concatenating strings of Ll with those of L2. For example { ab, b } { aaa, abb } _ { abaaa, ababb, baaa, babb }
.

Recursive definition of L*:
Basis Clause: t1E L*.
Inductive Clause: For any xL* and any wE L, xwE L*.
Extremal Clause: Nothing is in L* unless it is obtained from the above two clauses.
Theorem: L* is the set of strings obtained by concatenating zero or more strings of L.
This * is called HIeene star. (proof is omitted).
*w"
For example if L = { aba, bb }, then L* _ {A, aba, bb, ababb, abaaba, bbbb;
bbaba, ... } .
The * in E* is also the same HIeene star defined above.
"~°' Definition of L+: L+ = LLM = L*L.
Thus L+ is the set of strings obtained by concatenating one or more strings of L.
For example if L = { aba, bb }, then L+ _ { aba, bb, ababb, abaaba, bbbb;
bbaba, ... }
Definition of Set of Regular Languages:
Basis Clause: ~, {A} and {6} for any symbol E are regular languages.
Inductive Clause: If L,. and LS are regular languages, then L,.vLs, L,.LS and L,.* are regular languages.
Extremal Clause: Nothing is a regular language unless it is obtained from the above two clauses.

For example, let E= { a, b } . Then since { a } and { b } are regular languages, { a, b } ( _ { a } v { b } ) and { ab } ( _ { a } { b } ) are regular languages. Also since { a } is regular, { a } * is a regular language which is the set of strings consisting of a's such as A, a, aa, aaa, aaaa etc. Note also that E*, which is the set of strings consisting of a's and b's;
is a regular language because { a, b } is regular.
3.3.2 Regular expressions Regular expressions are used to denote regular languages. They can represent """' regular languages and operations on them succinctly.
The set of regular expressions over an alphabet ~ is defined recursively as below.
Any element of that set is a regular expression.
-.»~, Basis Clause: ~, A and a are regular expressions corresponding to languages ~, {A}
and ia~, raspectively, where a is an element of E.
Inductive Clause: If r and s are regular expressions corresponding to languages L,. and LS, then (r + s) , (rs) and (r*) are regular expressions corresponding to languages L,.uLs , L,LS and Lr* , respectively.
Extremal Clause: Nothing is a regular expression unless it is obtained from the above two clauses.
,~;: 41 Conventions on regular expressions (1) When there is no danger of confusion, bold face may not be used for regular expressions. So for example, (r + s) is used instead of (r + s}.
(2) The operation ~ has precedence over concatenation, which has precedence over union (+). Thus the regular expression (a + (b (c*})) is written as (a + be*), (3) The concatenation of k r's, where r is a regular expression, is written as rk. Thus .:...
for example rr = r2.
(4) VVe use (r+) as a regular expression to represent L,.+.
Examples of regular expression and regular languages corresponding to them:
(a + b)' corresponds to the language { aa, ab; ba, bb } , that is the set of strings of length 2 over the alphabet { a, b } . In general (a + b)k corresponds to the set of strings of length k over the alphabet { a, b } . (a + b)* corresponds to the set of all strings over the alphabet { a, b } .
;,.~ ~ a*b* corresponds to the set of strings consisting of zero or more a's followed by zero or more b's.
~ a*b+a* corresponds to the set of strings consisting of zero or more a's followed by one or more b's followed by zero or more a's.
~ (ab)+ corresponds to the language { ab, abab, ababab, ... }, that is, the set of stxings of repeated ab's.
~.

~ With the notation @ _ (a+b+...+z+A+...+Z+' ') (i.e. a letter from the English alphabet or a white space), (@*hello@*) denotes the set of all phrases over the English alphabet containing the word 'hello'.
Note: A regular expression is not unique for a language. That is, a regular language, in general, corresponds to more than one regular expression. For example (a +
b)* and (a*b*)* correspond to the set of all strings over the alphabet ( a, b } .
Regular expressions are equal if and only if they correspond to the same language Thus for example (a + b)* _ (a*b*)*, because they both represent the language of all strings over the alphabet ( a, b }
Note: In general, it is not easy to see by inspection whether or nvt two regular expressions are equal.
3.3.3 Finite automata Definition: A model of computation consisting of a finite set of states, a start state, an input alphabet, and a transition function which maps input symbols and current states to a next state. Computation begins in the start state with an input string. It changes to new states depending on the transition function. There are many variants, for instance, machines having actions (outputs) associated transitions (Mealy machine) or states (Moore machine), multiple start states, transitions conditioned on no input symbol (a , null) or more than one transition for a given symbol and state (non-deterministic finite state machine), one or more states designated as accepting states (recognizes), etc. [12).

3.3.3.1 Deterministic finite automata ~- Definition: Let Q be a finite set and let E be a finite set of symbols.
Also let 8 be a function from Q x S to Q, Iet qo be a state in Q and let A be a subset of Q.
We call the elements of Q states, 8 the transition function, qo the initial state and A
the set of accepting states. Then a deterministic finite automaton (DFA) is a 5-tuple ~..: <Q, E, qo, 8, A>.
,~" Notes on the definition:
1. The set Q in the above definition is simply a set with a finite number of elements.
Its elements can, however, be interpreted as a state that the system (automaton) is in. Thus in the example of a vending machine, for example, the states of the machine such as "waiting for a customer to put a coin in", "have received 5 cents"
etc. are the elements of Q. "Waiting for a customer to put a coin in" can be considered the initial state of this automaton and the state in which the machine gives out a soda can be considered the accepting state.
2. The transition function is also called a next state function meaning that the automaton moves into the state 8 (q, a) if it receives the input symbol a while in state q. Thus in the example of vending machine, if q is the initial state and a nickel is put in, then 8 (q, a) is equal to "have received 5 cents".
3. The accepting states are used to distinguish sequences of inputs given to the finite automaton. If the finite automaton is in an accepting state when the input ceases to come, the sequence of input symbols given to the finite automaton is "accepted". Otherwise it is not accepted. For example, in the example of Figure 3-2, the strings as and aabb is accepted by the finite automaton. But any other strings such as ab, abb, etc. are not accepted.
b 0 a 1 a Figure 3-2: an example of a deterministic finite automaton (DFA).
Q = {0;1, 2}, E = {a, b}, A = {2}, qa = 0, S shown in Table 3-1 below.
State (q) Input (6) Next state ( 8 (q, a) ) 0 a 1 1 a 2 2 b 2 Table 3-1: transition table of the DFA of Figure 3-2.
DFAs are often represented by digraphs called (state) transition diagrams. The vertices (denoted by single circles) of a transition diagram represent the states of the DFA
~.", and the arcs labeled with an input symbol correspond to the transitions. An arc (p, q) from vertex p to vertex q with label a represents the transition b (p, a) = q.
The accepting states are indicated by double circles. Transition functions can also be represented by tables as seen above. They are called transition table.
Note that the behavior of the above DFA is not defined when the DFA is in state 1 and receives the input b, for example. This DFA is said to be incomplete. In this case, we consider that the DFA blocks when it receives an unexpected input and subsequent input symbols are not processed. When 8 is defined for each couple (q, a) E Q x E, the DFA is said to be complete.
Definition of S*:
Basis Clause: For any state q of Q, cS* (q, A) = q, where A denotes the empty string.
Inducitve Clause: For any state q of Q, any string yE E* and any symbol 6 E
E*, *(q~ Y6) = S (~* (q~ Y)~ 6)~
In the definition, the Basis Clause says that a DFA stays in state q when it reads an empty string at state q and the Inductive Clause says that the state DFA
reaches after reading string ya starting at state q is the state it reaches by reading symbol a after reading string y from state q. This definition will be used below to formally define the notion of "acceptance" by a DFA.
A string w is accepted by a DFA <Q, E, qo; 8, A> if and only if 8*(qo, w)E A.
That is, a string is accepted by a DFA if and only if the DFA starting at the initial state ends in an accepting state after reading the string.

A language L is accepted by a DFA <Q, E, qo, 8, A> if and only if L = {w I 8*(qo, w) E A }. That is, the language accepted by a DFA is the set of strings accepted by the DFA.
For example, it can be easily observed that the DFA of Figure 3-2 accepts the ~:.
language characterized by the regular expression aab*.
3.3.3.2 Non-deterministic finite automata Definition: Let Q be a finite set and let E be a finite set of symbols. Also let 8 be a function from Q x E to ~(Q) 1, let qo be a state in Q and let A be a subset of Q. We call the elements of Q states, 8 the transition function, qo the initial state and A
the set of accepting states. Then a non-deterministic finite automaton (NFA) is a 5-tuple <Q, E, qo~ b, A>.
Notes on the definition 1. As in the case of DFA the set Q in the above definition is simply a set with a finite number of elements. Its elements can be interpreted as a state that the system (automaton) is in.
2. The transition function 8 is also called a next state function. Unlike DFAs an NFA moves into one of the states.given by b (q, 6) if it receives the input symbol ~(X) denotes the set of subsets of X. It is also called the power set of X.

6 while in state q. Which one of the states in S (q, a) to select is chosen non-,..., deterministically.
3. As in the case of DFA the accepting states are used to distinguish sequences of inputs given to the finite automaton. If the finite automaton is in an accepting state when the input ends, i.e. ceases to come, the sequence of input symbols given to the finite automaton is "accepted". Otherwise it is not accepted.
4. Note that any DFA is also a NFA.
b a Figure 3-3: an example of an NFA.
Q = {0, 1, 2}, E = {a, b}, A = {2}, qo = 0, 8 shown in Table 3-2 below.
State (q) Input (a) Next state ( 8(q, a) ) 0 a { 1, 2}

b ~

1 a ~

{0, 2}

~ 48 --2 a QS

2 b {2}

Table 3-2: transition table for the NFA of Figure 3-3.
As in the case of DFAs, the definition of language acceptance for NFA relies on the definition of 8* which is slightly different for NFAs.
For a state q and a string w, 8~ (q, w) is the set of states that the NFA can reach when it reads the string w starting at the state q. In general an NFA non-deterministically goes through a number of states from the state q as it reads the symbols in the string w. Thus for an NFA <Q, E, qo, S, A>, the function 8* : Q x E ~ ffD(Q) is defined recursively as follows:
Definition of S*:
Basis Clause: For any state q of Q, 8* (q, A) _ {q}, wherf; A denotes the empty string.
'°-" Inductive Clause: For any state q of Q, any string yE E* and any symbol 6E ~, ~ * (q~ y6> -PES*(9,Y>
In the definition, the Basis Clause says that an NFA stays in state q when it reads an empty string at state q and the Inductive Clause says that the set of states a NFA can reach after reading string ya starting at state q is the set of states it can reach by reading symbol 6 after reading string y starting at state q.

We say that a string xE ~* is accepted by an NFA <Q, E, qo, 8, A> if and only if d*(qo, x) n A is not empty, that is, if and only if it can reach an accepting state by reading x starting at the initial state. The language accepted by an NFA <Q, E, qo, 8, A> is the set of strings that are accepted by the NFA.
Example:
Considering the NFA of Figure 3-3, we are going to "run" it with the input string x = aba, that is, calculate 8*(0, x).
8* (0, aba) is the union of S(q, a) for q E b M (0, ab) according to the Inductive Clause.
Now 8* (0, ab) is the union of b (q, b) for q E 8* (0, a) according to the same clause.
Again 8* (0, a) is the union of b (q, a) for q E 8* (0, A) according to the same clause.
However S* (0; A) _ {0} according to the Basis Clause.
Hence 8* (0, a) = 8 (0, a) _ { 1, 2} (see Table 3-2).
Hence 8* (0, ab) = 8 (l, b) a 8 (2, b) _ {Q; 2}.
Hence 8* (0, x) = 8* (0, aba} = 8 (0, a) a 8 (2, a) _ { 1, 2}.
The conclusion of this calculus is that the states that can be reached by the NFA
when inputting x are 1 and 2. Since 8* (0, x) n A = { 2 } ~ QS, x is accepted by the NFA.
3.3.3.3 Non-deterministic finite automata with A-transitions These FAs are noted NFA-A. They are similar o NFAs except that some transitions may have A as an associated symbol. l1-transitions are taken without affecting the symbol input stream, that is, the reading head doesn't move when a A-transition is taken.

We will not discuss NFA-A in further detail since it would make this section ,~, unnecessarily heavy. They have been mentioned here for completeness only.
Note, nonetheless, that every NFA is an NFA-t~.
3.3.3.4 Equivalence between DFA, NFA and NFA-t1 Theorem: Let L be a language. The following propositions are equivalent:
1. There exists a DFA that accepts L.
2. There exists a NFA that accepts L.
3. There exists a NFA-A that accepts L.
In other words, the different sorts of automata introduced previously have the same computation power. Using one or another is thus just a matter of convenience to the situation where they are used. There are also well-known algorithms to convert between ~., any two kinds of~FAs (omitted here).
3.3.4 Kieene's theorem Theorem (part 1 of Kleene's theorem):
Any regular language is accepted by a finite automaton.
Outline of the proof: We are not going to give a detailed proof of the above theorem.
Nonetheless, the outline of the proof is worth to be mentioned. Note that the theorem doesn't specify a particular kind of FAs because of the equivalence theorem stated in the : .

previous section. The proof, however, uses NFA-A because of their convenience and flexibility. In fact, the proof follows a recursive logic just like the recursive definition of regular expressions. Indeed, the theorem is easy to prove for the base cases, i.e. when the regular expression in question is either QS, A, or a symbol 6E E (basis cases). Next, an '"'" inductive construction of the FA is made according to the first-level decomposition of the regular expression r, so whether it is of the form ryr2, rl+r2, or r~*, the built FA is the concatenation of FAQ (r,) and FA2 (r2), the union of FAQ and FA2, or the Kleene star of FAQ, respectively.
Part 2 of Kleene's theorem is the converse of part 1, that is, languages accepted by FAs are regular. We did not emphasize on it because we only use the transformation property from a regular expression to a finite automaton, not its converse:
The advantage of using the above result as that it is very suitable for stream-based parsing, which is what we will need later. Actually, an FA "consumes" the symbols (characters in the case of a Telnet/SSH client reading NE textual response) one by one and never goes back in the stream, and when an accepting state is reached, the string ",_ obtained by juxtaposing all past characters consumed to reach that state is a word of the language. Therefore, Kleene's theorem provides a way of matching regular expressions in a linear time (i.e. proportional to the number of .read symbols if we assume that the processing times of different symbols are approximately equal). This method is thus the optimal in terms of computing complexity. Most programs supporting regular expressions use this result to implement regular expression matching; the famous Unix H .
'grep' utility is a perfect example.

3.4 UML for Real-time Component-based Design The Unified Modeling Language (UML) [ 17], developed under the coordination of the Object Management Group (OMG), is one of the most important standards for the specification and design of object oriented systems. This standard is currently tuned for real time applications in the form of a new proposal, UML for Real-Time (UML-RT).
The visual notation of UML-RT is not only intuitive but it also has a deep mathematical foundation [48]. UML-RT is the result of merging the Real-time Object-Oriented Modeling (ROOM) [49] and UML.
UML is a graphical language for visualizing; specifying, constructing;
documenting, and executing software systems. Although conventional programming languages are good for expressing different algorithms, they cannot directly show the high-level features of a system. The UML is therefore a language for expressing high-level system properties that are best modeled graphically.
UML provides a base visual modeling language; however, it is not possible for the language to be sufficient for all domains. For this reason the UML has been designed open-ended to make it possible for the language to be extended. Without bloating the base language, new building blocks can be derived from the base to create ones that are specific to a domain (see Figure 3-4).
This section does not attempt to present the UML in its entirety. Rather, its goal to is briefly present the real-time notations to the UML accompanied by a brief overview of some key UML modeling concepts.

r~i~~~ maam ~~y~~°~~1i"~~ ~~~~i~~~c ~~K;Jv ~~~~.-~'I' ~Fas th;pe ~air~ ~~~lcv~3~; ~~~c~s. ':i'Facy ~r~ci~~~:
~~~~~s~r~ic~ are tile basis ~~:sj~rt-~~bierztød ~~a~siing hipcka ~~' t'le r~ll~n:L ar~c~ r~~:i-time s~~,ei~.li~asi~~as. ~ hey are ~.ased z~ ~s~~str~et ~-~e~e;s.
~~~zi~~~ly~sn ;~h~~~:~ arp ~asec~ to ~o~r: ~~ee~~~s ege~~~er rr~ r~l~ci~.~s.
~i~~~~~a~a ~hicF~ ilet~ ~.sse~hie .~eiatea e~iiecticzr~s ~f eierrn~~ts ~.:ogether drt~ a ~ra~~ai~al ~e~ic~i~~ c~f ail ssr ~~.rt ~s a. ~~~P~.
~lPzl~ents ire tile ha,sie ~h~e~t-~riea~te~ b~~iidi~g hipck:9 e-~ the ~.J~:, aa~~ }:°pai-ti~r~e ~l~taticzr~s any they a:~e rasp' to ~~~strs~~r o~~;xs. '''here ode ~e~zr hia~~.s ~~ elephants:
~trract;aral, phavior~~, ~ro~apEalg, ~~ci ~r~~etatie~lai. ~7~c ~,-i~l ~~ly hripr'~y ~respnt tiae s~n,i'x3Cii.~.raE ~.~~ ~eh~.Z~~~~~.'~~ 4.~~3ps.
~G's 3.4.1.1 Structural elements besides the base UML elements found in the specification [ 17] such as Classes and Interfaces, etc. the real-time extension to UML introduces a fundamental modeling element to real-time systems, called Capsule.
A capsule represents independent flows of control in a system. Capsules provide a very light weight modeling element for breaking a problem down into multiple logical threads of control. Each capsule instance has its own logical thread of control, though it may share an actual processing thread (known as a "physical thread") with other instances (roles). Capsules have much of the same properties as classes; for example, they can have operations and attributes. Capsules may also participate in dependency, generalization, and association relationships. However, they also have several specialized properties that distinguish them from classes.
For example, what differentiates a capsule from a class is how one can formally ~..
specify the internal organization of its structure, as a network of collaborating capsule roles. This collaboration is a specialized UML collaboration called a Capsule Collaboration (also capsule structure diagram). Figure 3-5 shows an example of a capsule's structure. The "ControlSystem" capsule contains three other capsules connected together through ports and connections. These three capsules collaborate to provide an overall service to their containing capsule, itself accessible from the "outside" via one port, namely "operatorPort"
..

~ ~T~ t'BIt~D 1'P0 t~
Figure 3-5: a capsule's structure.
Sending messages through public ports is the only method that capsules can use to communicate with other capsules. In fact, the only public attributes of a capsule are its public ports. While the behavior of a class is triggered by the invocation of a public operation on the class, a capsule's behavior is triggered by the receipt of a signal event over one of its end ports.
When a capsule receives a message from another capsule a signal event is generated and some response by the capsule is usually required. This typically involves performing some calculations, formulating a response, and sending one or more messages.
The optional state machine associated with a capsule represents its behavior. It controls the' operation of the capsule itself. The state machine is the only element that can access the protected (internal) parts of the capsule. Figure 3-6 shows an example.

error initialise disconnecteri Setup Connected connected ack o-0 o-0 Figure 3-6: an example state machine.
3.4.1.2 Behavioral elements °- Behavioral elements represent the dynamic parts of the model that describe the changing state of a system over time. In fact, once the structure of a capsule is defined, one needs to define its behavior (with state machines) and iYlustrate its functionality with "'~ execution scenarios (sequence diagrams).: State machines (that follow Harel's statechart formalism [50]) are found in the base L1ML standard. UML-RT extends the set of behavioral elements with the concept of Protocol.
.~
State machines contain hierarchical states (the state "Setup" in Figure 3-6 is a ., composite state -i.e. containing further internal states- and this is shown with an icon on the bottom-right corner of the state) and transitions that are triggered by events generated upon the arrival of a signal on one of the capsule's ports. To each transition in a state's machine, an action may be attached. This action is the execution of a piece of code (C++

for example) written by the application developer: As such, there is an equivalence between programs written in a regular programming language and a state machines.
When an event is ready to be processed by a state machine, a search for a candidate transition takes place to determine which one will be taken. A transition is said to be enabled if its trigger is satisfied by the current event, meaning that the transition has the same event and interface specified as the current event.
The search order is defined by the following algorithm:
1. The search begins in the innermost current active state.
2. Within the scope of the innermost current active state, transitions are evaluated sequentially. If a transition is enabled, the search terminates and the corresponding transition is taken.
3. If no transition is enabled in the current scope, the search in step 2 is repe-ated for the next higher scope, one level up in the state hierarchy.
4. If the top-level state has been reached and no transitions are enabled, then the current event is discarded and the state of the behavior remains unchanged.
As for sequence diagrams, they show interaction scenarios between a set of capsules present in a collaboration. The diagrams presented in Figure G-8 and Figure 6-3 on pages 108 and 115 respectively are an example of such diagrams.

Finally, the set of messages exchanged between two objects conforms to some communication pattern called a Protocol. It is basically a contractual agreement defining the valid types of messages that can be exchanged between the participants in the protocol. Therefore a protocol comprises a set of participants, each of which plays a .~. specific role in the protocol. Capsule Parts are Protocol instances (or protocol roles).
3.4.2 Relationships Most often model elements must collaborate with other elements in a number of ways. Relationships allow representation of how elements stand in relation to others.
There are four main kinds of relationships in the base UML (association, realization, generalization, dependency). In addition to the base relationships defined in the base UML, UML-RT introduces a new kind called Connectors. UML-RT also defines the semantics of the former relationships for the new elements introduced by UML-RT itself (capsules for example). For example; UML-RT defines the semantics of the Generalization relationship for capsules, which basically show how structure and behavior can be inherited in a class hierarchy of capsules. A capsule can, indeed, inherit their behavior (represented by state machines) from a parent capsule and extend it and/or override it.
Connectors capture the key communication relationships between capsule roles.
They interconnect capsule roles that have similar public interfaces (ports). A
key feature of connectors is that they can only interconnect compatible ports. Connectors only exist , in the context of a capsule collaboration (that is, a capsule's structure diagram). In Figure ""

3-5 for example; the solid line binding the roles "devicel" and "deviceController" is a connector role.
3.4.3 Diagrams Diagrams allow assembling related collections of elements together into a graphical depiction of all or part of a model. Each diagram provides a view into the elements that make up a model. In this way the user of the model can decide to see only the views of "" the underlying model that are of interest.
Some diagrams fully specify an element, such as the structure diagram of a capsule or its state machine. Others, such as interaction diagrams, only view particular use scenarios of the elements they involve. The only real-time specialization to UML's ~". diagrams introduced by UML-RT is capsule's structure diagram (which is a special kind of collaboration diagrams).

a 4 Generic Modei In this chapter, general issues related to the definition of a uniform NE
control interface are discussed. Next, design requirements for applications targeting uniform control of heterogeneous NEs are defined. Finally, the architecture of our framework is presented in two steps: The web-based architecture using SOAP and WSDL is presented, w and a generic server-side model based on Control Protocol Adapters (CPA) is defined.
4.1 The problem of defining a common view of NEs In order to achieve transparent control of heterogeneous network elements, two main steps are necessary:
- Defining a common abstract view of Network Elements, and - Transparently mapping that view into NE-specific commands and protocols.
The question of how to define a common abstract view -or model- for all NEs is not a trivial question: NE classed are quite different across vendors and technologies, in .., ' we will say that two NEs belong to the same class if and only if they have the exact same configuration , .
interface relatively to a given control protocol.

terms of functionality as well as control interfaces. For this reason, defining a common ,~,, abstract NE model, even for a specific category of NEs (QoS-enabled NEs, for example), may reveal very difficult. An attempt to define a global model will basically encounter the same obstacles as SNMP and CMIP which some have been mentioned previously.
,As explained earlier in Section 2.2, introducing a service-unaware intermediate abstraction layer (Caliban in the Tempest infrastructure case) necessarily limits the range of possible control operations, which we cannot tolerate here. Therefore, we reject the idea of having a generic fixed abstraction model for all NEs and we propose to use a generic control interface that is service-dependant. More precisely, this means that within the scope of a given service targeting a specific range of NE classes (that support the required nctionali fu ty), control operations are performed transparently from the controller point of view and NE-specific details are hidden.
So again, it is not necessary to focus on having a global abstract model, that is, a model that covers the widest range of existing NE functionality. As argued in [34], "Traditionally; a bottom-up approach has been adopted with regard to Network Management, i.e.; the network itself is the focus rather than the services that are provided, when in reality what is required is a top-down approach". In other words, the abstract model should be defined according to the needs of higher-level services that have been expressed prior to the model itself. A concrete example would consist in the case of a service requiring,two QoS functional blocks, namely Bandwidth Management and Traffic ~~ Conditioning: The NE abstract model in this case would cover (at least) those function blocks and the implementation would achieve transparency among a given set of NE V
b2 ~r...
classes. So, although this "scaled-down" abstract model does not cover all the capabilities of all NE classes, it provides all necessary control procedures required to deliver the higher-level service in a uniform; NE-independent fashion. Also, as future services are needed, the abstract model can be incrementally extended or new models can be added to ~.. provide for those needs.
As a matter of fact, we are not concerned with control architectures (that is, specific controller designs) but rather with how to efficiently and rapidly implement control procedures for a given control interface. The control interface in question, which we called generic control interface, is typically targeted for a specific control architecture itself providing for a specific service or a small range of specific services.
Since control interfaces are per-service, they do not interfere with each other and a change in one of the control interfaces does absolutely not affect other services that use other control interfaces (via adequate intermediate control architectures). The price to pay for this approach is obviously that new control architectures require implementing new control interfaces, but that is exactly why we are concerned about rapid and straightforward implementation of control interfaces. The evaluation of the framework, presented in Section 6.4, shows that implementing new control procedures with our method is ~~ particularly fast.
Starting fxom the latter point, it wily be assumed in the rest of this paper that an abstract NE model is given; and we will not be concerned any more about how to actually define that model. The purpose of his document is to introd~zce a flexible framework for developing support to transparent NE control. The flexibility of this framework is such ~w that it does not make any assumption about the nature of the exposed interface or the functionality offered by the targeted NEs Note that it is not forbidden to expose an operation through the common interface ~a that would provide the user with specific and concrete (i.e. non-generic or non-abstract) information about a certain NE. However, that information is a priori not known by the user and should not be needed except for pure "browsing" contexts and other similar tasks. We stress the fact that specific information about NEs sitting behind this generic interface should never be needed in order to make NE control decisions.
Following this logic, all NEs will be represented in memory by object instances of a same class. That class will implement the common abstract interface to all those NEs.
Note also that it is possible to include support for NE classes that do not implement all the functionality exposed by the common interface. In fact; it is assumed that this common interface sits underneath a control layer that comprises a control algorithm designed to provide a specific service to an upper layer. The control layer makes control decisions and issues control commands through the common interface, in turn controlling the NEs transparently. The control logic consistency is thus checked by the control layer, and the common interface is only a means of achieving transparency in performing the actual control functions. Therefore, the control layer is not supposed to send inconsistent commands to the common control interface otherwise it would be synonym of a design weakness in the control layer itself. However, should the control layer request some functionality on a NE that does not support it, a meaningful error message must be returned.

4.2 High-level Design Requirements This section discusses design requirements for a generic framework for uniform control of heterogeneous network elements. It is inspired in part from [4, 28, 33-35].
4.2.1 CiientlServer web-based architecture Remote objects can give a program almost unlimited power over the Internet.
Client/Server architectures have become ubiquitous [27] in most applications.
For this reason, one of the main design goals is to allow an Internet-wide access to the control module. But since most firewalls block non-HTTP requests, a web-based (I.e.
HTTP-based) architecture is necessary to get around this limitation. .
The Simple Object Access Protocol (SOAP) is the solution chosen to implement the distributed web-based architecture of the system. Section 3.1 introduces SOAP
and explains its adequacy -for addressing firewall issues in particular-, whereas section 4.3 explains its role within the global architecture.
4.2.2 Extensibility As new control protocols and networking hardware appear regularly, the ability to easily add support for new technologies within the system is obviously highly desirable.
For this reason, the application has to be easily extensible. By "easily extensible" we~
mean that extending the system to support new protocols/hardware should require minimal knowledge of the internal architecture from the developer and make extensive use of reusable components. Therefore, the application has to be modular, and its granularity has to be fine enough to permit easy module replacement and reusability.
Also, functional blocks [34] should be used to gather functions with common characteristics; for example the functions used for bandwidth management. This requirement is satisfied by using control protocol adapters as discussed in Section 4.4. It would also be suitable that a portion of the code be generated automatically from the framework's design model. This is achieved using code generation tools or IDEs (Integrated Development Environments).
4.2:3 Reliability Two levels of reliability of the application envisaged in this paper are required:
a) Completeness, that is, the application must handle all possible "predictable"
errors originating from the NE, such as the failure of a login command due to a wrong password. The application thus never "blocks" and recovering control of the situation is always possible. Most importantly, if a command fails it should return the NE to its original state. This is crucial because if a geographically-remote configuration erroneously puts the NE in an inconsistent state, it can result in important service-interruption times until an administrator physically present on the site fixes the problem.
b) Correctness, that is, eliminating inherent design errors from the application, such as wrong memory management. Of course it is a general requirement desired for all types of applications, not only the one we're discussing herein.

But we stress that using IDES for software development greatly reduces the chances of coding errors, since the generated code has been formally verified once and for all by the designers of the code generator.
The proposed implementation increases the reliability of the application.
Indeed, section 5.3 shows how the completeness of the application can be efficiently achieved.
4.2.4 Performance and Scalability For manual administration tasks, performance is usually not an issue. But for more complex scenarios such as concurrent access for QoS resource reservation, it is important to minimize the processing time on the server.
Performance can be improved at several levels. First, client/server communication times can be minimized by using an efficient and lightweight middleware.
SOAPIHTTP
latency can be optimized using a scaled-down HTTP server with an embedded SOAP
processor (implementation choice adopted by [20]).
Second, NE latency should be minimized by choosing an appropriate control protocol, which is a choice that varies from a NE type to another. In our case, we consider that CLI presents satisfactory performance for most NE classes.
Third, the control server should be multithreaded such that it can handle parallel requests for different NEs simultaneously. This prevents a client requesting a control procedure on NEA from waiting unnecessarily until a request from another client on NEB
is served, thus reduces processing delays from the client's point of view.

Finally, another possible optimization is the use of finite automata to parse the textual output of NEs (only when the control protocol is text-based, of course). Finite automata are mathematically proven to be the most efficient algorithm fox regular expression matching (see Section 3.3).
4.2.5 Security When it is a matter of configuring corporate routers and switches; security -ranging from protection against theft of resources to protection against denial of service attacks-becomes a hot concern: However, the application should use existing security standards in a modular and transparent way, i.e. without affecting the architecture of the non-secured version of the system.
Our design is consistent with this requirement. Client/Server communication security can be achieved by layering SOAP over HTTP, in turn over SSL. On the other hand, communication between the control module and the NEs does not generally need to be fully secured since both components would typically reside on a same security domain (typically a same LAN behind a same firewall). The only security feature that should always be enabled for every NE is access control (through an authentication mechanism that varies from a control protocol to another).

4.3 Web-based distributed architecture with SOAPIHTTP
I___________I
I NE
I

Client Application I Generic IVE I
NE

I Controllnterface I

SOAP Stubs C SOAP Skeleton NE I

I I
HTTI' Client I HTTP Serve)I

HIP

(portao)~__________I

LAN

Firewali Figure 4-1: SOAP/HTTF for firewall-friendly web-based access.
AS outlined previously, SOAP will be used in our system as the middleware Layer to support web-based access to the generic control interface. Figure 4-I shows a layered view of the system emphasizing its web-based aspect. The control module, which services are exposed through the generic 1VE control interface, controls heterogeneous NEs within a same LAN (more generally, NEs situated behind a same corporate firewall).
This generic control module is accessed through the firewall using SOAP/HTTP.
The SOAP layer consists of the pair SOAP stubs (client side) and SOAP skeletons (server side). (See Section 3.2.3 for a brief introduction to the roles of stubs and skeletons).
The generic control component exposes its interface -enabling SOAP-based RPC-as a set of web services. The Web Services Description Language (WSDL) [6]
will be used to describe our interface. Roughly spoken, a WSDL file is an XML-based document that basically contains the signatures of the available methods (services), which gives the client sufficient knowledge regarding the necessary SOAP structures to make RPC calls.
More precisely; "WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information: The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint"
[6J (See Section 3.2 for an introduction to WSDL).
Chapter 6 discusses implementation details regarding the incorporation of SOAP
and WSDL in the application. The next Section discusses the abstract architecture of the generic control module itself.
4.~ Server-side Generic Modet The architecture is two-fold (see Figure 4-2). The Generic NE Control Interface is the top layer and represents an abstracted view of a set of NE control functions. This interface is the one that is remotely accessible through SOAP-RPC as previously discussed in section 4.3. Such an interface may expose any set of high-level control procedures. Indeed, if an upper layer tries to invoke a generic control function on an NE
that doesn't support a control procedure with the same semantics, or if the procedure is simply not implemented. for that NE, then an error message will be returned.

Generic NE Control Interface CPA ~ ~ . . . . . I CPA n __,____+______,____~__ NE~~~ ~... LNE~,p) I NEn,~ I ... I NEn,a Figure 4-2: Architecture of the generic control system.
The granularity of commands allowed by a NE usually differs from a NE class to another. For example, some NEs will allow individual port configuration, while others will only allow configuration of ranges of ports at once'. We can say that the "port configuration command" of the first NE class is more granular than the second's.
The commands included in the generic interface can obviously be at most as granular as the finest grained commands among the supported NE classes.
However, they do not necessarily have to be as fine-grained as possible. On the contrary, it is often desired to have access to conceptually .simple operations that map to complex sets of commands for each NE class. For example, it can be said that "setting the bandwidth for a queue to a certain value" or just "logging in" are conceptually simple requests, although they may have to be mapped to quite long sequences of commands and intermediate tests ' For example, some NEs allow configuration of queues and their associated bandwidths on a per-port . .
basis, while other classes of NEs will only allow a same global queues configuration for all ports.

for a given NE class ("logging in" may involve sending several passwords, checking for timeouts, retry the login procedure when an error occurs, and s~ on).
The second layer is the control protocol adapters layer. A Control Protocol Adapter (CPA) is a component that adapts from the generic interface into a specific control protocol for a particular NE class. The CPA thus presents an abstracted view of this NE
class to the rest of the system. CPAs are implemented on a per-NE-class basis, which we consider being a sufficiently fine granularity, and each CPA may support one or more control protocols for the NE class that it is bound to.
CPAs are an application of the Adapter pattern. The Adapter pattern is one of the structural patterns listed in the reference book Design Patterns by the Gang of Four [37].
In software development, an adapter simply maps the interface of one class to that of another. Adapters are used continually throughout the software development process, hence the term Adapter pattern.
When a method is invoked through the generic interface, it is dispatched to the appropriate CPA, i.e. the CPA of the concerned NE class. An instance of that CPA will then choose one of the supported control protocols -using a predetermined selection scheme- and map the generic method into an appropriate set of commands relatively to the selected protocol. Note that the protocol selection logic is up to the CPA
implementer, as long as the end result is adequate and that it doesn't affect critical parameters of the _ system (performance, security, etc.), Again, a CPA may only implement a subset of the methods exposed by the generic interface, and should return an appropriate error message if a non-implemented/supported method is invoked.

As mentioned in the previous paragraph, when an invocation is made through the generic interface it is dispatched (at run time) to the right CPA. In order to achieve "Command dispatching" transparently, some knowledge has to be provided to the generic control server about the nature and state of the NEs it is going to control.
Indeed, an implicit knowledge of the composition of the network, that is, the classes of NEs forming that network, is needed. This is necessary because when an operation is invoked upon a certain NE the control server has to choose an appropriate CPA to handle that operation, which can obviously not be done if the class of the NE is not known. Making this information available to the control server can be done by several possible methods as long as it remains transparent to the upper layer.
One possible method is the use of a basic network information service. Such a service maintains a database containing specific information about lVEs of the network and makes it accessible to the control server. The database in question is therefore populated by the information service and read by the control server. The information provided by this service is typically concise and would consist mainly in vendor, supported protocols and software version information for each NE. As for the network information service itself, its architecture may vary as well. It can simply be inexistent if the database is populated manually (an approach only suitable for small networks), or it can consist in an automated discovery service that would use standard management attributes (with SNMP
or CMIP for example) to get the necessary information. Note that the performance of the discovery service is not an issue here because the database is typically filled offline and rarely updated. Also, the control server would access the database directly and hence performance issues are shifted to the database implementation, which is usually very efficient.
Supplied with information about the controlled network, the control server now can dispatch control requests to the corresponding CPAs. In the most general case, some knowledge about the state of the control system itself -that is, knowing which CPA
instances are active .and which NEs are being controlled at a given moment-may be needed as well to make dispatching decisions that would insure efficient use of available computing resources. Therefore, given that such knowledge i.s conceptually global and unique within the system, it would be preferable to relay the dispatching task to a separate component. The dispatcher is not represented in Figure 4-2 because it remains an implementation detail and the latter statement is just an implementation suggestion. It will be further discussed in Chapter 6. , Note that there is no restriction regarding the number of NEs a single CPA
instance can handle, as long as they alI belong to the same class. Reciprocally, nothing prohibits the use of several CPA instances to control a same NE. Indeed, some NE classes support multiple parallel requests as long as they don't conflict. As outlined in Section 4.1, the consistency of control commands is not checked by the implementation of the generic control interface, but rather by the upper layer. This is why the implementation should not put any restriction on the number of parallel control requests per NE.
Finally, the range of supported NE classes is reflected by the different CPAs implemented within the application. Adding support for another NE class will consist in . .
the implementation of a new CPA for it, which is a modular and scalable way of extending the application. As we will see later, adding new CPAs is a simple task that doesn't require detailed knowledge about the architecture of the rest of the system, and is performed mainly through sub-classing.
The next Chapter discusses a specific CPA architecture, namely CPAs supporting Command Line Interface (CLI) control protocols.

CLI-based CPA design In this chapter, the problem of choosing a control protocol for a given NE is presented. The choice of CLI as a starting point is justified. The particular case of CLI
interaction protocols is then studied, and specific relevant issues are presented and addressed. A component-based, real-time model is used to design the architecture. A new concept, called Dynamic Triggering Filter, is finally introduced as an evolution of regular-expression-based parsing in CLI interaction automation.
5.1 Con#rol Protocol Selection A CPA will require a control protocol to achieve remote control of NEs. This protocol may be SNMP, CMIP, or a login-based Command Line Interface (CLI) mechanism, etc. The NE class itself rather than the designer of a CPA often determines the choice of that control protocol. Several criteria, in fact, have to be considered.
A first criterion would be the availability of the desired functionality. All control protocols that do not support_the target functionality are thus eliminated.
For example,, .
while most NE classes support SNMP and some of them tend to be CORBA
compatible as well, operations specific to the desired control may not always be offered via these protocols. On the other side, the widest set of control functions in a NE is always available via CLI.
A second criterion would be efficiency. This is an optional criterion and depends on upper-layer's requirements. Nonetheless, it can be mentioned that SNMP, for example, has a rather poor performance. In order to configure the state of a NE with SNMP, one has to send UDP packets having he following properties:
~ Each packet contains authentication information, which has to be processed by the NE every time. There is no notion of "security session".
~ Each SMNP packet can only perform a single and primitive SET operation.
Thus many packets need to be sent in order to perform a complex configuration.
~ SNMP agents (i.e. embedded in the NE) are typically slow. In fact, the agent usually translates the SNMP data into an internal object representation after undergoing several validity checks. Moreover, some SNMP agent implementations surprisingly translate the SNM:P data into internal CLI
commands, in turn translated into internal objects.
In comparison to SNMP, CLI has many advantages:
~ Authentication information needs to be sent only once, since CLI is used within a "session". Subsequent configuration commands will use an already-opened session to communicate with the NE, thus saving the authentication overhead.

~ Complex configuration can be achieved with a few CLI commands (typically 1 ~3 commands) that map to a much larger number of SNMP SET
requests. The traffic necessary to carry that data is obviously low. The generated response is also concise, thus low on bandwidth consumption and faster to process by the controlling entity.
A third criterion would be reliability. In the case of SNMP, since UDP is used the configuration is unreliable. Some acknowledgement mechanism has to be in place to guarantee the successful configuration of the NE. Even when this mechanism exists, it will be required for each SNMP SET request, thus doubling the volume of the traffic necessary to configure the element. CLI is better from that point of view because:
~ CLI is usually run over Telnet or SSH, which both use TCP as a transport mechanism. The communication is more reliable than UDP.
~ CLI allows a synchronous type of configuration. Each time a command is submitted, the NE responds as soon as it is processed with either a simple prompt or a specific message indicating success/failure of the command.
Within this paradigm, it can always be guaranteed that each configuration step is carried properly before issuing the subsequent ones.
A fourth criterion would-be ease of implementation. The purpose of this thesis is ~ta - -present a framework that allows -among other things- easy implementation of automated CLI commands. We argue that the proposed method is easier than using SNMP/CMIP

libraries to implement SNMP/CMIP-enabled CPAs. Implementing software components achieving CLI automation using our method follows the natural interaction that an administrator is used to, and doesn't require much programming skills compared to implementing a standard software component.
Security considerations should not represent an important issue, because the controlling entity usually runs in the same security domain as the controlled NE
(typically the same LAN). Therefore, using unencrypted communication over a Telnet session is not problematic. However, security has to be enforced regarding the communication between the controlling agent and a manager acting as a client for that agent, as mentioned in Section 4.2.5.
One of the disadvantages of using CLI is that only control procedures can be accomplished. SNMP and CMIP for example, support traps and thus allow monitoring of events in the network, which is impossible with CLI. Moreover, retrieving network information may reveal more efficient using SNMP/CMIPy M-GET commands. This is why we stress the point that our previous argumentation is not meant to show the "superiority" of CLI over other management protocols. Instead, we aimed at justifying why CLI was chosen as the first control protocol to study in the subsequent sections of this thesis. We insist on the fact that it should not be used as an exclusive solution for network management, but rather coexist with other solutions in a cooperative fashion.
Finally, our proposed method is designed to be extensible to any other control protocol.
Therefore, in the following it is assumed that the underlying control protocol is : .
CLI. Issues related to other control protocols will not be covered in this thesis.

5.2 CLI-based CPA design issues CLI-based CPAs use the command line interface to a box to control it. This is accomplished by opening a login session (via Telnet, SSH or some other means) to the box and then sending textual commands to it. Traditionally, this is a task that is performed manually by network administrators to control their NEs. Our purpose is to automate this interaction using a method that satisfies the requirements previously listed in Section 4.2.
The following general CLI characteristics have to be taken into account:
a) CLIs are heterogeneous across vendors and technologies in terms of syntax as well as semantics. CLI-CPAs thus need to map operations exposed by the generic interface into CLI commands on a per-NE-class basis.
b) CLI's output can be viewed as a stream of characters. Accordingly, the CPA
should provide a stream-oriented parsing of the NE's textual output.
c) Some CLIs support a basic form of trapping by sending text messages asynchronously. The CPA has to provide a mechanism to parse such messages whenever they are generated by the NE.
d) Some CLIs are implemented such that the prompt may be re-printed prior to an error response being generated. In this case, it may make detection of errors difficult.

All the issues above have to be considered carefully in order to insure reliable NE
control via CLI. Our design will address these issues incrementally in a way that reduces the complexity of coping with all the above problems simultaneously.
For the designer of the CPA, being familiar with the Network Element CLI
interface is clearly a prerequisite. However, writing a CPA should require little or no knowledge about other implementation details of the framework helping the CPA's writer focus on CPA/CLI interaction logic. The design architecture discussed below takes this requirement into consideration as well.
5.3 ~SMs and Regular Expressions for CPA~CLI interaction 5.3.1 Introduction Commands that are conceptually simple sometimes map to complex sequences of CLI commands. If a command within that sequence fails, some alternatives usually have to be taken. Also, the syntax or arguments of some commands in the sequence may depend upon the result of previous commands within the same sequence or upon the state of the NE.
To model such complex interaction; a high-level command (i.e. a command present in the generic control interface) will be mapped into a ~'anite state machine (FSM) that will handle generating the textual commands and parsing the reply coming from the NE , , .
(see Figure 5-1 and Figure 5-2). Also, to make the design as modular as possible, the mission of sending textual commands to the NE and receiving "raw" text replies from it will be undertaken by a separate component (Text-based Control Client) within the CPA.
Control Protocol Adapter input Finite State ~ ~ Text-based Machine Control Client output Figure S-1: General structure of a CLI-CPA.
Figure 5-1 shows the basic structure of a CLI-CPA. The FSM sends text to the Text-based Control Client' through the "input" port and receives text from it through the "output" port. The Text-based Control Client is simply a component that hides the details of sending text over a CLI session. It acts as a transport layer, and as such it performs only basic operations (opening sockets, sending and receiving text through them, etc.) and is not aware of the semantics of the CLI commands or the NE reply. The FSM
is therefore the engine responsible of controlling CLI interaction.
The CPA will have to use a different FSM for every different generic operation and every different NE class. The CPA also has to infer which FSM to use transparently from ~ ' the upper-layer perspective. But the upper-layer doesn't have any knowledge, a priori, about the NE class it is invoking the operation upon. The upper-layer only possesses a reference to an object supposed to reflect a common abstract view of a NE.
Therefore, the upper-layer cannot communicate the NE class to the CPA simply because it does not know it, which implies that the NE class has to be inferred by the CPA itself.
As explained in section 4.4, such information can be obtained from an external network information service. Once the NE class for the target NE is determined, the CPA can finally map the generic operation into the appropriate FSM:
The FSM also has to be able to receive parameters from the containing CPA.
This makes the design more flexible because it allows parameterization of certain commands, such as the port number parameter in a "port activation" command or the username parameter in a "login" command.
In summary, a CPA dynamically imports an appropriate FSM instance (Figure 5-1) into its FSM slot to handle the interaction with the text-based control client. That FSM
instance is determined function of the NE class, the latter being obtained from an external information source.
5.3.2 The FSM component Each FSM follows a same global behavior pattern: After the FSM has sent a textual command to the NE, it enters a new state where a certain number of possible replies from the NE is expected. This new state has a certain number of outgoing transitions, each of them corresponding to a reply. According to the received reply, one of the outgoing transitions is to be taken and the FSM moves to a new state again. The FSM
follows the same pattern until a final state is reached, where a result (optional) is returned and the FSM is subsequently destroyed.
There is, however, a difficulty that stems from the fact that the replies in question can be of a very large number. It is clearly not viable to have an outgoing transition for each expected reply. Instead, one can notice that these replies conceptually fall in a limited number of subsets according to their semantics (e.g. the subset of replies indicating an error of a certain type, etc.). Each one of these subsets can be characterized by a corresponding regular expression (see Section 3.3). Once the reply matches one of the expected regular expressions, an associated transition is taken.

conn ction retry ~ ~
o .~ o ~- ~ c~ 1og''~' iE'yriC~~~e 2~~t Sgt "'Password:" a ~ send password w..~ ,,~ 'o lo9in C h'~Z9~., ~4~~~/
Class A "login" FSM
Figure 5-2: an FSM example.

Figure 5-2 shows an example. Strings within quotes and typed in courier denote regular expressions (a simple Unix-like notation for regular expressions is used for clarity, such as the ' *' that denotes an arbitrary sequence of characters.
For the prototype implementation, a standard notation is used instead). Text typed below transitions represents actions to be executed when the transition is taken. For example, the transition from state (l) to state (2) expects the password prompt (which is « Password:
» in the present figure example), and sends the password as soon as that prompt is detected.
The above can be abstracted by saying that the state-transition diagram of the FSM
has the following properties:
i) Each transition has an associated action which is executed every time that transition is taken (typically sending a textual command to a NE), and ii) Each transition can be triggered by « the set of strings matching a given regular expression ».
The latter point is the one on which our efforts will focus the most. Indeed, in most FSM mathematical models, a transition is taken when its associated symbol equals the input symbol. Input symbols and transition-attached symbols are, in particular, of the same type (they both belong to the same underlying alphabet [ 11 ]). In our case, however, input symbols (characters) and transition-attached symbols (regular expressions) are not homogeneous as we would like them to be:
To address the issue of heterogeneity between input symbols and transition-attached symbols, a first solution would consist in changing the "equality operator"
(i.e. the F

operator used to compare input symbols and transition-attached symbols), such that its left operand be a character and its right operand be a regular expression. The following can be done to achieve the desired behavior: every time a character is received by the FSM, it is stored in a queue forming a string. Then, the current string is checked against the regular expression (the right operand of the operator). If a match is detected, then the equality operator returns true, which fires the transition to which the regular expression is attached.
The above workaround bypasses the heterogeneity obstacle. Unfortunately, it raises a more problematic issue. Actually, such an operator is usually expected to be stateless.
In the most general sense, this means that when comparing any two elements, we expect the comparison result to be the same no matter how many times we repeat this operation, and regardless of the previous elements involved in other comparisons (i.e.
the history of the operator). It is obviously not the case with the overloaded version of the equality operator introduced herein, since the result depends upon some previously-queued characters. Even if we could tolerate such behavior, it would clearly be a source of bugs since it is hard to observe the behavior of a program involving a stateful operator. In short, the above "solution" is just not practical.
There is also a remaining detail. In classical FSM models, when outgoing transitions have distinct triggering symbols, the fired transition can be resolved unambiguously;
there is at most one transition to be taken, and the FSM is said to be -at least locally-deterministic. Unfortunately, when the symbols in questions are "regular expressions", things become slightly subtler. Distinctl regular expressions, indeed, do not always recognize disjoint2 languages. Even worse, given two regular expressions it is not always obvious whether the languages they recognize are disjoint or not, and the answer may require non-trivial computations. In our model; this means that even when outgoing transitions have distinct associated regular expressions, there may still be an ambiguity if at least two of them recognize non-disjoint languages. Such non-determinism is obviously undesirable since it can be a source of hard-to-detect bugs. The rest of this section explains the solution chosen to address the previous two issues.
The idea is simple: confine regular expression matching within a separate component, which we will call Regular Expression Module (REM), and define an interaction protocol between the FSM and the REM. The REM should naturally be encapsulated within the FSM component since it is an implementation detail from the point of view of the Text-based Control Client and the CPA.
1 That is, matching (recognizing) different -but not necessarily disjoint-languages.
2 That is, their intersection is empty.

Control Protocol Adapter Finite State Machine input internal port Text-based Control Client Regular Expression output Module Figure 5-3: FSM with internal REM.
Figure 5-3 shows a component-based structure of the CPA where the internal structure of the FSM is also visible: The FSM component automates:
a) Sending the textual commands via the "input" port of the Text-based Control Client component, and b) Parsing the output of the NE received via the "output" port of the Text-based Control Client. The parsing is done within the FSM through the Regular Expression Module (REM). The latter communicates with the encapsulating FSM via the "internal port".
Since the mission of regular expression matching has been conferred to the REM, the alphabet on which the FSM operates is no longer "regular expressions" and a new alphabet has to be defined. Now the REM will be responsible of triggering the FSM with symbols from this new alphabet. It has to read input characters -coming from the NE- A

and send triggering symbols to the FSM whenever one of the regular expressions is matched.
A property that has to be verified by this new alphabet is having a partial order.
Indeed, as we mentioned earlier in this section, there is a non-determinism issue due to the use of regular expressions to trigger FSM's transitions. To cope with it, an additional notion of priority needs to be attached to each of these regular expressions.
The REM
will check the character input stream against the regular expressions in their order of priority. The triggering symbol sent to the FSM is the one corresponding to the matched regular expression of the highest priority. By convention, the highest priority will be given to the smallest symbol relatively to the order of the alphabet.
A simple alphabet that satisfies the above requirement is a finite set of integers.
That is, from now on the FSM will be triggered by integer symbols. Regular expressions attached to FSM transitions are now additional information that is dynamically communicated to the REM. The example presented in Figure 5-2 is now slightly modified into the one of Figure 5-4. Note how the choice of transition-associated integers is totally arbitrary as long as the FSM remains deterministic and the implicit priorities do not corrupt the proper behavior of the FSM.

open connection 0 retry o .~ 4 two ~ m 1 it~~
E G~ 103 osse clot ~ "*Password:' 2 send password v hay 2 ~n i°9in svgs ~ ~~ 3 Class A "login"FSM
Figure 5-4: an FS1VI example with integer alphabet and attached regular expressions.
More precisely, every time the FSM enters anew state, it updates the REM data by sending the set of regular expressions it is expecting. The REM reads the characters continuously and sends a symbol (the triggering integer) to the FSM when the:
sequence of read characters matches the current expression of the highest priority. The FSM takes the transition triggered by the integer received from the REM, updates the REM
data again, and so on.
By adopting the previous approach, that is, bringing more structure into the FSM;
the task of defining new FSMs for new generic operations is simplified.
Actually, if the interfacing between the FSM and the REM is implemented in a base class for all FSMs,-it:
needs only to be inherited by new ones: The FSM defining that FSM/REM
interfacing would be the root of the FSM class hierarchy. As a consequence, extending the range of ' supported control procedures is done in two simple steps: l) adding an FSM by sub-classing from the base FSM class, and ii) binding it to the generic operation it is meant to implement. In this new FSM, only the state-transition diagram has to be specified, which is obviously the minimal set of information that must be provided by the implementer of the FSM. Re-implementing the default FSM-REM interaction (see section 5.3.2 above) is not needed, and neither is the knowledge of other implementation details, such as the CPA architecture itself. This satisfies the easy extensibility requirement introduced previously in Section 4.2.2. Chapter 6 shows this scheme in great detail using UML's formalism.
Increasing the reliability of the system also becomes easy when using FSMs, because:
a) Complex error-detection and error-recovery schemes may be implemented (which cannot be represented using simple command sequences, for example).
We called this feature completeness in section 4.2.3 above.
b) The graphical design of the FSM reduces the likeliness of design errors and facilitates debugging, especially if it can be observed at run-time.
5.3.3 The Regular Expression Module The above can be summarized by saying that the REM acts as a dynamic alter on the character input stream. The word "filter" is used herein to denote an active component that transforms a data stream into another data stream, namely a character F .

stream into an integer stream. It is "dynamic" because its internal parameters are changed dynamically by the FSM every time the FSM enters a new state. Those parameters in question are the set of regular expressions against which the character input stream is checked, in addition to the integer symbols bound to each regular expression in that set.
FSM-contra(lable parameters t"r....~i_~...._......."
FA-based reg.exp. watcher input ~ output 1 ~ ,, FA-based reg.exp. watcher . . . a b g d . . , c c ~ in ut out ut ~ 2 . . 3 2 1 2 . . .
p ~ P
Chad cters c ~ ~ ~' ~ 3 in egers FA-based reg.exp. watcher.
input ~ output t~,~.~._ ,.._..~.~ R.E.M.
Figure 5-5: the REM viewed as a dynamic filter controllable by the FSM.
Figure 5-5 illustrates the concept. Each input character is replicated and sent to the "regular expression watchers" that work in parallel. When a match is detected, the index of the first matching regular expression is sent to the output. In practice, however, when a match occurs within the REM, the matching string should also be sent along with the integer identifying the transition. Such information can be useful if we are trying to ,. , extract further information out of the response, for example.

We purpose now to address the issues b) through d) of Section 5.2 by analyzing their nature and Ending necessary design enhancements for the REM.
Issue b) requires the REM to be stream oriented. There is a classical and powerful algorithm used for regular expression matching based on I~leene's theorem [
16] as introduced in Section 3.3.4, which basically states that every regular expression can be mapped to a finite automaton (FA) that recognizes the same language. A finite automaton "consumes" the input symbols once and never reads them again, which makes them a best-performance tool suitable for stream-oriented parsing. This is shown in .Figure 5-5 with the label "FA-based reg.exp. watcher". Every time a new regular expression is submitted to the REM module, an equivalent finite automaton is calculated and used to read the character input stream looking for a match.
As for the issues c) and d), one can observe with little reflection that they actually incarnate a same problem: The fact that text can. be sent asyncl~rorcously by the NE, that is, not only as a response to a command but also at "unexpected" moments.
In fact, according to the scheme previously discussed, regular expression watchers have the following lifecycle:
i) they are created when the FSM enters a new state, ii) they are active until a match is detected, iii) they are finally destroyed, - and a brand new set of regular expression watchers is created as the FSM enters another state.

Within this logic; Figure 5-6 shows what might be done in order to detect a late error printing. The diagram in black shows the desired FSM behavior: The "command A"
is sent, then from state (0) two possibilities are expected; a "success"
response and an "error" response. But since the error message can still be sent even after the FSM has moved to state ( 1 ) or even to state (3), the transitions in "red" have to be added in order to handle that error should it be detected at that stage. Note also that when the FSM moves from (0) to ( 1 ) and from ( 1 ) to (3), it has to re-send the reg.exp.
corresponding to the error message to the 1ZEM otherwise the error will not be detected. It is clear that this "trick" is unscalable and greatly affects the readability of the state-transition diagram.
FSM state transition diagram a 3 v, 3 m D
1 _ 5 ...
success ~ some action 3 o~

Figure 5-6: an inappropriatevvay of detecting late error printing.

To make matters worse, textual traps can also be treated using the latter method, but it would require adding "red" outgoing transitions on every state of the FSM.
Therefore;
we decide to enhance the REM behavior, as explained below.
The solution we are going to discuss is based on,flexible lifecycle management for each regular expression within the REM.
We introduce a positive integer that we call TTL (Time To Live), and attach it to each regular expression within the FSM. Now regular expressions are communicated to the REM jointly to their attached TTL value. Every time the FSM enters a new state, it sends a notification to the REM, and all TTL values are decremented. The regular expression "dies" (i:e. the REM destroys it and stops checking the input against it) when its TTL reaches zero.
The above enhancement allows detection of late error printing by attaching greater TTL values (typically 2 or 3) to expressions matching errors. The other "ordinary"
expressions will always have TTL=1 by default. TTL values can also be "infinite" for expressions that are desired to remain alive during a whole CLI session (traps for example).
Figure 5-7 shows how TTL values are reflected on the state transition diagram of the FSM example from Figure 5-6. Now, the error reg.exp. has a TTL=3 and is sent to the REM at state (0).,Accordingly; that reg.exp. will expire when the FSM exits the state (3).:
The choice of the value TTL=3 is empirical; in fact it means that it is "unlikely" that the error message be received if the FSM has already moved TTL=3 states away from the state where the error were originally expected. If reliability requirements are very stringent, this logic may be intolerable and thus TTL should be set to an infinite value such that it can be detected at any time, but this affects performance since it requires .
checking the character input stream against an extra regular expression at moments where the probability of an error is very low or inexistent.
FSM state transition diagram (with TTL) ~ a . a success ~~ some5action error reg.exp. : TTL=3 ca Figure 5-7: impact of TTL on the FSM.
The "red envelope" in the figure is called a composite state because it contains encapsulated sub-states. The red transition from the composite state to state (3) is called a "group transition". According, to UML semantics (which state that the transition-lookup. : , algorithm starts searching from the innermost to the outermost state); if the FSM is in state ( 1 ) for instance and the symbol '3' is received, then the red transition is fired. The .- .

use of composite states hence simplifies the FSM design by eliminating unnecessary "red" transitions, as it was the case in Figure 5-6, as well as eliminating the need of re-sending the regular expression to the REM every time.
...~ ~ 5 3 ...
some action ' ..

3_timeouts TTL=infinite Figure 5-8: a FSM example involving an infcnite TTL.
Figure 5-8 shows an example of a state-transition diagram involving the use of infinite TTL. The reg.exp. corresponding to that TTL value is communicated to the REM
in the beginning of the CLI session for example (not represented here). Since that reg.exp. never expires, it is constantly checking for the text pattern; namely the occurrence of three "timeout" messages, without disturbing the course of other events within the FSM. When such a match is detected, tine red transition is taken and some specific actions are undertaken. [NB: the outermost envelope (the one with rounded corners) is also a~state and it is called the top state. When the symbol '0' {corresponding to the "three timeouts" reg.exp.) is received by the FSM, since there is no other transition but the red one accepting that symbol, the red transition is fired.]

The discussed enhancement may give the impression that the design of FSM state-transition diagrams becomes more complicated. In reality, it is only more complicated for those "pathological" cases, but it is indispensable in order to insure correctness and reliability. For all other "regular" cases, however, the design procedure remains the same, and the default TTL=1 value corresponds to the originally-presented scheme (i.e. before introducing TTLs).
5.4 Further abstraction: Dynamic Triggering Filters The architecture discussed so far is the one that we adopt for the implementation of our prototype, presented in Chapter 6. The purpose of this sub-section is to discuss further enhancements to the architecture of the FSM that would allow more flexible and thus powerful interaction with the CLI. These enhancements would also allow future extensibility to other types of User Interfaces, namely web-formatted UIs (with HTML or XML for example). These new enhancements will be recommended later in Chapter 6.
Let's first summarize the concepts introduced with the FSM. The first obstacle arose when we needed to trigger a finite state machine with something that is more complex than a simple symbol, namely regular expressions. The proposed solution to that problem was to shift the difficulty of regular expression matching to another component such that the FSM be triggered by simple symbols sent by that new component. The new component that we introduced was the REM. The REM handled regular expressions and acted as a dynamic filter on the character input stream. It transformed the input stream into a stream of integer symbols (or signals in UML vocabulary) carrying data (the matching string). The reason why the matching string was sent along with the triggering symbols was to allow the FSM extract pertinent data and possibly undertake further actions depending on the contents of that string.
By observing the latter scheme, we can notice that what the FSM really needs is a pertinent feedback from the parsing module (the REM, so far). As a matter of fact, what is desired from the FSM's perspective is to send text commands to the NE and receive the NE response under a "distilled form", that is; signals carrying data. The FSM
specifies the form and content of that distilled information to the parsing module using a certain language (regular expressions, so far). Therefore, the nature of the distilled information is limited by the expressiveness of the language used to describe that same information.
More precisely, using the REM one can only parse text using regular expressions.
Although regular expressions are sufficient in most cases, they are limited to a language category called "regular languages" (see Section 3.3). Regular expressions cannot parse XML for example, because XML is a language that falls in a super set of regular languages called "context-free languages". Moreover, using the REM, data carried by the triggering signals is limited to character strings, as presented previously.
For each signal, the attached string is the one that matched the regular expression bound to the same:
signal. One cannot request more expressive data from the REM, such as the 3'~
token of the matching string. Instead, the entire matching string is first received by the FSM and has to be further parsed in order to extract any other specific information.
We propose to push the abstraction further in the architecture of the REM, and use a more generic form of it that we call Dynamic Filters Module (DFM). The DFM has the same global role of the REM, except that it is extensible to support any type of parsers internally. We call these parsers Dynamic Triggering Filters (DTF). They are "dynamic"
because their properties are settable dynamically by the FSM. They are "filters" because they transform a character input stream into another signal stream. Finally;
they are "triggering" because these filters serve to trigger the FSM with the signals they generate.
With the REM, the FSM can only specify one property, which is the text pattern that the response has to match, and is limited to receive the matching string. With a DTF
object, the .FSM can specify more properties to be verified by the response, and can decide which information to receive when the response verifies those properties. For example, using a DTF the FSM can require the NE response to a) match a given regular expression, b) to have a minimum given number of tokens and c) to contain numerical data. The FSM can further specify that when the NE response satisfies the previous properties, the signal sent by the DTF carry a list of numbers corresponding to the numerical data contained in the textual response.
DTFs can be incorporated within the FSM using the same logic that was used with regular expressions, as represented in Figure 5-5 on page 92. Every time the FSM enters a new state, it sends a set of DTF objects to the DFM. These objects will parse the NE

response in parallel and send a signal whenever they detect a match. The signal sent by a DTF that detected a match contains data objects that were extracted from the matching string. The algorithm used to extract that data from the matching string is a property of the DTF itself that can possibly be parameterized by the FSM when the DTF
object is created.
Using the above idea, the DFM can be extended over time to provide additional parsing functionality by defining new DTF classes offering that functionality as needed.
Another advantage of this approach is that the FSM's state-transition diagram is simplified to its maximum, because it is only left to reflect the outline of the CLI
interaction and indicates clearly the semantics of the expected NE responses through the use of DTFs.
DTF is an application of the Factory Method pattern as defined in [37]:
"Define an interface for creating an object, but let subclasses decide which class to instantiate.
Factory Method Lets a class defer instantiation to subclasses": In our case, the class DynamicTriggeringFilter (see Figure S-9) contains an object of type DistilledData. This object is supposed to be sent to the FSM when the NE
response matches the filter in question. Therefore, a DynamicTriggeringFilter subclass will send a data object that is an instance of a subclass of DistilledData to the FSM. In summary, object instantiation is deferred to subclasses of DynamicTriggeringFilter~
that will decide which DistilledData subclass to instantiate, which is exactly the spirit of the Factory Method design pattern. In Figure S-9, the object performing regular expression matching (RegExp DTF) becomes a subclass of DynamicTriggeringFilter and the data object sent upon the detection of a match (RegExp Data) becomes a subclass of DistilledData.
Figure 5-9: the Factory Method pattern applied to DTFs.

6 Prototype implementation This Chapter presents a fully working prototype that was implemented in order to evaluate the theoretical concepts introduced previously. This involved two main activities:
1. Implementing the generic framework, that is, the infrastructure that provides support for the architecture described in the previous chapters. This includes in particular support for CPAs, FSM and REM, in addition to other necessary components that will be described later. This activity also involved gathering the different third-party libraries necessary to build the prototype.
2. Defining a generic control interface for the prototype, which depends on the desired service as well as the chosen target NE classes.
The implementation part also served as an evaluation of several criteria, such as the required delays to incrementally extend the application and the complexity level of this task. As mentioned before, a big importance was given to the latter criteria -beside the _ .
traditional ones such as executable size and processing delays, etc. Indeed, the application was intended to be highly flexible and easily extensible to cope with the ever- .. .
changing nature of both networking hardware and software.

section ~.l hrief~y t~resents ~:s~~ vools aid third-pa~°~:y lg~sr~re~;
that ha~~ been wised ire tile i~nplerr~entation o~ the pr~tot~pe. I~lLxtS ~e.etion ~.~ details the ~J~h design and i_~ple~nentatio~ cl~ the v~r~~ne~rao~if. ~eetio~~ ~.sho~xrs hour the: p~-c~ious ~r~:~~e~oa°k ~v~s used to irnpler=lent a partieular cc;.ntrol se.r~~ice, nar~lely $ra~ffic ~onditioF ing. Finally, ~e~i:~s~n ~.~ evaluates She o'tained -;°~;sults.
~°9~r~~i~~~~~a~~
'The design was .r3ostly done in i_.il~i~, a~~atil real-tar~ze extensions, and tile ~r~l~iernen'tatio~ i~a ~:-~~-. ~I~:~'iJ desgal was cd~~~. usitzg ~
eo~BZrnerei~~ ~~ool, n~.~°reiy 1Z.~.tioral l~.dse ~ealT'in~e ~~9~. 'This tool supports ~.Ti~~~ ~.3 ~~ith real-time extensions ~se,e ~e.ction ~.~ ~'o~ an iaw:~oductior~ v~c~ ~.~NIL':~ ~ea:~-tirrse e;,;~tens.io~~ end ~~~~
: as an irn~Jle~nei~ta-~ion iangr:age binding. It All a~TI~ diagrams shovel ire suhsesiuent sectians are screen capt~~res a:~ c~iagra~s designed ~ass~g that vo~l. ~~igure ~- i sho°avs an o~rerv~e~r ~~ the tool9s C"aLl~.
Figure ~-i also sllo~~s a ~~~~~g~ ~di~~~L~~a. 9.llis diagram c~.~hasi~es ~rve:~tations~~i~~s bet~reen pacic~.ges. dotted arrows a this diagram repa~~aent ~~~:~~.~ency ~~el~.ti~r~.siai~s.
°~he soot package off' this si~r~ple ~r~311 is tie one that contains the capsules and classes that irr~plement the an~'rastnzcture supporting ~ 's.~~ automation. 111 utl-~er packages depend directiy or indirectly un~~d it.
~ he package «~p~» 1~1~ ~s~rac ~_~; iew contains classes that define the ~--~-~-I~al~~ assts to access the ir~~~astr~xctal~-~; ~r~~w~~,y. 1~1o'~e "r~~~r the in~st~~cture pa~cage does .
~r~t depend on the chosen BFI.
1 ~~.

6d2 L~~,, ~
r~
"
d's ' , cir' ~
~;
'~~.
, , tr''~
~~

- (~ Model t "~
i Use Case V~sv~ C~. LT ' C ~ ul=~
( ~~ rvtmn ~
93i: ="-'~ a G.n_~--c .onk,_c-i:. .,rvecf -~ Logical View ~
~
L~

- ~ neneac -~o~alroS_~zrv~~~
- ,,~

~ fi,Pi > ~
NE_Abstract_View ~
,'' -~ CLI CPA-Capsules ~
i -~ Ciagrams ~ ttF d ~e - tt Fn s ~-.~ t v-e . , ~ E~ernal_Access_fvlodules, s t'"rcvx ~,_ner_=~ ~ Cxron~ G...,er crsruv ,i' v.vaz-;_ ~.~nr_- ~
~rveW

- ~7 PrOtoools t ~ I

t a Nest Harness _ ~ ~.w Top Level>> Geneeic_C~ntrol Server .: L'~, CPA

~ Hostsln~ 0 ~ .::.terna5_x ~ves 3 a~d~i~e , t1 AL-j- Macros i E ~ ;=rc~m ~ ensx_.
! control ._a:ver~
t ~
;, I

j~ RTCiasses ~
~
i f ~ Component ~.liew y Geplojment ~,Jiew t , - , 'st~eu ~ ' i~jJ idtOdet View: ~
Co~faitimenf ate ~ tiitieeataan~s ~ ~;y ; '-a--e. C~f , ' .,..d._ .y.~ . i , ' ~

a , .-~
~

14:31 ~Se ,~ ~ LtJi~ ~~, ~.'i'b bU!(Lr Ltd allied ErC9r~ ~ ~\ ~ ; (31S~ ~ '' ~' 'Y'tYtd ~ !~ r/~ 2°fIt'f3°j~' ~ :w~ y, ': y~~
J, ~ i ,i ': t; 3 Fo; Hetj? .press FS v '~
~~~a~~~ ~~.~~ = ~~~~~~ va~~a ~~' ~~~~ v.~~~°~~~ ~~a~t~~~~~~~~
'~'~c Extermal Acee~s_~uG~ules ~~<~,k~~c r~~~t~ral~~ d~:~e~d~ ~~ ~y~ac l~c~~
~.P~
~ack~gv. ~':r~~s ~acl~~oe ccs~~~ir~s c~.,~~s~~cs ~~Ic~~c~~ti~~ dy~~~cre~:x ~,~r~s ~~ ~acccssi.~~ ~~ac s~.~rac ~cc~l ~~~9 ~~ar~~$~ ~~~~, cc~~~~d 1~~~,, soc~C~,fis, ~~~~~., c~c. ~~
as t~caa~t ~~
~iuc~%a ~~e ~~a~eb~~~it~~ m' ~~~ r~AQc~~~c~~re 'F~~~t~ac~~.~~ cha~gir~g the t~~.~ ~~d ~h~s ~e ~,~~
~~.ck~bc d~cs~'~ h~vc ~a=~y ~r~wgc~~~c ~h~r.~~ ~a~e c~i~~e~acc ~f ~h~s a ~.c~~~c.
b ~~~$I~~, ~,h~ ~ac~~~e ~'esr rIarres,~ cG~_r>~~~a~s ~~s~ c~a.~~s~~c;~ ~Lh~.~
~frcrc a~scd ~s~
~I~l.Ci~i~ ~~~a~,~ 1~f3'ca..~s~.Yi~~':Ll~'~. ~..~~5~~"iiev,S
'~~°a~l'J~.s'~~~~~1.
i~

b'''°s."~SS~a~S ~~.tzo~'.'.~ui ~~"~u~ ~.~:....-~a!"zl~g ot?~r u'"'~~'.3o'i.-S~~.ir~~ ~~~~:~tr"a~.S nl~~i~ ~~'~.~,g~ '~~.5~~ to 55~.~~ort Si.,~I~r~~ ~gJ~~i1'l~~lt~'?4~3i .2S:~e.~~S ~.T"~ .~~~.ar sr~'i~'3~'a57~°~. ~'~yr r~~"a.li~r r:.~=~r~SS~:Si~.~'~, eaC;
~r~.ix~- ~:~ro~~~t d2~ ~ Haas ~.rs~.~l4 ~r~o =:ir~~~~.~ roe ~~~_~ ss~~~~ort ~;rst~v~~t's "~~~~a -~-~-,'- ~:~C~
tooL~3t ~TJ~S c~~~3io~l~~.
~Li ''w~1~5 S~~vF~Dr°" ~T7~ ~~yi~~ 61~6;~3_~.,: ;=d~
~tI°';,F.ef.,"~x.F."e~"-. ~~~E2~'w ~3(,a"1~''dF~Sr 2u ~i~~
,~,~E~lc~:'~rl~ ~~~'~i~R~ritS
opt o~ ~~r~~.a~t~is °Iorr~str3~~~~zr~ rs b~.a~~~:. ~s~~ ~~~i~~ ~~Qp? ~, tor._~o~m~r~ ~~yoro~~~ sy:o~:~r~r~g rdaor~ ~.rld razors d~r~~is ~.s ~RJ~ b~ ~~~:~~r ~r~q 'w:~~~
v~~t~:.~~li~~~°~ ~~~a-~;°~~~~1. ~pe~~ab~''~J~~~~iL r~~~~-z<b ~ t~r~'~1r1~i~9b~ \3J3.~~ '~~ 15~. : o'" u~ lrltro'.~l~~~go?~. ~:C1 '~Niu t~;%°aTF.3a'$o'o~."~ ~°~~°:'~5 S~°1~;.e'irrt&~°S~
~, s5~°~S~ ?°5,~~r to ~~~t~~5as ~.~r.
'~~~r~ ~-2 s'1o~~ s ~ a-a~~,~-aFr ' , . a ~ ~' a ~e~~c~-~c Cor Y -r s ~~1~ ~t~ . . ~ C~.~~~r~ri ~~r tr _ czol-~e ve_ y~~iS~l~~. .~'~'1iS ~a~SF.~~~ <S sit t=s~ t~r~ !.~~~d~~s ~FE~ t~'F~5 t;or'~t~~a~S ~~~ ~ita'1~r ~~z~SF3s~,S ~lFt ~1~ a.'_1~
~.F~,'Sx~P'~, e.~.~ ~e St~'F;i~t'~,~~~, ~S i°A"~~."e~.rii. ~~~
r~;~.f~m~;,~ h~ ;i~S~rr~a~t ea~'~~lt~;tata~r~ ~9g~:~G.'f'F'w~'~'l lrb ~~~l.~r~,' n JL1~ ~~~'~rFiC ~,o,rog~.,~,,j ~~qt~r~~~~~ FS ~d~.~S>~,a ~~''r~a~4w~1 ~~~
~;X~e1'_rl~lAC: eSSL.WV'~Y' :~,~5~?~ ~~J! ~ S"~~. ~ <:'1St%~i~d~' ~~~ a:~l~a ~.~1'~~.~so~~°.I7r; 3S
r~~d~~'GS~1 yj~ ~~JuyF.liz R~'1~, ~~9~l~or~~F't.
'~~.~s vo~or~r~t r~~.~.~acs ~~e~~.°:~ ~t~~~ u~~s -ir~t~~~~~ to ~~~r~or,:r~~r~~A~;v i'~
o~~r~tF~~fS- ~rl~ 1':1i v~"a1'CC~S 'C~t~ri& Lo '~~a~ ~,i~~l..~~3ry~.t~: ~~~:
~rlSt~~;lC".~, 'y~il~ ~,~~~>l~ ~~bz'1~.,~F:S
'fir y'~~PP'o~3~~~ ~~Y~ ~o_»~ ~~.i~~C~ cp~_cor~tia. ~P2 ~~~~~ ~~ ~~~:~~P~~ -r~~9r~~~L,r°a~:~ ~T"~ ~~~1~ ''~a~~~°~r~.'~ W.~~P
s~~~~ ~~YP~- ~d~~~~~PP ~~?~ Exi;erxmlAccessl_eye~~ ~.P~~ ;~~'3~ CPA
~~~r,°s~P~~v ~ h~~L~i-~.Pa~S~~~
~or'iI'yll~i'x".'P~~;~POP'P ~,~.~~sl'P~C;a'~i'P~.~ ~~!P'P"P~~ ~a~;~aL,'~
~s,~~P'''=_~ ~~ ~63"'~as ~~'.alC' kio3~~~~.
~t :f ~ c't~._G'~lTtSt?
;'~ ~'~~ 'Tngy~~"~el C~7:r-L'trn~t"., d 1W~~'~~~cy ~~._ Ct7:ii'L'f1 _'O~J'l.a-4~~T"U'"~ ~,Cr:1'I~D~
_.
trltav,_C.:~Ini?
Li~~'~ ~tJl'i~=.$:!~i~' t~FJi~, : '.u_~i:_ !', E"~~.~ ~.!=IJiLi1~
~L'~1 L~rl~lil'i_L ij f '~ 3,,~~~'~'°~ ~~~a ~aP~°~~.'~'~~.~°'~.. ~ ~~~~'~i~'1 ~~
':I'Pe ~~P~",~~~~-'~..~r~'~~ ~i~~~-~~,~L~.~Sj~P"t' t~.~f;.u.~~ ~..',~
APP ~~~~ o~~~~r ~P~~, ~a~P~ ~~~ ~~~z~s~~~ =~ ~~~~~~~~~~j ~.P~~
~~~~,~~~°~~~~ y L ~:P~ ~~~~ ~~:~ ~~ ~s ,~ . j~ . . _ ~'~LF~Y'~3~, rr~~~P~~ ~~'-~~~~ s~ ;<s ~t'~Iz'P°~~#P'~?>~.,~~~~1 '~PasE~Pr~.l~~~~.~~'i. ~~ ~'r~rY_tan~~ ~;Jf eiP~ ~.~.~.~s~fp; ~,a'ac~~
C~iIP'~a.~:~~1 ~~~$~~~.~ v~ -~~~ ~erLer,_' c ~oru~L o_~_Serwer G~.ps P=~ ~~~:r~,. ~I'7~:
~~~'~ '~~P~g i~ ..s r~~~~~~:~C~
' "~'~i~ ~or~ is ~s~a ~va~9~ tT'~Jgy. s~z~-a~at?cs.

~~t.~ts ~'g~t x~ gas ~ ~~t~~~~ly~T~;~ ~t'~~~~~r '~~t6~ra ~~~ ~q~.~~.~ tc;~~~9 ~,l~ai~_~ .~~~~~'~s ~~~ f~.c~ ~~t~~
~a~r~ ~~~~t~ c~g~e i~l~ ~~.~. ~~ ~~f~~r~~~~,~~',: ~a~ ~~~~~~Ir;~.
~'~~~.~a°~ ~G~o ~~~~~ya~~~ s~qr~~~~ei~ ~~~~°~~~~ ~~ ~.y~~
~e~~°~~: ~~~-.~,~r~
~i~~~r~ ~-~ s~t~ws ~ sit~~~ ~ ~qt:~~~tcp ~~~~rG._= d~~i~~i~~; t~t~ ~~s~c i~~~~~:~~;;~G~~~~y X
c~~~~ge~. ~~~ '~~~~: Ge-r_eric.__~osl~-=-o~_Se~~rer ~~~~) c~.~s~a~~. ::~t~
ExcernalAcce~sLayer (~'~~,~ ~~~t:s~ ~L~~~~r~ ~ ~~~t~~_~r~~l~~~ ~~~ca~ ~~~1 :~~c~~.~a ~~t ~.'.rt~a~~~t~:~.t~~ 'r.~'. ~i4i~~~_~t ~.'c~Jn~~Ji7~i~r>k~ ~,~C~,~. .J
p~~'~..~Fv~%~,~°.y3Li°~~~~ ~~t ~~tAU ~~~t~~t~t.~..
~T2°r~'~y ~~ ~~~~~.E9 ~, Sa,~~~9 ~e~J ~~'~4n-, ~'Y~'~ ~S~h'.~i..~~' t? ':CD
d:~s~°L:',~".3'l~i~'' ~~.F'. ltlsje.tlG,tc~f~~ ~ S°_:_~~
E:~~9s~~t~~, ~1 E3 ~~::~s.~El1 ~~.~ s~h-Mass than vas ciet~~~Zi~~c~ h~ rh~ ~yy~~. a~ a~r~~~iat~. f~~~ v<pat be~~~,ric c;,lii. '~'h~
~~~~ ~~°a~~s a ~PI~ i~as:a;~~~, ti~~c ~=~ili ~~~c~~~~r~ :h~ re~a:dest f~-o:r~~ '~~~ ~~.~~ r7ia ~~~~~~~ ~.' arvhe ~e~.~ly ~r~ateci ~~~ ir~sra~~~ =his handles that ~~qt~~st arid typifies t~~e ~A~ ~~cn Cd~31~~3C9i~. a~'l~a~Ij~, ~ ~~ ~~~~ g~a~k2''~~ a ~'a.:,~l~~''E tee d1~ ~a~~~~~
"'I'~~yi9~uC,".
'~'h~s ~,~a~x~~~er~t is ib~t~~ded ';~ ~~~a~a~~ ya~~ i~~ic ~f ~h~ ~~c~~s ~~
t~~~ g~~.n~~-i~: ~:;~~t~~i sc;r~rer ~r~c_~ the a~~i'iitecv~r~ ~f the s~~r ~~° itself. its ar~te~tr~~~ aii~~rs ~~~~.ist~~c~ ~f ~a~itipi~ a~~~ss ~rz~d~z~s sir~~it~rk~c~;Asi~ ~ ~,~~y~, ~~~~~~., s~~r~~t~, ~-~.).
~ ~~~~.u~ ~»
~~~:,'e~~.~~~~~:c~.saL~~e~
.i~ r~~an_ ',r __ ~:~:~~ z;?~>>
=~a~'=~ zZ~ ~.a~~~~: r c ~ v.~~ r_~.~3:~
~' °oa~ s~r~e~--..-.., pp ~

~x~t~~'e ~-~ silk's ~~~e str~I~r~;rs~ ~~ dim ~~c~er:naiA.cces~;s~a~er (~~~.).
It ~t~r~~ax~s ~$T~ M~lLipleAccessl~~~odiA.Ie ~~~S~I~!~. ~~~3~ ~da~t~r, ~~i t~rl'~, is in'~~h~d~:,~. to ~ollt~ii~ ~~nu~ti~7l~
~t'_i~',~'I' ~~.~"sTd.T~.2S '~.55G'~ e:~ ;'.yrvlJ~y~~ ~YIr~~'? ~°r=~ ii ~ar~5 'ag~ ~G.r'..'C.'SSl'i?g t~i~ ~~$~(.'I'I~ ~dJII~r~I Se.°r~7~r.
soap_ser~e~' ~~c~r :~;a~~i~ (6~e ~v,.~'~ ~~~o i-yx~;~a~~~~~t~~ a~= ~~r ~'~ar~~~,~oric) r~o~s ac~~;ss ~~ia S'~~~. ~a~5~zi~s ~~r~t~ir~~,d i~ ~~~ 1~t~1.'tiple.AccessModule c~I2~~~~~~~t ~r~e~ri~e di~~~:a~I~'~ il~te_r~aces tts ei~r~ts >~si~g ~i~.fer~ ~t ~~ma~s to a~~~ss t~a~, c~~~tr~I s~r'ver, ~~at tia~y iF'lte;.l:'%&a~~y I3Se. ~~Fd, S~.f°t'~ a~~~SS ?TlG~:r"I~69:i te?
II~~~E:a ~~~~"cllS '~a~~Y~ 'u_11~: ~~a~~$°Qi S~-'aJ~I°.
~'~~ '~~ ~~~
'~~~ ~~~ ~ap5~l~ ~~~o~~~~~ ~i t~~, w;~;~v3~~s se~ti~~ is a ~~Iasi-.,r~~t, ~a~su~i~ (it ~~iy ~~~tu.ix~s a sin~i~ iat~rt arid ~-~~ '~~h~~T~.or s~~~if~c~ti~I7). '~'id~
~w~s~l~ ss i~t~~c?e~:~
s~r~~ as a ~as~ cuss far ail c~ti~~r ~:i=~~s s~~i~ tia~.i ~~~~s s~sta~ces ~~
~.i~~~,rP~t s~.~c;l~ss~s ~ar~ ~~ il~s~~nwat~~ ~.r~ rul~ti~ (~.~~~r~i~I~~ ~~ ~~~ ~~ ,Y~o~~~;a~~~~:~x~
c~~nc~~t,~, ~t~~.~e ti~~; ~~
uas~, ciass its~if is n~~mr il~sta~tiat~,d. '~~~re~:~~~, ad~e.~~ su~~c~rt ~~r ~~~;~~ ~o~~rog prov~c~is anc~:~r i~ar~war~ ~rii~ he r~e~teci ~~.~ a~~i~~ ~'~~ subclass's th~.t ~~~~~i~
aii~w a~~~~~~,t~
~~r~r:~ci .~~II~~t~~r~~.d~ty. ~'~I- ~~a~r~l~:,, a~~ a ~:a~_ ~a~:~~I~~ a ~~~
sub~cAa55 tYlat ~~~~Iid s~y~~~rt ~~t~ ~>.,~ al~si S:f~°M~ ~I~.r~ decide ,~~al~~.ic~ii~r ~r~~s.~,~r~tr~i is~oto~~i g~ Iac foI° ~~.~~a s-,Ip~~~~~i ~~ class.
lriblzrc ~-~ sly~~s a si~l~: ~~~=. ~Fass dia~ra.~. ~'he cuss calhd CLZ ~D~
i~i:;e~°its ~'~°or~ t~~ c:aA ~as~ class, ~~ ~ ~s s~~.cn~ i~ c~: a '~~
i~a5;:ar~~i~:~cd t~ ~cc~~~r a ~~~ slat (sic ~'I~d~I'~ ~-~). C.~I~CPP> ~I'z~y Sbl~S~~rs.:; tj~'~~ F.~u.,~ ~oy'I~:~to~' ~9r~~~G~r~.

r~ ~~wi~~ 4.~ (yes ~~r-si~l~ ~~.; ~ri~ ~~~~de'=~, e~~ ~~~i~~ c~~ ~i~a~~rFrr ~
~~~ :~i=~~id ~~a~di~ ~r~~, I~T~.. ~~ ~~~'ai~s~ ~~~s ~~%aa::, j°f~ ~~~~~~. ~~r ~,~r:~pr_~~i~y, ~a~: ~~~se ~~ ~~dic~,~e a c~~
i~s~:~r~ee ~~r ~~~I~ i~~~. A~s~, ~~ gas s°~.id ire ~eA~~i~~ ~-.~. ~a ~.~ ~.~.~ biasses ~.r~ d~y'~i~ed ~r~
~~~_~T~-~i~.ss basis. ~'~is ~~~.~s ~g a~ r~~r~ sI~~~Id ~~; ~z~ ~r~~~ ~ne ~:~~
cuss a~~r ~i~ cuss.
~~r ~Z~_ca~~ ~,iass ~vili ~;~ ~~~v s~~w ~~r ati 1~,~'~, ~ia:;ses; ~Thi~r i~, :~ c~~n~lia~~-. c~~i~~. ~'~~~
dTs~ia~~~i~~ ~~~~re~~ difr~~-~,r~~ ~,T~ ~~~ss~;s ~~sii ~~ .z~ade ~~~~i~~ a:~~~
~~~z c~~ ~~ t~~ ~~M
ie~:~~.i, as ~~~ia~~e~~ ~.~~r ~r: ~~~js s~Lt~~~.
~'~'~~ ~ x~'11S ~=8 '''~3r ~73~e'.
~~ Cle~B ~C:r ~,y~~ ~:.~'~3 !
«G~~su~.~~.~ ____~~_~~~~a~e~~~c~ x~rii-h.z~~
~-'~'~ .~~ ' i.~2e 3~;~~s tr~r~:.
~_..~....~
i~.
r ;~'$Ws aye ~~r;~~~rt~ ~"
n~ ~s ' la~.~t. r i~Lt~'3~'L,WW,31 , 1 i~?gur~ ~-~ s~ao~,vS v~~ s~:~x~~~sr~. dl~~r~~:z~. ~~ ~.i°gP CLI_C7?.~
~~~~s~i~;. '~~~'he ~~~~ ~~r~
cc~~~~~~s ~-e~r~ser~f~d i~ this di~L;r~~'r~ resealed i~ s~i~u.-~ 5-~ ~r~ ~~~e 8~, ~a~i~
~h~, i~~L~~ ~~rr~~~~~ra~ ~r~~. g~z~; '~~~:-i~~se~~E ~:~ra~~~i ~ii~r~. ~'i~.~
~3~~d ~~~~~ae~n~ ~~ t:h~s , a~~~~ ~~~ S ~~~~r~~y ~~~~ ~~~F 4bis6it3S w ~ ~ ~~~~~x ~~ Vr1iu11V ~r'~~~~~~d ~~l.~r i~ "~~.~s 5~~~,i~i?.

~f~~ ~l~G2a~ ~~.SCC~ ~ i 1~i7.~ ~ ~a~s ~ s~Tz:~~~ L3.c:.: ~~~
~'"$~~e.~~~,t~$~5 ~57~~ ~ t:~~-~-bc'3,~v~~
s~~si~i2 ,'~'~";IP~? ~9~ ,~~~'$~ ~s2L~ asj~~~i'~~~~~7~.lSiy~ y~e:,&i~=W
~~2~r2ct~9.'~ ~~.~'irigb it. ~.p,~~r~~f~t~t~t7%i ci~t~iis ~f this ~,~r~p~a~~;r~t a~~ i~~~.i~~r~,rt t~ bags thesis ~..~a~ Eh~s =~i3i ~~t ~e ~is~~s~»~ ~.~~
~u~r.
.~~~~°~ ~9~0 ~~~~-_~"~ s~~°t~~t~~°~ ~~~~~~:A
'pig ~ s~ ~c~~.~a~~=~~t~s ~gsb~ t:~~ texv-~~se~ ciie~t ~i~ three s~~~r~t~
cc~~a~a~i~~.ti~r iir~es: t ~m fires ~~r i~p~tl~~tpr~t ~~a.~~.~~:~rs ~.~ta 3h~~~ iir~~ ~J~
c~~t~~i c~~tis ~C3"~.T~.f'~6:=~s~. S;~ilY"~s.C'~~~~''i, ~f.~.
~.°~IAr:~.,~°a~'~,D'2f ~Le;stL?'.yy ~,''._.~'"~.~'.
~~t~ t~~.t tie ~~~rgp~r~~~t ~~~-es~.f t~~~~ ~:ia~ 3~~~is ~~-arw~a i~ ~i~~~.
'i'~.is ra~e~~s t~~.t tg3e ~~~~p~~e~:~t is ~ ~l~a~~~ ~°~;i~. :~f~~-is= ~~pu~i~ :ages ~~~
ya~~h~ic~~~°s ~~~ ~ria~f .
i~!

C~P3:~~~t~'~'~'s°~ C~g~S~:~C~, ~.n~ ~I~'~ '~tSed h~J°YR~~ ~~~e C~"~5~:~~ C'~~SS t~'i~t ~.sa t~ ~CC~~~~ t~ S3~i. ~S
ns~t Psne~n at design bane. ~.e~en~~e~ brat tiie C=~z ~~~ has t~ dete~nir~e ~aiai~i? ~ sM
s~abc~~s~ to instt~=~:~e f~,~n~tp~~ ~i t~ge ~~:ve.;~ ~~~~~~s~ s nd ~~e ~:o~-~c~x-~e~ ~.i~el~s . ~x~ce the ~~Pd.~ class dete~ned anci i~~st~nti~.i~eds t-~at P~~P~ ~nst~.nee fs zt~r~~-te~ .~ that plug-in c~.ps~bc .~o~e. 'P'~e Factory ~s ~r~c coi~~~n~,nt res~~~~s~~ie o~~
dyra~~~~ic;sii~g.ca-r~ni~iag~ end inst~~ti~tin~ F~~ cusses that =~ailx '~~e ~~te~- i~s~p~rte,d t~ tie ~ Sl~~
pi~~b in aoie.
~~~ ~~~~~~
~~. r ~~t c~,~onent y~ ~~~e~~dv~ ~a ;~ ~~se c ~ s for' ail o~~~e~ ~~~~lis ~~esp~1~~~~~e ~~
;~er:F~~rr~ing ~~.~ ir~ie:acti~~~s. at p~es~ides tie ne,cessa~y st~ructr~~e ~.nd tools descried in Sect~e~ ~.3 s~ ts~~t s~~~-ci2sscs ~.~ nor ~r~~rc so ~-e-~~~ce~~t ti°~~.~v.
~a~~~c ~-'r' s~e;ws the ~tct~:~~E; c~ r~E~ .~ szul. ~~ii ~ S~ ~a~'o-~.i~s';~;s ~~~s Gwill h~~c tnat st~"~.1C~~,Ls°~,, a~t~9~~~'~~~~~13'~C~~h"S~ ;:! C~ C,~SCe~l~inm Soil:-C
C~1~~9o?9e~:L~ ~'~g'y~2I~:S :~SOSS~~ae. ~'~.e inCl-~a-rs pout ~~~~'~i~1 ~'e~~~~~e~: ~~l~r~'t~~s ~5~3u~ ~Y~~n tits rro~t based Cli~~.'c~ is di~e:cts~ rennecte~ ~-v tie ~t~v~i. _ ~~e ~.~~~ ~iate~s t4~~t v~ar~ct~.~
strews and sends triggering Y
s5~ri~?f~ v~:~ tile po~'t fsm corcun, ~t;~~~'' ~~:~Sn~Ctecz ~~ ti9e po~~ .-r~~~~~p_co:nm. '~'~~e ~'~~M
receives ~eq~aests :~~om~ tild Cr.=_C~aA ti's~~~ii ti~~zy cpa_comx~= post and fiends tex~~~
conl~'.~~~e~s '~x~. t~'~e ou tChars p~~''t.
1 ~ccord~~:b to IJl~~., a co~npati~~c c~.psule is ~ sub..class t~~~ ~oesn"2 e~ce~o~c ~r~y co~~ec~~.c~ port of trse parea~t capsule. h o~u- exarnp3e, F'SM~s ~~on.pa~i~~e ca,~sules are ~i~e sub-gasses t't~aE ao not exclude anv of the ports _'_nChars, outC~~ars, c1; encCoi?trol ~v~~l cpa-cemm.

~ he ~~ 'T~ ~a~s ~~ i~~~~~~~ v~ ~~_2~ ~.~3~~i~~~~a~~~ ~~~~~~ ~xg~~~;~sa~~;n ~~
~~~~~~ ~~ ~~.e~~
vie ir~p3.~~ ~ha~~~~er st~~a~ ~.b~~t. i.';~~~ ~~ ~~rpj~~I j ~~~~ec~ w~~gr r~~
~~~ ~ ~~~x~~~s a :7.~tf~ ~tC~.~~'r ~~'~~.~ a~'a~~ ~6i~r~~ Is ~~J'). ~,~'fd~~.y C~~~.~ ~.~5 ~~~..i~:i ~~~ ~~~~d~~,~s~Y~ ~ ~D~~ ~~ ~'ly~~~~u~' ~wC ~~
~~~.~i ~~~~~1~ ~~pg~~~~~r~9 ~~.~~~~, :~~'~~~,~ r~ '_~~ ~~.;~I. n ~g~~v ~-~
~~Llfa ~,s ~ s~~a'R~~
~1? ~eracgi~r .
x_ ,.

' s < .
x 1 . i ! t 3 :YDY1'Gttgrt~~ ~ ~':::r'%;s.~
j ~
:
a~..~:_ ."' ~S~'_I

.-.._.

P

1.~: ~~YtOi.~:.EC L~i~?'~7 'y-',sib ~ 3iltJQ't3.lC
t'lre;t..
;~C:~IaCi~~
'i.rl~'_F~
z 1. ~: a'tiJ. 0 u:f2 . '=~~':=':~.'r_.~r_--iL EtB,DC1:~..'~'.ea . . j 5:~~~f~.s~. 112~~~<S

r~wyCl ' ~
.

3t;r,r'u 'rg c~'~S~r;C( 1'r1~?~~~~"~~ ~ ~,r.yl~ E:aYf,~.~~'t~C
_ ~ i L,.'C?:~I1 7~iZ~

3 r-- ~ ~ i'~C~'vi4.'~?Lia, a rCBPC 1''L ~..'C~_~.i~
.._, '~ L,~2~ 1.~'''LI'~
' y;l.:L~w r~.C';E ~~ "e,:3 s~"-,--~~ G ;3cA'z 3 ,: ='~G ~lriG.
~
i' d CCIa.:~~ ?.C2~~C ' .. ..
~-~ ~ _ c a ;w~itu~,k ~ vz~~ c~f,.r i.r_. ~~~a~~d in all a0 ~.1'4°'C
t~_ _ -i _ ~~ i i~S ~0 C:ilBC:~G w~0~ L, sld~~Ci::.
~31t7. vu Or:
i .. ~ i ~a3'~cl.'r:C~f~~~~~~> :~Y~lgrf a: 71'f7.~rt;. ~g i~.rtW_~yx C;2f~L~;~.~., ~~1.. =:'~.~x~~ a1C i' ~'~l~1'L8~'fGr°..C~. ctrBCl ii, t3 l~'c7YfC°"°l. ~'~~:i ~-Pxff~~- 1 t 5~1'l 1;.J 'C,~.Ah; ~t?~L1-Z.i:3.y''W
E ~,..~ - :','.'.~'.~°~.
~'. ~. '~. .~~afd ~fi~.~C~~?in~~ ~uJ~:~v_.~=i;~:~a ~.a'~~.~ '~-a~~~~~;:~~;'~~~~~~-. ~ ':~:~e r~~;~r~ rrfotres e~, ~ rm~,r :r;tat~, ~:a.~
?x5~t0.,~.'C~~ _rp ", ~ ~ ge~~" aatl~:i.rf _~~~ _w,.~ts ~:~.~'°u.l~ ~ta rFn~ °e~:rvar~ ~i Lid: W rw s ~:::47 :L. ~.. 1. ~~: ~~rld ~r_, urc . . . .
~:i'~~.~.P ~i 'v'iJt'9~ ~a.f~.'d' ~i'~e~i ~~'~~.' ~~~i~i 2S
~N~~~',J'iv°~,.ta ~~- ~::W s ~~;:i.~'s~ S~J~';:2 ~T~ ~~~~;'~irw ~~'g~~".R";1~~~". ~,..~..iGii, ~~1~ t3~c~~~"~.'~~,~ ~ s~~,~7~~~~ 3a3:i' ~9~,~~r ~'SL<~t ~51~9~~~~;~~~,~. ~'~
9~ ~ "~~r~~~ctqJt01" ~E.1~~~~~'1(~S'pr°s ~'~.3.~' x S.L~I
F
~.vf~~.~d~S~.~~ e'~~?~ ~ zC; ~~?~~~~' u:~ ~~5~ ~z~~,t;~s~e~~'~~~' ~:;~~~s~~' ~~~ ~~ s~~~~IT~S~ ~~~.'' g~~:,~~:~YY'il~'~iil~ ~~i~~~~~

s~,0is~"~°~.,~:.b~hl3 St',~z'da'".S OI ~~3~'~, l~:~w-~;~t~~C.~ C"
_7_~~7L ~.~. ~~~t'?~~:~"i~~, v. -_'i;s ~~36~2~r COF'_~~~s~:°;:.
',9~°
~2'°~.C~. ''~:C i'~ ~S ~~~'~~a~~~ ~~~t"~C.'i;~~~~'.t.~ ~i~~;"f~ _S
~,fy' ~"~~,'~ ~n' ~.C:°~ 'Lr~ 'e~FL~ ~,~i= ~''~~~ ?~fA~PI~S
~9'L!~~'';~~~' '~° 5~~.~~ 0~2Y'a.~~10r1d_. ~.~.'~'eaa~~ r»<~~; ;~ i~_O't~'u~S s~ c~~
,~~~.LV l_;~~~:0. ~.Al~~.r~. :~i~ ~~~i~~? "s:~ f ~0~~.;'~ 5~.~1:~~~a~~. ~Og:~ ~"s~~~ ~~'~ 5~~~~;~~ ~.Og~~.'t ~..a~~x. 0~~~'fLi~
~_OI1~.L ~lf~: a~?~E ~~"~3~~1 5 ~~.~ ~~E,~1~' S~?~~13~d~°'~a~'_sfy"~ ~s.'a~'a~,~ is0' ~ 'c.7 > a r~ Via- s ~ "'fi ~ b V c E ~' t~l~ ~..~5~ ~~, ~~ga~,:~'y ~._a~ z,: ~I~r~S ~~_~. ~ P!' :~:.~~°a~:"y~~
y~
"v~~..'~;. ~~'1~ jJY'C_'_=Tl'!~~L"y-_~~~2C:~:> '~c.':~, a~O°var~'el~,ri" ~~C_~C:YS S~t~~iC~(e'~~'au ~:?"~~~'"~~~~0~
cldl? r'~ iryl~ '.~~X'i. ~:3e~SC~.~C~ 7_°Y1'L ~fi.~ 1S i?~aF~~
>~~~° ..~ (9i '~~.'"~~~ ~'Y~~_ ~:~~SS~S% ~.'~~I ~~ (.,,~~5~'~, gS
~~ti 4~ Y ~
w.
~~:.L~Tt't~.l"«r~~r~~~ e~ iA~
r7 _ 9 ~r r Y
t-~-. ~O r~ , ~ lv ~,~ _ts.
_'c>
5. 'k iict~~ ~ y~. ~=:O'?1:#'~,~ ~ ~,:>a'sifl t~ ~s~ ~:~ nct~3 a t~ v~"~~.,s"
?'q~'~yS.~
9. i y ;
., ~~C7~VYtu~'~',a~ 7:~t2.''T~s~~.~t~ .~it~.G~;f1 '- ~ ='-'fty7.i.i_ S~ y- '~.'it>_-°:i~~cGLf.
-' ~illi~°~;:. ~~~ia "r~'~t~~. ~s,~'~ a ~~ ~O~Lz~~l~~9E"0 ~"'~~~ ~,~~t ~~rr,~or~e=~t ais~ ~~~~ricies additions stags t~ i~d~~~
starac~a~~ errors. ~'h;, sta~~ handl -disconnection is r~~ch~~ it t~~ ~~~re~~iv~ a~ ~rr~z slg~ai ff~~r~
i:b~
x Tex~ base. ~lienL ~S ~. h~sF~gf ~~ s. ~:~~,~~~~ti~~~ joss. ~~b~~!~.ss~s bate ~~~ ~r~~~~ ti'~a, stag Haiti? a~~r~~riat~ b~.~avi~r t~ ;~,a~~~i~ teat ~~~r :.~~c~rdi~=~g tee tiFs;ir r~c~~~ir~rrF~~ts.
~~vCF~.a ~c~rC s.~~.S ~:.%~o ~:~~~ ~..~I~:n ~~ 'E7C:'FF3tatl~Fg ~f'2~:
~'~~S:f,o~Fn~Clt9'CC~.~~'9eF~g2F~~, 5~~~~.
~FZ~L~,d, 3~ ~:~~~~ld bc, r~.t~~~F~ n~ur~~~ st~~ tc~ ~~ss~~~ ~'~~at t~.~e ~~sagFg~~ ~T ~. sgv~eF~ ~u:~~ gill a~g%sTCt~ls i'la~la. a ~~rr~Ct st~tC'°tT'aFlsF-iFL~.YI
s~Ic'~,g'F'c'Fr%°E ~F~'~'xb3 t~~ Abut t~-i7T??~,. ~'~ ~d~,?"~sS 3~'aiS, z~lo ~f~.txS'c.'F' $~t~i:CCt~ E.'rF'or r~r~ :~~s6~San~?i::~ ~~ ~a~.a~.'.Y.~~~ ~Y%' t}d'aE, ~.~3to st-iCt,'S ilarl~LC-~'tlaLC,'~? ~Y~
nsb~:~dle in~u~.. '~'~~~se s>~at~s sA~~~~~.1~ ~~cv~.~ b~ 3~~.~:_~~~ r~ tb~
~~~i~~~ is ~~°~~~~i~ si~sigi~~;d.
I~e,T aF~~ ~r~i;r bei~~~i iFe tb~ ~eu~i:~?~~Fer~t~debuggi~g stagy at~~ sh~3~id ~~t b~ 'vs~d ix~
"~5rod~~~ ~-~~e~.s('.
'fin past, t~~e hand:~e r~at:~~ st~.t~ is F-da~b~d i~' tb~ ~~W at~h~;s a r~g~iar v%~3T~,'~u.Sjord L~a~, do~'.s~'t J'o~'r~,'s~9~~C~ to ai.:~1 ~,v~tb~,~g:g tdd'~Td_SFtIC~Y; ~F°~'1i7 t~xYp. ~.T,~I"rgF~,~. ~>~G2'l~
~~i.Cl:~ C5~'~71~t3d'3s a',~'F~ ':e~rll~:: L2PeXpeC ~eG~l,_ S:~a ~~ -W'l~
a~ll~ t.;°a1?sltlC3~~: d~~.~?Frd~ ~f9 ~~'~s'Ft sLe:'.t~~. ~k ~F~ ~~e~i~ect~d s~at~is der evt~a, i~ vs Ci~~=~r a~_ ~'~I~s design ~.r:ar.
~~:_~h a~ ~rr~r t°~pi~~.ll~ ~cc~=rs irz tb~ f~;i~'uing siE~~:atic~r~:
"h~ des~gn~~~- ~i' tl~~ t=~~~~i. r~~a ~~a tvgger a transiting ~ ~itr~ a rug~iar ~~~r~ssi~Ea ~. .~s ~xE~~.~Pc~. ~ar'.i~ry t~~is is a~~orr~~iis~~ '~y r~~gn~~.g t~~e ~;Ss~rC<at°Cin l' , s:~F3af ~~; ~~~.~ '~r~.hv.~~ a~ ss.n~l~g t~~~7~
tF'~5~'.~t ~t"9 ti'Fs:, ~~.'~~. r~-'~.s:
s~s~n as ~~~~ 1~~ ~~,s~~_~as; F~jatc~:~s ~~., ta~E~ ~-~I~i: viii :s~r;~ the sig,~~ai ~ t~ ~.~3~
__1 I~l~.x~, ~id~~ ~>~si~r~er ~ v-~r~e~~s,i~ ~~~-ird~,v ~I~~ »~i~~er ~f 4r~gnsiLi~~a ~ as s.~v-~a~ ~
~~i~h ~ ~ ~.~ ~°ds~e~.c~ ~ ~ si~~dai 1~~..
r~~s a ~~rds~~.v~~~~~,, ii ~~~q~ ~~~E~~l~~~ ~~p,~~ssi~r~ is r~~-4~~i1e~4 ~~h~
~~~ ~riYl s~.~d ~~~~
sib~~~i_ ~ ~v~ she r,~1~7 ~h.ie~ ;:p~~r:sib ::~" 1~ ir~s~~~~. ,~s~~~~ ~~
hi~~bc~~~., ~_~~, ~~l~:i e~d~crs ~~~ s~a~~ handle_m~ ~ch a~ ~~d~ dFcai~~p~s ~~_~~:,~s a:K~ err~_p iri~rr.~i~.t~.i~.
~'Y~e s~a~e .har~ci~ e_in~ut i~as a sE~~aiiar E~~~c~i~~~ali~~~ ~~ t~~:~~
~re~r~~~s ~r~c, ~~~ ~riih a s~~ti~ ciir~~,rei~~~. ~.c~~~~iiy, r:~ is ~ ~~~ :h~~ ~er~d~:n, ~h~ 1~~~, r~.sp~~.~~J ~.~~s~~'c r~aa~.~i'~ a~~~ ~~~d~.
.3 ~.c~i~r~, aiit~rs ~ri~l~i~ ~~d~ R~1~:!-" d~d ~~~a~ c,~s~, A_F~s~ 1~:~~~
s~~.~.s ~h~ sign°~ai v.n~~p~eted_zr~p~.t ~.rd~ i:~~de ~ ;~1~ ~~~~r~s ~,~ u:~.t~ handle_inyut.
~.,jair~, ;:iris is sy~n~~~~~~- ~. ~:~sig~d ~,r~-~~-, sine, ,--w ~~:ii-~~si~d~e~ l~~l~/.i sh~~:~~x hanciie aii p~~si~vle I~~L;
r~s~~r~ses., aid '~i°~~ l~~i~ ~es~;~.eu :i.~r~~~~~v; i~.~s ~c~
~~~~~~r~sE~~r ~di.s~~.~~-~r~.rasi~i~r~ ~~agr~.d~~
~it~: ~~r~.
is a~~t~~~ess~zy '~~ ~d-~s~d_j ~~~de E~iJ.I~ ~~~rd,,,~r~ert~
i~~dteu~.~.~~'~aiis ~i.~~ra ~~~,a~ ~~s ~e~i~4l:~r z~'d~.s ~c~$°~ ~,~ad~~~' Csv~tv°&.dSS~'~,'~. bl"~, zh~ :~r'~r~'~.'S s~c~:d~~S. i.~'°~.~J'',,~d'e ~~-~~ ~'~ ~w? ~~/~=.
c~~;~5 3 ~ ' F t ~da~br~.?Y3 Aa9~,~ S~3il~.rda°S ~s'~~; ~9re~?~~:~.5 sc~~La~D;.~,aPlCM
~E'Ve:~ ~. $~~~~s~~ ~:dn~ra~'~,~2L~~~ Cyc~~'d'~gf:'~d ~~ i-~e ~~r~.p~si~io~ ~~ ~~~~ ~ra~~vu~r~.
' ''his i7ap~P~s v~~Ce~ aIt ~~ni~e auta~:aca {~s°d tc m~tc~ re g~.alar :~~~ress~a~s) v~~~t~i~ ~~a~ Rah:, are ire ~ ~aiiurc sate. rear exa~ns~Ie, a cor~~ieae ~'~ :i.e. az~ ~ ~~ ~ri~4g a I'ai~3~re scarz sucr ~h:d~ is ncE~er i;Iacks) pat recognises t=r,e cnt~~ess~ar~ "a'~'cc°' ~vili c.r~ter a iaiiure sa;:e artcr recev ~~irFg t~~c se~uerr~e "a~z~~>».
i~~

v~;Lfc~.'g3V 1.~.~: :'L"D~ I3ve.T~.~..~~
~~n~ri~.. ~Dx~j~rr~l ~~r~~
.: ..
',., ~~' ~p a ~~ 3~acrr~ .:~~'~LT~'~'3°.~~
i,~;~~.p~xt~~3 ~ ~~a~~s~.~2?>
~xrna~c~as~a.~~~r . < ~° a~ txl.~ »' ~.J:~Z- I~L~i~. - , ~' tac~Dr~y,r~' ~, , '~~,..,;' c3..ier~t.
~,i; : ~ ~~~n'~
~ ~.~~~r~p , ~ ~ ~N~r A,~~y ~ ~'~~~ c~ -~a~~d Cli xtv~
~FD~ ~.~..~ C~x~7S'17.~..8= arB '~-~.
~i~~laya~ _rmre. C~Iy ~~xe ~tai~ # ; J rest nd~°,1D.~PS ~.r~ latC~.L~.~~~~ ~D'~
~7_ar~ ~.;: a.~.J. ~ or ~. yey~tera?_ LTUT°rC~'?~TrF L~ 'C.~12 ~i3G~r~'~..r~~23t'.=x~ ~ ~ ' 'C,I=~at.~lg~7"~..e~, yaps»ye ~D~zt~a_~.amenLS_ ~ .,~'.~',3tx ~~~~°~ ~-~o ~'1~ ~a~~~ ~~~~ ~r°~~-~a~~q~~~~~ ~~~~~~~~~~u~
~°~~~t~~~~~~~~m ~~~~~~'~~~ ~6~~~ ~~~ ~~~~
I'~~~,~ t~c~ ~'_~e i~~-~r~.~~~~c~~rc a~ ~n ~~~c~., ~~r°~~Ic~cn~t~g ~
;:a~~tr~i servace ~v~~~ sac ~~:c~r:_~~F~~c,~ a~~s~~y ~r~~~P~ ~~~-c~a::<it~g.
n l .t ~-,.
'4 ~' , y.~' P
f °~~._.r''I~
~_~rs~i Tr':.' ;''_'L. .,~z!~L~.L'i~t~G';-rs=~~,5'i !~'iiN:'.R~~h'~~.i~~"'ii:v z':'t'S5°a ev~.'~°tu'','.~.:~'~ f' ~ii ~r?i . !:~?~L'$j'! ~'~°~~;'::' :
.2''~E'Y'8~". L'i''Y' : ~~tE:i,t~..iC:'-,'.! ai'..~.'O~ v : t''t7i i.:~ :
32'22.
'%'_°t.°.~G'~°G~~l'~;'s.s''''rr?_Y° :
k~_~'..~LTP_Y', a/'c~'.'..'~::7" . ~:C:vr~n':. Ci;~..s:.G' . _.._ "~~r7r'iC??:~ ~'..lny°u : .C'n:I=~,~ : .~.i.?
.. S'~_.L~i~7:~~=G~"'.i if::'t1~ TI:W ~z~r~2:i:c".~'E ~r.7.LW;r Ca~~.u~'.~.'~ ~' ~f~c~ ~h~ z~p~~i~er~~~~ ~~~~~~~~~o~ s~~~r~ s o~s~~% as ~ p~oof~~b-~:oa~~~~t ~~~io~y~~~Y ~2 ~ms~'v ~~~~.ss~~ i~ ~~~~s~. wry ~~~~a~c~~~r ~~~ ~j i~~ ~~~r~xo~ ~~~i~v~~~,s.
~z> ~~~~r~~ '~h~;
~~a~~c~;yi, i~he ~ir~~~ 3~~~,FE~~~.e '~ro~.~~ co~~sis~ ~~~ ~~ s;n~ie o~~~~~~or~ th~~ ~~~r~~~s '~r~
~;,-~~ere~~ ~~ c'a.~s~s. ~~ c~~~ ~~s~, ~v,v~ 1~T~ ~~~sy~~ ~: h~z~~l~~, ~<~~~:~1 <z~o~n~xy ~i~~r~~i ~-"s~~'~9' ~"1~ "~".~SC~'J ~~~~.~~'s, ~3C~1 ~$~Jv ~'C~s'~~f:7i C3'5~.'i~~.3oC°tS ~.1~ ~J,'.~3~o~~~i~,. ~~~x.~.~C.' ~SRI~ 'a"~~' ~~~ss~S
~.a~' ~~'Ia~,~3~~ gC9~' ~3i~i ~°,n.:~.~~'1~3~~ ~1~~~ ~:~I~~ ~t~.~'~S~sS
C~~~;~'~i, ~''~fl~w~a~~&~ ~~~;i~, ~~~ W~~~~ Gt ~~lY?d;ii~ a~

~S ~&~~~?~c~2~~~ SC~s°v~. L~c~~ a?Y~~9s.~'~x'1_~r~~~~;'s~-r~I3~~
'°~RJ~P~ ~~ ~.vl~~L~E'~~~? 'u~'~ u~~'i~ r".~~~~.
S~~~h"~~.
~~~~,~ ~~~ ~ s~~~a:~ a ~Ji~~~, a:~~;~r~s'~~~ra~~r~~~ ~~'~ ~~~ ~~~~, ~:W~ca~
~~~1~ i~~~;r ~~ ~~~~.~~~
,r~.~ a ~~~,~~'~, ~~~~r~~~c; ~s~~ e~pp~~e~~~~ ~-~ ~~r ~~~~ '~;~ ~~~, :~~~~r~.z~.~y. ~r~s~~.~~~~s ~~ v~~e ~~~ss ''s ~ x-E , °'r" ' ~1~TE l~da~~e.~ Jd~la ~v ~t,...~ ~~ ~~s~~':.:~'~'~? ~~r~~~~~
~~°~~"~~l~r9S. s ~l~ ~~~i~ ~~~;~~,r~v ~~~r~~~~Jr~S '~
crew ~e'I'C ~ ) ~.~'I~ gel a Ce'I'C ( j .. y'yw~~ ~'a'~r~~'~~~~ ci~~KwS et ~r~~~~~, :.~~~~1~<3r31~~~ ~ a ~i ~:~~i~~
Wi ~3~ ~~~a'T~~~~, F~li'~I~~ i~'°t~ ~~~t~~" ~~~~~~5 ~~. ,~~ a~~ ~ii~
ryl~ur~c~~~ t~ ',~~drC ~~T ~~. "Q~s~~~~l:°Y~:, E~3~
~2i_~'i~'~~iS '~~z~a.~'~ ~''~1 ~~'3~5~,' i:~%er~ ~~3w;~°~'~~~~rlS t~.«%
~~'°~"t(;:~'3C ~(~~, ~re~~ ~"~i~~,~'iS~ ~~ ~?a3.~ Sri ~C~L'~S
~~"T1~~1~F~~ ~~~'~t°?'z~ ~'S9~-ve,~s~~C:p~.~F i..,~.a.,i'~~'<
'~~''.,~~~"., ~~5~rsa~m~~2~s ~t~~'.~ .:~e"$iCi3 '~"~=P~~r":~,~E, a°r""C~i ? p"1°SS~~vS ai ~~"~~ j1 L~~.~.
~'~ 3~~.~~ ~"~is s~~.~i~rx ~s ~a~~;~e ~s ~~,ss~~ ~z:, ~a~~y~~ei~~.r~~~~x~,_~
~~~~.E;_s ~v~~~ ~~ ggver~ ~_~r '~°r~'~ ~~9u ~Iis. va ~~3~ I'~~~ C,°~~SS~S, ~~~Lak'1~3~
:~~~;.~~~~~'~~,~ ~33~~~r! L,~~~u'~,1~'~ry gyrlfi '~,%~~iA~ ~3~ ~~..le~in~jl _22~r3~i~I'~~a ~~r Ei'~~ ~z~~r ~~SS.
'i"9~~, ~irs~ s~~~ ~s ~~ ~e~~-~ '~~° ~';~~!~ ~i~.s=.~
~:°~°~r~.~ ~~r ea~::~~ ~~r~ c~~ss. ~~~~.~F~~, ~-~~
5~~~9'~TerS ~_ ~';~~5~~.?~i. F'DRY i'~cc~e 's'~S ~ i ~ r ~ a ~~°o e' ~~ ~y~_y; ~~~ =w~~ :~~~~r~~r J ~~~la. '~'~r.~ c~~ss ~~s ~~
?ae'~°a~i~C '~~~~~ FST~'. (~~5~ ~~uSS, ~?x~~ ~e~~ i~~'1~ ~~''c"~e:
C~~fl~~r3 ~~~~u~ll~r 5~~~~'; ~S ~~'"a'~.~.: i,~~~r~
r~.,~,»~c_.xx,.~I~aS.

i 1 ~
~',al;v.~3~L1~~::ktl~'~'i~~ i'.~CSlv~y 2u 'v.,~4iC ~lr~
~___.____.C
f C~3"s~ LCI~ ~~.~
__ ' v..1 ~'~t'~~ ~.~ 'iw"'~~ i~~.s~~
a :.t:3 ~_ ~ C~ i.° ~.~ ~ ~' c~L~:>"E r_~ ~'y w l~Ci~t 3331r~ : :?'i.~? '? ~~ .~ ~ T',~wi_'s~S I'U ~ n:!'t ~'Lti7 b°t::
aJt3~d~~~ CtLY3.t,'.C ~'.'3.'~"'~t.~-_,_ ~'' iJ~i ~Ct3G~ ~ f_YyIB3~CJ2 ZQ4'~'~Y3.
_ ~:a ~ iC..L.ii~.~':s:~d~~.
~; .~ ~ c '~ °Y.~a,.~ % ~
x-~'~i ,pf,B~YYj,E~' :.=.y~l~ta~~:'..:
~'~.~C~:~' ~4=a~E' i CCU~~%,~u''.se~f;> ~ C :~iz~t~sL7.~.e>?
,%

~G.JSL~~~. F~~~-~~~~.~~ il~,L:ls2,..~°~~J .~~~ d."e_'t~~l~
_li.l.L',iJ.tlY ~f~.SC .~~ ~~~~~ ~~. s.~~~J~e9~ ~'..:.Y~
~~ x~-~?~1~.~~i'%?~~e Ca~~"~~1~~ ~~i~~irs:i~°. ~~~1 5 5 ':~9~ ~~.~SL:~~
~~~$ i5 ~c'_I~~ ~~ '~~ ~5~i~~' ~9c~~
Ci23L2TC ( ) ~YoCi Q°ieGeTC ~ j r.-'~.~"~Id,~aas. ~~ Sl~~zl~uF°
c:aZG~~'c2':Ci1 ~S 5~~~'~J~2 ?~ ~''~~~i"~ ~-~~-F' G 3S~'~. ~'~d°3~5 ~~~ 9 it'I'~wsa:, 3S ~ i~:~3~..."~s~~
'~'v'~~yj' <:~a~3SL~i.a~.. ~~'" ~'~C~? ~9p9~~vili~I~.
r~a~.~;;~~rn.iruc~-f.a,sLr.cc~°sf~a'~ ~~
_r c. c~C~ j ~ -- --~ _ 1 yM.~._,~t~ f 'C ct ~.t. ~ ~.2YL_. r._''' ~S ~ ~ t7. ~ w..'-,_y' t s..._ .~~
.'l~.iLS~°eyGE. ~~'I%_:C~Y C :: ~CD'r ,f i _ -j.Y_'L'1 ~ ~ YI C-t' ~ f~SYLv l~ ~ ~ ~.~~~~ ~"~ , ~~rf rl' '-..',.. ~' .~..~ , t ~,.
/ Eti__S7tG~'? :~~L'~~yr (~ lffl ~,yi'a~ 7V~ Cull~'_G~ O~~ .Jb.~~ ~,,~ i ~--~'~'"'~~w~,ei'~~~,~~'~33rym1G,!t~.~.~
~ i ~~rn~. ~ e:~.i~
C.~,a~a ~~ ~.~ =.~JC.tl 2W ~ ~.~~~F_?rf > Oi ( j '~ ~~"' ''J' '"~ , y _~, r ~'e ~3~~~a.P3'3~ .,'' ~:~5.'t:'..
"
f '~'qy~9~~~ ~9~~~n ~~~~~a~~'~~rfl~~~~~~L ~~~~~'~~~~ :~~=' ~~~, a~~~~
~'~~~°~~~1;~.~. ~'~r~~ ~~~~~L~~
.~'v~ f~s, 1 DR'l-~oi.'T~ e,~S3a~~, ri ~;~ ~~~3~j1 'ul~;;~S'~~~ ~w°
~~.,51~''Y ~i'~LA' '~~'.~~'1~~~'~evr ~~ ~~~ S~s~.~~
cperat-=cruel ~s~~ ~~g~>~°~ ~-~ ~'~:,~; ~~5~ ~ Siv~ ~t.c~~e~%~cr. ~~ -;~~.~;~ ~ ~~~. l-~S S~~~rva-~ ~~' o ~~Ltr~ ~-~'~, L"a'1~ ~'~~~~ ~'i'"a~~,~'S ~'~~~~~°,;" la~~
C~'Ga.Ler!_~C ~1~ I7~c~.e~~c;~i~~ 5~~~~ ~~St:,~i ~':'t ~I~S~~"~'~~
r~~'~i~''1a ~.i~~ ~~.5 e~~L~~,S~~,~$. ~'~5~ ~~JJ;~ 5~:~v~°s ~i,~~~
~~si~t~30~'~~~s 5~~~~~,5, .~. °L~~y ~°~Il~a.~I3 ~r~~~-a-states and transitions. ''his is sho~r~ on tl>~ diwgr~~z by ~. srr~~.ls ~o~ on the hoa~torr~-i3gl~t corner of each composite sty=~. ~ figure ~-i5 salot~rs the, inv~z~~~ls of St%to Crea~eTC
~~ ~x~~~pl~ ~,~hi~h doesn9t cantai ~ any ~~rth~.r ~o~r3posit~ states_ hTCte h~~a the ~~tte~° afro a~3~r~~rs ~r~, ~~ad~~~d ~~~~h ~~~~r-h~r~dli~~~ tr~9it~o~s V=~:'~_8~'.~llt ~f3IT~p~'~%Tllsi'ad~ the ~~~rIC~ C~ t~~ des.t~i'~. ~r~
la~,'°,.ty '~A.~k~h 9J, :.'16..' urci.~'a"s~~~~a"~.,s ~2i~Ca~3:!~s str~ight~or~r~~d Code, typie~iiy o~~e method ~.~~1 ~a~re~dy implemented inn tl,e base 1~~'~
class and lust inherited herei ~xrhidh sends ~ tv~t~a~.l command to the test-based cli.~~a~, in L~.~rn re,spo=zsihle ~~' sending it t~~mr the a~t~aai session. 'the romp#eze, design a=nd tost~n~ ~~
ts~~e st~.te diagram of the ~'DR~_se-c~c; capsule; gas done it about h?,11' ~.
day.
1.:~~_ ~ first evalaaatiorl a i~ regard to the ease o; design aid ipieme~at~~tior~ of r~e~.v ser~iices. ~~i~7iriie the d~,sig~~ arad g_~p'.s:,~~°~e~t~~~vo~. of i:~'~e ge~yer~i i~~~-~.str~acYvre took almost the Creole research period for ais thesis, ~.:~g~geritir~g it yrith the ~'~'-service descried pre5~ioa;~si~ f~sl twv~ I~eYer~ge~aeo~s c~'~' elasses Yooa~ rao yore r~g~~~ a d~y~ ~~or a sirrgie deveioper~'. ~laere~'ore, ure coraider r~ret the goal of aido~ri~ag eas~r arid rapid ~~~~iee~tatio~ ~f ~e~.~ s°rvices ~wiYi; the ia~r~se,~ted v~~~.r~e~ork.
a~s for reiiaaiiiY~; the di~.gra~~s ;ores°rgved :i~~ the pre~ri~z~s s~;~;tvor~ s~ao~;~ rx~~av co~:rlpiex error detection arid has°~d~ir~g ecix~~~iss cap he e=~sii~
iricorpor~ae,d to the het~avior of ~or~t'-oiiir~g caps~~ie. i~oreo~r°~~y ~,~ol:rolii~g ~aps~~e:~ i~'~er~t art importaY.t part of ti~e~r ~~sr~ctiorsaliYy ,~zo~n the ~~~~ ease ci~as ~~d use f~ciiivies offered h~
other cor~porze~-~ts of the frae~vor3~ ~rhich zas ~iread~~ i;~.e~ zis.~rea:yhiy ver~fie.d once ~.~d fo~~ a~ao ~~s'~, the sii~pliciY~ of the code that ~a~s to ~e $mritYe~ i~ ordeal to i~pie:r~enY ~
~:e~ service is s~c3~
t~.~t err~rs are made Less ~ik~ei~. ~r~ the otiaer i~~~~d the er~~irorar~e~v~
~.~aed tc ir~piee,r~t a~~d ~erif~r the furictiorfaiitl of the ~,~s ~l~avio~~~ai dose ~eai-'pir~~e;
~eit~g a serr~i-forr~~.i to~~ fo:c b~:~idi~~g ~~~aite slate ac~ifi~~;s, it is iikei~r t~~aY arses tie ~'~I's ~r~, s~ccessf~Ii sir~~iated Wye are error free. ~s a roused fierce,~ overall reliahiiiY~ is improved.
' ~'I~e average tirxae a'or sueia a task is esti~~xted to tvvo .pan-ea~o~ths.
~f this iaolds, t~eu~ our rr~etla~;d reduces tie e'~o:~ i~ G ratio oa' at least i:~~ in ~ wo:st case s~:es-rtrio.
l~~

:h'1 t~3~ ~~~! - ~Id~:, ~i"1~ ~3~- r's:3~, ~~t.~~c~'~~rtt~.gc~y c~f ~~Y° fY"~t~3"FC~~I°~ is t#~~t tt rE~'~~~~'~s 'r1 lrinirrtvm ievei c~'~ tr~.i=ti~g ~viti~ d~.~c ~.ati~rtai ~s ~ ~.eai ~'ic, ~~$~ic~ is a c~a~r~erciai and rattler c~~~nsiv~ $~~i as ~rcii. ~a~t disc ~ra~cfi;-_sl~s ~~~d the a~~r~ac~
ir~tr~d~accd in '~ gis tiiusis :~r° net tsea~~d to a~~ specific tc~~sZ. '~'~~ed~ <:,wl:~ tse arn~ie~tc~t~ud alsing ~:~~ c~~ttcr e~~~to~''.~
~w~rl str~.igtat ~°~dii~g. ~i~~rever9 ~ass.r~g ~_~ u'~.~', has ~t~~dersia~ie, ~aci~~~t~:ges.
~sil~9t~11vT L~~~.aC$~~s~ ~~~2"~s f~v?~a t~k~ f~~.~''.,'t ~~.~"~"~.i: '~I':J
Gid nE9? '~.~~;h'3l'9~ rk&~:l 3e'5ri~2i~lsh~P. ~6~
f~latx~ ~~aiid~te the i~~s tt~u:,t ~~,ra~r~.~ the. ce~rr.tr~~i ~ige~at~~rls.
~~lida~~e~, t~~;y d~,~llggt~.g, 1S d~rta': tk~3Y~a c~. tr~Gtttt ~d~~ ti,'.s'att"g,.~"-~"
d~~r«~~~t, k.~.. ~~stgt'tg ttlc a~~5'~4c~t1E5$'3 ag~3il3sd:
~ s~.t '~3~ l~~a tn a to"st ~rl~llk(~Ttt~tert'.lt. ~~-3<°t~i~.'~css, 3I't c~~~ ~.~~.sc E~~~3L~$lI-ag .-.°zl't~~ 'tTaaC~atX63d~.
were r~~ne easier mitt: tte~e "~~sc:~vatsility'S ~ieat~l:~p available is ttte ri.~.~tire ii~raa~~ ~f ~.ati~~ai ~~ssc ~eai"t'irrae, rl~at is, ~~a~c ~~sf>it;~ii~~ lc ~riss~att~~
f~tie~v t~~c e~cca:gvi~rl e~f cac'~
~.~d e~er~ state r~acr~~rlc ~l ~ :rcwl-~rr~ae oasis.
tte rest ~f this section viii ~:~pse~t w test sc~;~aric~ ttlat was ~~sed t~
~e~lc~~ tale '~ ~
sPrvicP i~tr~d~aced ~re~rF~~stj.
>gore 6-Id sl=aws tic set3~:~~~ the testing erl~%iro~l~ae~t. ~~F:~ hJ~~~~~.s~
vide~ stre~.-~ is aerterated t3~ the l~t~E~2 brides se:~wer. ~'tais stre~,r~ traverses ~~th the ~~~~~~dr~ ~~ig~ert -~~~ L~~4.~) r~uter and ttie ~is~;~~ &~0~ ~ ~ 555) svaitctl ~~,fere rcaci-~i~gg ~~th vide clients. r~he tg~frlc gencrat~l- is ft~.~~;~ to load the i~~:~w.~~r~ ~vit~.
i~ea:!y traffic. 'the vsie~
~wd~ gei~~g rc t;~te first :rides ciie<_=is ayvr~~rs give's 'i:igher ~ricJrkty arid ~araciwidtu~, aid t'~~~as ti-te ~ualit~r re~rtair~s ~~rfvct d~r:i~g aI= thu pest ~Pri~d. '~ his =.aient tl~Pref~re ~.c~a ~~s a ~-e.ference. 'fhe vide fi~v~ go~.rtg ~:~ ti,.e s~::~rtd vidcs~ ciier'~t ~x~iii be c~;~fig~r~.jd isy c~rlr~tling ~i~K axld ~~5~~. ~"i~~ene.ric ~;~~~tr~i servee° is ;~~a~rri.~g el~t ~ host rs"~ar is _~~

~~~~l~c~~~ v~ ~~ae i~~~d:~ ~~~ ~i~r~;~:~:~~ ~~ ~~~~~vrv ~~:~e~s ~~~~~ t~~~
~i'~~: C~~~~~i ~~-~ffi~ d~~~~a't d9'c~.~i'~Ci~ ',A~~°~i ~$e~'cC4 ~T~.'TiC ~~~>~H~~" :~~1 ~~
.~°~.~~ ~a2r~:5~~ ~~"f~ ~ k~~C l~~ySa~~~~y ~ ~C ~~JC9~~~:~'t~ti6Di3 i~~B.E~~s C~9iF~i°rs ~CDiE7:Ci1°c~~dC~a~ ~~3 ~~~ irs~~l~~~3~
~~i°V~T ~'a°,~~~~~Fri~ C~'?~ sr~~i'9~ ~3:=J~~'i~~IC~IF ~C
~~c7~~'T'~ ( i ~
C~~L~'1=2TC ( ) ~ ~~fi' ~'C~$ya ~;~~a°<1Ct6'L 9 ~s.ki~i $_~'iC;
C~~f'iG> ~~h'6J~~° ~i~3Y&de~;'s t~a"d:~~'~ '~~'c~.:'iS~,'c~fi'~t"it~jl.
.~-~
_ Tr~~iie Cr~~ei~~toA
-_ ;~~ ~ f._.~
~,2PEG~2 Video j ... . ,. r , . . _. t 't~ideolCli~~ 1 VzdeoiC3~ei~fi 2 ~ . ; ae~i'~Jer' ~j I I, ~~-'' i=d~~~C'~ ~ u~°a~~~~ '' ~e~~~eE ~~~~~~~ ,r ~_ iv~EG 2 aat~
~Vf?E'i ~~t~ , F
~ .~. ~ ,- ;r~
Fd ~ ~ ~r,~, l :: f~,,:~ ~ ',~
ff ,.:~,.4. , , _ ~ r'~ .~:.~a '' . '' ,m.-xw i ~ . ~Y ~'~x,. , _ . < z ~ ~,' ' " .sF
CiSCO 3~QC
~,is~c 6505 , Fat~~nc~-yEia~ar Cisco 3~~

J_.
, i ~' ~ ~ 4r2t"c~L'3C COi"liFO1 Sel,"VeP' --~::-~w .~..
v,To~l~st ati on ~~~a~~ ~w~~~ a~e~ ~~~~~~:°~:~rr~~~~ ~Q~r ~~ ~~~~a~e~~
~~~.~.~°a~~ ~~p~~~°o ~.~:,ita~.l;y, L~ ~~id~~ fi~~~d ~~iz~4~ ~~ ~~~ s~~a~v~~ ~ai~~~ )~~s t~, see ~r~~si~:y ~s ~i:~ ~r~.ffi~, ~e~~r~.~~c'~y r~~ zr~>fic ~~,~-~~,>~.t~r, ::) rrv v~idec~ q~~i~a is ~aisf~iy ~~~r. ~e~~
cr'a~eTC ( ) is c~l)~c, 6~~~ ~ri~~~ fi~v~ a ~~=~~r~ ~.d~q~a~.~~ res<~,xrJ~s ~ru ~~~ ~rid~~°; q~~ii~~,~
~~~s~~s siiiar ~c~ ~~a: ~f v~ae first ~ii~r~~. ~.~ri~r~r;~iiyy ~re~~
c~eleLa~r. ( ) s ~~,iie~., t~
~ai~es~ ~az~i~y ~e~c~~~s ~c~cr ~.g~ir~.
~~g~rdi~~g ~~~~u~i~~ ~i~°~~sy :i'~.~.~i~: -i s~:~~ri~~s ~i~e r~s~l~s f~r i4T~ ~~d ~ ~bi~
-~ r~r i '',~lS~~~ ~~'3~s~ ~:.'°e:. ~r'~'~'~~g~~: '3r2~s ~~s~dsø~ ~x3 ~~E: S~~J~,y fmr Sf:~~r..''~it: ~~~r~;~c"asiQrl~
~i.~. i~,~ a~~rawi~~s t~~r~~ea ~~~~~ ~. sir.~gi~ ivy, ~.~ ~ ~ir~e~. ~~s~s~~-~s~ ~vi~ys ~a~r~.. f~~~a~
'~~~~r øor ~'6~~5 ~~:~r fC~r ~f~.'~~~;~~;g~ ~~'~~ ~'~,~ :~~t~r~c~i~~
sc.q~~r~~,e r-~q~~ir~ci ~~ ~:°ry ~.~~. create'z'C t ) f~dele~te~~ C ( ) ~t~zs~r~.~r~~.a v~r ~~.,'~~C~~
°~ 5ii~~~~iy s~r° ~.~~l~i~,~ z~.~l~
~~~~"s. I~is~g ~~~ ~x~~~:~=~r ~f ~)~a~ fig°s~ r~~gi is ~ia~ays siu~~~r ~~ec~~s i~ i~v~l~~a s~a~rr~i~b a ~°ir~e~ ~iier~t ~~d ~.~~~.~~~t~~i~r ~ i~gi~E seqs~erl~~.
~~~seq~ea~~ ~~lis 3~s~
~'rP~.~y ~~~~_ s~ssi~r~ ~~ ~z~e ~a~~~~~.~: ~.~~d ~u~;~s ~.~°v ~~~.~~r~iy fasc~:~_ .~s~, ~;~e delete~C ( ) a~~er~ti~r~ ia~s ~ s~~~ %y~~ ~f i~~~r~.~~i~v~ ~w:~~~ ~~~ '~~ ,~ as create~C ( ) fir ~~~~ ~i~~ra~s ~~~s sir~il~rr ~~~~azti~~~ ~ir~:~s.
~~~rati~~ ~~__ ~:,irs~ ~~°i ~. ~ ~~a~s~q~~z~~ ~~,lis ~rea'ce'x'C ( ) ~ w LS.,~~r-~;s - i~sC~ rrls ~, a ceTC .... ~ .., a ~ 3 t ) ~ .~(3 ~x:~s ~~t. ~,s ~~.~~ ~~a ~°~~e~~~e ~d~~~,ys ~ ~c~° ~~°~~~re~~ ( ~~~~~
e~~°~~ ~ a ~'~~ ~4~.
l~~

~~er~.~~~~ --~--.~ ~~rsi eaii ~~i~s~~~a~~t ~ai'F~

._ _-i N lr3L~~ ~'gxs ~ ~ ~.~ru~ I~
1 C~'es3.i..e'j'C: ( 1 ~'.- ~~ -~

_ delece~~C ( ; f ~ ~z4~~ ~s ~ -- ~~3~ ~s ~ti~~~ ~~~ iz~ i a~'ai:~~,i i.e. ~~I~~,a~~ r~~~z~,~~~is~g ~~~ ~.wr~~r~i c~rr ~~~~~ ~i~~~~ri~.
;;si~~i~a~~wsiy~9~y ig gas ~~,~~~d ~i~~C ~~e k~s~sra~ d~ia.~s ~,~~r~
~.~~3~oxi~~.a~~iy ~r~~i<'~~,a~g~da ~3 '~C'~, ~'t, p~ri~rrYla~'~"~ dS ~1~9i~~.'~ ~~ ~Yl~ s43~~~3 C3. '~~ 1 ~~~~~
~~~a' ~1~$1. ~v.. ar'uG; o°.r~ G'lr~
~s."J~C;Ssa°,d c21 2~ rYlL~C.'11 -~~.s2.~~' i."~L~ i.~~c.~ øS~~Fr c~~~'.i:i'~J~ r;~~~. n~'~"t~rv,~~~K:, ~IaIE;F3 ~~~ ~a3El~xfii'~ y,"'ir~,i.
iS l."~,d~~l~I2~ ~~3J~ ~r~~~s er' '3sa.~2d~~,i ~~9 ~s~J:'S~ ~~~1t9 >'~;~~~3~:~~G s~ii~s~.=:Yav, ;$ ~s ~~~s~ ~:'l~3lib~'Y ACT
s~~i~~iz ~r~~ a str~~r~ ~~ a~~~~~r ~ysr>~~g~~~ a~~d~~i~ ~~~ ~~u~raaf r~s~~~s~
stay ~~~r ~ac~
~r~~~~~ci~~~_ it ~~~ ~~ a~~i~i-a~~;~.., h~~i~~J~=, t~~~ r~s~~~se ~~ia~s ~raili begird ~~ ~e y~~sc~~~i~i~ ~~fe~~ed ~Jil~r~ ~~e ~ga~ ~via~~: ~.~st ~rai~~ ~~~ ~c~r~r-s~<
serer ~aili ~e~.ci:~; a eer,ai~ ui~r°si°sold. it c~.~ ais~ i%e ~.~~:ci~~ted ~~iti~~~~~
i~ ~~~sr~'8 veYi~ie~ ~~ e~ar~cre~e Less z~ c~~r ease ~eea~ase of ~~e a~c~~ a-~~~iL~~i~i~g~ c~~ a i~~bv ~esti~~~
err~ir~r~r~e~~~) ~~r~at r~~is ~~resi~~id i~ ~~av~~.se~~~y ~r~~~~~id~a~~~ t~ rye pr~~cessiq~b fairer ~~' ~~e h~s~. ~i'~°xei'~be, ~i~e ~~r~~ase~. s~i~~i~r~ as seaia~ie ~ec~::~ase res~~r~se deia~s c~x~ '~e i~~r~~Je~ ~y adtii~g ~r~cessir~g ~~~er t~ ~~e ser~Jer.
'~~e ser~Jer ~%as ~~az~~in~ ~r~ a ~;~~ie ~rc~=~essa~~' ~~~ar~ ~a~r~s~a~a~~, ~~~ ~~g~~. ~~ ~~i~_ ~~~ira~~~.re ~.~ ~,~it~ ~ i2 i~/i~~nes ~~ .~it~9 ~<~~a~~ J. ~J. ~ rye eiacrk'~
:xr.as ~~x:;~~~ii~~ a j~.~a ~~pi=ca~i~~ ~~a a ~~i~d~~JS t'~T k' 4.~ ~~:, ~~ ~i~'~L~~ a~r~eess~~' ~i~rs ~,~~ i~~~tes ~f ~1~3"~.
l~~

l~~t~a~~~ ~.~r~~r~l will ~i~~ ~~~ li~~~~~si~gl~ i~~~~~~.r~t ~~ie i~-r i~~~r~a~.ti~~ T~c~~~~ic~gy ~s t~~ 2I5~ ~~~~u~;r. ~~ve~r~~, ~a~,~~~,~~~ ~,~~~r;~l ta~~~y is i~afi~.i~~d ~.r~ci ~~s~a.l~.~l~ ~~c~, aa~a~~~ic~.li~, i~~s ~~t ~~c~i~~~ ~~~~~~gl~ ~.t~w~:i~~g ~_~~~r~
~xevi~~'r~s~~.rc~. ~la~ ~~~~ ~~a- ~
~e~i1~1~, ~~xi~i~~t ~~~ ~°~IiQ~I~ ~>~sl~t:~c~~~ :~~~ tl=~ ~r~bl~~~
~r.~if~~ c~~ar~l c~~
i~et~r~g~~e~~~s ~etm~x~ eh~~~vs ~~s ieti to t3~.~, ~~se~r~~ gs.' this thesis.
'~'h~s ~~~~e~t ~~~s~~rs ~ s~a~x~~ s~Pveie~,~~~t ~~~.~~J~~~. that zs i~t~r~~~c r .~~~c~z~~~'o~wo;~°~ a~n~leme~~cz~aon o",~~~a~y r~~~ge of ~e~.vo~-~C
e~e~ce,~z eo~~~o~~~oceclr~a~,~.~ ~~ e~
~raa~o~r~ ~'us~~ao~a. 'The ø~~~~s~ci s~l~7ti~~ is ~~l~r~~ ~~ ~-~~liseic e~~w~s: ti~~~-t~-~k~.t, sir~~li~ity., as t~~l? ~s ~~~~~a~~~ v~~~ ~~liu.~=l~t;~.
~'~9~,9~i~~"~ i~~ i~
~~eg~ll, °his th~sls ~~~~~i~a~s ;:he yr~~l~;:r~ ~~~ ~ar~i~c~Gc~~t~~l ~i' h~t~~c~g~~e~s~.s tv~~rl~ ~l~a~~~~ts h~s~~ ~~ the t~~~~~~~ ~~ a!r~it~ st~.t~ ~~i~Fr~~s.
I ~c~

~n. ~~5~~'ia~'~ S~~-g~'~~:,a S~izg'~i~'~ ~'e~;~ ~9~~>a ~L~~lv~~~~~.°~%
e"a~.'C"k~' S~yY's~ ~~~~~~,~1"?~ ~5~;~~~~5 ~L9~

G 7 °"1 ,~° -~ ~ ! d . ;r '' a f3" ,.~. ~ j- g-;. . y y-~ ~
~ rd a ta~t,~ ~5~'~~a~L~. I~~~~dJ S~,G,~.,~a~~'c~~_~j ;~~ ~ e.,% t'~.3 °.~.,~ae~ . ~5~ ~:".,"~S '~s' ~ "t° s.~"~5~~' ~. - ~
~~.>~~~,YLa~, ~~~~~~a~~ i~~n~ ~_~~~~~."~~r ~~~~~ ~~.~~~,~.w ~~ ~~~~~~~ ~~ ~xvea~~i~~~~'d~~
~SS~~,~.
_ _ ~ , ~~_SL, !~?~ ~°~~"~L°:.':° a C~zL'~~?YLc' _.~ I ~~
3~3t..e°~,k:":'FS°;iv~ ~'I'~ ?~il~ ~..35~ ~~ ~.~~'~~.>'i3?
~~'~~~~cJ~~ ~c,~~~~i._S
~~~L.~':~>~ ~w~'.Ø~ ~~E.~=~w'i~vtrv~. ~'_n. ~~~5.~~~rv! ~'r ~.:9 ..'~,a ~J.~.ltiB~C.. S..T~~~~.F~~' s~ ~.~_'~J4J~I i",.~5~~'..~~~~~'S v~d'n~~I~~...
L~~
~~'",S3~~S ~J7c'~S ~'~5~.3~SSw,~' ~~ 'C.'' ,~p~ls.".a~~; ~~~S9s~~:=.%.y .'~.
~iYlal..."~i~~ ~'~'Tyr ~S~;.k'n"'~'~'~%1~..'''.'i~ ':n.~"'ri>>TF ~~3~
~.~59''S'?.CE9;
~~~1~~~~,~'1 ~'a ~9~e'1~T' n~~~~~'iT'3'~a ~~~a:.~i_x~-5~,~~~~~:~~lt:.
~'1''~3~a.e~;i.
l~~~i.'. E.'~~~Y~1 ~~~~a,~.'s.x~~9g1 ''~~s'~~ ~.~~'T_i.~:~~i3,_' ~,~~~
~~W~'~~~ ~~ ~,~y' ~3J~3S ~~:~SeC~~3~;'S~ e~S
S~~~l~~'~<~' ~=~.'S~?~~~~''~~ ~~s'~.~'d°S~l:.~~ ~~e,i:z;~~~35''na,'~"~.
,~F~~~,~~1~L~: ~SS~~S C~br,'~~~~..~ ~~ (~..~.a ~.~~iYi~'n~~~i9ag y~'_" ~~~SN~,'~':~s ~i~a'EISii~~ a,o'3a"~av'I~! N~'~,:~ :s~~~:~~. f~. ~~S3~~x ~3e~N:'~~i"~ 1~~Y. l.~I_~~-~'~'~~~i~a~~ ~P~~=:.S &=_''k~~
r ~.a'~'a,S ~iY°'._t~~' S'C~~a:, ~2~~i"a'"~S ~E3C: i~~~~~t~.i ~.7~.i.~F_°~3"s't~~~~ v~~~S '~15~.(°.~i.SS.r''.fa~ ~.~d~ ~~"' r~d'~~J'd~~S~~_ S~c.~~1SS~~;S z,~~.~~°~ k~l~E'~~,~zC~:'~~a'~ ~i~-~'.':~S;~E~C~.
l-~ ~~~~~~ ~~~J~,~ ~'~~ ~~3~~°°.r~ a~ v~F~"~~~~~:~ ~'<~, x=~<::-z'o~% I~~~~~~=C'° f~~~'~~~~ ~r~°,''~~ ~J~P~~ ~~~e °~d' ~L3~.~ 'r° °3~ ~'gdY''a ~"~7i.~~',~'<i. ~iy~ "' ~
;.'° sa y 'a'~'~ k '~ ,'~/.,~
f~ ~''y "~xw __ ~~v ~ a ,, ~,~ : ~ -i~~i'v~if~~;~ ~ ~~Ti ~', h C~S~%~~~:~~
r' ~~~~~~ai~~-~, ~'~~~$~~~~ '~s~~'L ~~S'~f~ ~r ~ "~"s~3':~.,°"~,°zv:,~"~~e$1'u iya ~ t~Lii~~:,~a~:~s~i ~~'.",=9~~~~~5~ ~1~;~6; ~~°~'~s~i:'~~~' ~~u~ c:'V~:~o~~~~:~"~. ~$,'ar~~S ~~~~a~''1~ k~°~'' f.a=~'~'i~?~'~~,Y'>~y~s~ Y"~i,~%~? a:'~3L"°~r"~~ ~~'~,'a.G"~a.i~~S
~i~i~S' ~°~.?~,~1°~.?,"~l ~rcc°3.5~ ~3C3~ ~a'lc~~: '',.L3~x'x~~r.~ ~~~~~~'~'~~.Ya~°
~~5~~3~!:S ttJ~~N 5:~~~'SM~~w~~v~~I.
;fir '.~ '1 his thesis ~s~de s~~r.~rai ~-E.~;s~~-c.h coy ~°~h~'-~or~s; ~i~ich ~~ar~~ he s~~v~r,_ar~cd as ~oilo~vs:
- ~'hy rc~rairc~~e~ Zs ~~r ~~~rt~~ cw~~~°c~~ ~;f '~~~~tcr~gc~cot~s ~c~~;;.mri~ cic~~~c~~;~ ~~crc prcse~ peed. ~ g~~eriC ~r~.~~e~v~-_~l~s ~.~~~.t s~.~is~ics those rcei~~r~r~~ergts ~~.s ~rcs~:r~vcd.
- ~ raew dthodolog~, ~~~h:~cico~sis~a iri ~_~a~i~~ra-~ ~T,:~ i~vc,r~cti~r ~~to~~.ti~ra ~si?~g ~ co:~iso~~r~t-~~.sc~; rc~~i-ti~r~ ~aa"~~~~rrae,h, ~r~s ~scd ~~r tl-,c first ~i~~c.
- "~'_~e ~~rtic$.~iar cGsc oi' ~~i~orz ~iw a~ao~~~atior~ is st~.dod ~xtc~sivci~~ nor the ~~~rst time j~ ~h~~te~° ~, ,~h~r~. v~he co~ccot ~3 "e~~~,aic tr~ggcri~g ~'~ii.ex9~ ~~,s aiso i~a~rodF~cc~.
- '~'hc; tcchr~i;.~.l aspects oi' the ~I~~~ sta~r~ard that ~~c rcic-~a~i to s~~~~ortig the ~rc.sentcd ~:ra~c:~orf~ ~~~~°c ~x~.r~~r~ed. ~ -i:ool that seaports those aspects ~.r~.d pxte~~~ thcr~ w~A~n rc~i-ttj_~c. -~t.":rzh~.tcs ~a~s ~~ri~ ~~ ~rcsc;rptcd ~:p ~c~i.
- ~> ~~ii~r ~u~ctio~ai protot~~c o~ the ~rcscr~te~~ a'ra~~e~~rork is cor~straetcd aye a test a~~Iication is ~rod~ccd ~~s!. tcstc~. r~dita~nai ~~rf~rrr~a~cc c~s~res rc~JCaicd satisfactory aid oti~pr ca~ic:ra~; ;~L~via ~~ the easy o~ ir~~~~Ar!r~c~tirg ~c~ cw~~r~r~i ~r~cc~~rcs, °werc cva~a~~.t~d :~~~'. iovpra~t ~.gn~~~_ca~~~i~
!~tcr~Gti~r~~.
~w~ ~ ~~t"~~~~"
~~~ :S~~l°c.°~~ya~'ril~==''~. '~' ,~ G°~3 x~.~~
~'~v~~i~''? ~~'"vl~C~, 47J.~'~ e'1~'~ cS~tR.'.rfd~L~'.. L9Y~~~:~~~i Yrlt~':~"~&?c~
aped sv~~ort ~o: se~er~al co=._~atro3 ~rott~cols, i~-~ isc~or~d the sco;~e off' this thesis. pork i~ ti'~is i r:2 ~.$'C~ ~Si~&Dl%1~ ~i~.' CC"a'3'~'~rl'i.g~.'~ 31'1 L9~'a3'Cr ~6''i i~3li'~y.;,,sa"1 t~"l~s ~$'aTIY~:~r'~1t'"3.~~ '~Xl~is'3 f~Tl~rC r'~C'rI-i~a~
~~~r~.ct~ristics. '~~3is ~~m~:i~ iv~~i~~,: :i~~ ~~ii~~~i.~~g:
~~ple~er~tir~g t~t~ ~ Jr.~i~ r~~~~,~.:rg «~a:~'~ ~~~~:~ ;~r~s~rlta~:~ i~~
~e~ti;~rr ~.~.
:~~ aclcitioil, f~~r~stig~.tirfg ~xhic4~a i~.~rii~i~s are: most ~esieci ~r~~~r~ ~arsi~lg ~, ~~a~,r~~.rv~, v9 n .~yc~
V~ 'L%r.Y1 ~i~d~~~i ~ ia~~~'~~v'~~~~ r. ~ ~.e~.
~~~~°t~°'.~gr~~ t~~ ~lC4rr.~"v~',~ar~:~S$~ 31'~ltla ~./"4.ah~a~
rY~~.IC'.~~~~~'~'1~~ ;~~hit~~.~~~y .5~w G~B.S w~l~~~~~
anti ~1~. '~~is ~~ro~ic ailo~,r a~~;v~~~~:ing ti» ~rarr~og,~aork with ~rz~ncc~~~c~:~t f~.~iiiLs~s.
~r~'ICS'~=g~tafil~ i~Cr~Cr~l'L~z~Ct 1~~Z~C~ ~:1'.°:'~
~Cfi,rr%T3~rl.lrl~ ~~'.~e:. uCr-~raT?CC ~;~~
siii~o°re~t corztro~a ~roro~ois 3~ ~-a~i'oront scenarios. ~y ~oirlg t~°~=s, ~~.~t~s oarl d~~ati~ w~ici~ ~o~~~roi a~r~~o~-~~i ~o ~4as~ l~v ~~c~n :~~er~a.trr:a~ ~~ v~~~r x~~v~ ~r~;~xoa~~s icr~ovvi~tig~ 03 ~erfor~:aloe attri~~d°s.
~:?T . ~~..,~ 2i~t~~T~~3.~F~h ~.~t ~~°3Sz~9 ~C~lrl~'1g c~
~T2CC~l~i~ISr~ t~lat Ia'~Ll~~ ~=~f3~I
~r~~~ ~~~ _~ ~~.Y ~i~(~.~~''u ~3~.~_ ~-~ ~Y~1~~ " ~.~ ~~iiSi~.~~~ ~s~s~~'~' thJ ~C~~~c.re:~~
~ei~~or~ ~3vr~ents' f~~~s.
~n~~stig~.ting otj~or a~~ii,:ations o~ tire ~~-eserte~ design batter's.
1~~

~, a 1 ~ I~'~'~, ~~~ 2~7~, øa~t~c~~ac~i~>~ tc ~.~~~~Y,~~~r~ ~ ~~tb~~ ,~~t~~r~~--~~.~~cdc~a cf ~,~tvcnrk - ~~~~be:~~~~t ~~~~~e~~~~~, ~w~r~i ia9~.3~.~t~:df~r~~~su~~.s~t~.~Fg>'r~~,rr~c25'7~.~xs~
~2J~ "~"~ i~'~~r~~t ~ra~'t, ~4~ .~~~'~;~-~~z 1~~~~~c~?e~ac~~.~ ~ci~i,~e~
,~;~~~n~> ~~Lf,~c~~°s, F~~~-enary 2fl~i. ~t~~~:ll~.~~~.~~_:~. ~-~fivtu.,:.t~~t-d.r~.ftsfdra~t-~f~~~-d~~~s~r~-r~a~dei-~~~.:~~;
3~ ~~t~. ~'r~~lc c'~~a~ctr~ccv~.~ .~rP~~cr:ci ~~~~,~; ~.f. ?~ 2~~~.
~vt~:fi ~~,r~s~.~3.~r~,~'J~~~'u~',~
~4~ A~r~n ~~~r~r~ard. .~~~~: ~'~~ ~i~n~ic ~~~cc~ ~~~.~ccs.s u~~~tc~c~i. ~~3rJ, January 20~. i~tt~:/d~~~w~.i~r~s~~t.~~~rr~fa~ir~;df~~l~C~ls~a~,~s~a.as~
~f ~~z~nard ~cri~~~~r a:~d bark ~. ~ti:~~r. ~.e~c~-~F~nr~i~zg bhp =i~~i~
~~~cct~ccc:~s ~~c~~ocr~i. ~,art~re~~fO a~-ti~:~~..
~tt~:llg~~t~rar~d~v.~ar$v~~~~.~~~~fartz~°1~f~3;; i~~-~~_~~~13Z i 9~C~.a~trr:
~~ ~1~~ ~~t~. 4~~~ ,Se~~ic~~ ~~~e~-i~~~~~ .~~~r~g~~~~=~ (6i~~~~,~ .i.f.
~tt~:!/~~~~v.~cr~.~rg~~l=:~sd=
i~7~ 1~ar~ ~:ira~-~~a. ~ ~ia~c~~rn,~~~°,:~e~ ,ie~-~iw.~. i~/i~~l~
ii~rar~r~ G~x~~ar~ 2~~1.
~~ sari's ~. ~'s.~a~r~. r:~~~ ,dew°iw.~ ~se:arify:i~~~ ~~~~~~x~c (~J~;~~~) .~x~~r~id~e~'. ~~~~
iiigr~~r, .i~i~ 2~~i.
~~ ~.'ass~r ~ic~~~;ud. ~~~-,~,~'~ea~~r~~ ~~~r. ~~~~~>~ert.
~~tt~:ffvvwv~xa.d~°~~p~rt.c~mft~aa~r 5f~,rsdh'~,~sdi.asp [<~~ 4~hi~~ J~~r~g. ~~~~t~ir~~-e~~~~~.~.si~~.~ ~~~~ir~i~~ r~s~:%~~:~~~~.
~.,v~tar~. ~°~~t~s. ~xai~m~°si~y ~
~~ir~~T~s~~"aar%1, ~~tlc'~..~,''~ G~~ ~ .
~tt~:ff~ ~.l~a.c~t~ ~ai.~c~. ~l~~~larkfi~~ad~:c~rr~~l'~ar~d.:~ut i .~d~
t [ 1 i; I~ whir .~~~rg. i~'g~~~~~ ~c~g~cg~j. ~.,e~t~~~ eves. ~Jrsiv~rsiy~ y'y ~irr~~i~~,ga~3, .ia~~a~ary i;~Ci.
~~ttpa!~reWw.~~~~~i.e~.i~~~l~r~t'I'~Ii~si~~pft~a.~c~a~~,~t~.p~f [I2~ p~~~ ~. ~Iae~. .~~c~~z~~~,~a ~>~'~=~/g~~t';~~~._, :~~~~
~"~~°°~a~~'u~~~, ~~cl ~'~c~c~l~~.~, ~r~"~".
Sep. i~9~. ~tt~.,:ll~,~r~~.~~fst.~~l~a~ste,~~~s.L~~:::
I3~ ~~~~a~ '~~:~<ar ~~°.~;i~la9 ~i ~~ea ~i ~ai~A~9 .iia ~h~. ~~3~~
~~~e~ ~'~~srse ~ta~d~~, ~~teriaps. ~eee~~~e~ 2,01.
~~p:ll~~~~r.es.~cix,~.e~~/wtss~~ar'~.~:~~:ie~'s~~t~,~i~a~a~'~re~
c~~rt~e.~f~tri [ g~. ~ ~Tat3er~~.i ~~stHr~te. ~~ ~ta~~c.~ci~; ~ e~:~~~i~:g~ s ~~~~'~).
~'~c,~~w.
htep:!/e~pec L.r~is t.g~~,d a~~ ~~1~.~ ~~~t~~.re. ~e~a~=rs~.
~~ttp:r/~~~~hr.g~~.~rg~bs~~t~rare/t<ejag~~~zlcie~~.g~if.htr~.:
i6~ Aie~ ~3~as~r~. .~~g;~lc~~ ~~p~~<~s~~r~.~ ~.~~cT .~?~~~,~~s ~~~~r°~a~~c. ~,eet~.~xe ~~t~a.
~.Jk~~~ersit~ ~~ ~sii~~~xrg~, bet. ~~~~.
a~at~tp:~'lw~v~J.~.~cs.eci.ac;.r is~te~~:i~r~g/es~.~''~a~ir~~es'~..ect~resl~~~,~~J~,a=~tgn~ro~:l~p~.~~~
s f~ fl~~eet ~.~agee,~~ ~~~~p ~e~~~). ~1~:;~~~~ ~'~~~ll~eg ~c~aag~~cge ~~ec~~p"~~~t~~~~~a >e~ss~r~ .1.~. ~~~e i ~9~. ~r~tp:e'le;nw~~v.~a~<~.g.~~°gl ~~a~~i~r~al ~~~t~,T~re. c~t~fl~~l .~~c.s~ ~~~~"~~,r~ r~~llr~ ~:~~.
~tt~:l>'~r~~r.~~ti~~~.i.~;~~~' [L~'3 ~,ati~~ai,~o~t~uare. ~E~r~r~~~ ~~.~v ~~~.~1"r'~~.
i~~tr:ll~~r~.~~w.rats~~~ai.e~~~t' ['~~; ~~S~ ~: L-~. ,~;~~t~~a~~ ~~~g' ~-,.. ~_. ~~~~1.
.~attp:dl~r~a~v.s~sti~.et.e~' [:~ I~~Jr~i~rersit~ ~v V~Teste~~ia~iv. ~':~~ ~;r~~~-; i~:-~~ec~. i e~r~a~-~
~~~~~.
~ttp:ll~:~~.cs~.~~a~.~.afrese,ar~:~~'gra ~.Ii [~~~ :~~a~~i~ ~~. '~eiie:~ , .ie~r~ ~'essiev , ~;~r: gc~r vY°c~~~
~~eha~r~~. ft ~~~~~~:°r~~ sys~e~~~'a.~
y~~c~~~~~ ~r~~eczg~~a~~~ ~~~r'er~c~w~. ~~_~o~~~~ieatic~ms ~~ ~~v l~.~Ci~
~epterr~~er i~9~9 ~~~I~:e 4i ~ss~e ~.
[~~~ ~eiia .~. .Joseph , ~,. ~~er~°~ ., i~. ~i~ra'i~~~a~~.
~'~~~~v~rT~~~g~ ~rx~~~~'~~Z~ ~s~~~t~g~~°~~.~
f''J~' ~S~l~.°~''"v~J'~f"Ir~.~"'~%'~~~~~~.llg~ :ia~'aiG'1G t~3sr~
~3it~Frl~.tlt~r2af ~;~r:ø'e~°S."_'1~3: ~~ ~~~''idstI'$s'a a~~; e~gx_~eeri~g app~ycati~~s ~~ .:~~i fc~ai ~t~tei-i3g~:~ee a~~ e~c.~~ert sister's. ~~~e i ~~~.
.~ J

"'berry ~... ~ar~sse~~. l~le~work ~.~~e~~ c~~~t~~~~~~~ic .~;~-,~te~r~~o~° ~ec..i'-t~,~a~e ~°orz~~~;~1.
~roceedir~~s ef ~e seeor~d inweat~.e~~ai :~c~nfe~°r~nce on ~nci~~~s~ri~i a~ad e~gi~aee~°inb app'iea~ions of a~ifie.iai ir~~eii~Lnce and expect sysieans. ~'~ne i~~~.
2~ ~ ~J~~.;Jne ~~alier.1'~'et~.:oriC ~~axa~~;e~e~s~ ~.~~'~eg ex~e,r8 ;~iag~o.s~i':°.~. ~r:{t~~.~~~~on~.~ ~~~~,r~~i ~f l~Ie~~esh I~ii~d~a~enen~~. t=~~~~;~.~st ~.~9~. V~i~~~~e ~., L~ss~e ~~.
~2~~ ~. ~Jarrier , ~. ~'ceia~a , ~. ~ers-y , ~. ~a~.nisae~°, ~ ~ae.fo~k ~~a~~~gernent =~t:ag~soge fir ~,~~t' ~e,tv~o~-k~. 1'~~1~/~ ~~~:~~0~~i~:ornp~~er ~:or~~~niea~aor~ e~ie~xr, ~.y~r~posi~n;
pr~eeedi~zgs ~n ~o~:~~ic~r3oa~.s ax~nare:~~~aes anc'. pro~oe~;is. ~~~~~s~
i~~~. ~Joi~e i ~, ass~xe 4.
X27? ~yeon ~apa~assiiiou. l~le~~~o~k czP~~ set e9ice ~~tt~ge~~e~xt ~~~ ~va~e-a~e~x eiec9~o~ir coz~e~ce ~et~vo.~k~. y:~~erna~i4sna~ .~-~'~~~a~ of 1"~e~~ork ~a~~a~e~r~en~
I~sare~ 2:~G~i.
~'oi~n2e i 1, ~ss~e G.
~2~~ ~i~n ~tarose. ~~a~~r~~-e cia~°ec~io~,=' z~ a~e~~o~-ki~g ~resec~rch. A~C:~oa-rap~ati~g ~~,,ar~~eys (~~~Y~~ ~eeexn~er ~9~6.
~25~ ~~~ai:~~-fan '~o' '~'sai , ~~aa~~-~~i~,~ng '~o' ~i~~~a~. ~"1~~ ~h~r~~gh ~'J'~i~~'.
r,te~r:ati~r~ai ~o~rr~ai or~Teav~aori~ l~~n~~~~er:.~. I~~~ei~ i9~~~. ~;iel~n~e ~. ~ss~a~= 2.
bona-'Task ~~a , ~'~i-Jo~r~ ~i~~~i , ~a~:~~es ~l. bong. ~~e e~cve~~~ ~nc~
iigh?~eigh~
e~e~l~e~ ~7e~ .~e~ve~,~'o~ ~~~.~~-~s~,~e~ ~e~a~>o~~; eie~~xe~zt ~n~~cxge~~ter~. ~~~~eationai .~~urr~ai ~f Ne~~mriC l~a~~~~r:-r~e~~. ~~p~~;~i~er'~~dC~. ~lol~r~~~ i~, ~ss~ae ~.
1~1~.t~an ~. l~uile~-. '~,~eb-~ec~,~,ri~fp ~ctwsm~-k:.aa~a~ac~ge~e~~ ~rois.
~~a~er~arFonai ~o~rral o~~ I~'e~~o~°k ~.nage:nent. ,~esf~e~~e~- i~~'~. ~joi~arne 7 Iss~:Ee ~3~ ~ ~~aca ~a~ ~e~°i. .~e.sk~o~ vea~.~~.s ~e~-;J~.~,2d ~~e~~wori~
;~~~~gee~~~. ~nYe~°L~ationai ~~t~r~aa~ ~f I~Te~rv~,oric I~aa~a~~~uen~. ~ec~~~~ i 9~~. ~lolnr~~~ 9, ~ssr~e ~.
~~3~ Cairo ~. ~u3i~rre~. A con~ect~'oYies~ ~a;~zo~oc~~~ to i:~~egr~a,te~
a~et~~~k ~~~a~zr~ge~aea~~.
~ernationai .io~rnai of IVe~~°o~°~ T'~tdnaber~~e~r~. ~t~iy 199~~. ~oi~rne y _ss~e 4.
~3~f~.,. 3. ~. ".n. v~.r~ ee~.~~r~o~;ieis 5~j~«a~-~i~g ."he ~te%~v~~°k y.~~~t,f~gee~td~
o~g~~izo~io~. ~ternationai .o~r~ai s~f ~e~~~~r~~°i~ I~ana~errm~~.
~o~~e~nhPr ~~C~~~.
~doi~e i(3, issue ~.
i~>~

~3~~ bra-~~cc~~ ~ , "~'~~-~c c~F~~. :~e,~iyrc ~..~~ =~~~ee~ttatic~: o~et~~ror ~c raacar~r~~e~-~e~~t ~y~ter~a.~ for ir~te~Yatec~ a.~c~e~~e~t oaf ~.~i~.%,~ r.T~x~' ~ia~l~s.
9r~~c~~i~r~~ ,I~u~n~y of ~c~~~rk 1~.~~~.gc~cr~~. i~~'~~~ ~.C~~~. ~~~I~~c I~, ~ss~c ~.
I~v, ~s~s~~~. ~ ~rsic~v, ~~~. i ~r~, ~H~~~-~9I. ire-bc~.~ec~
cor~.e~~A"V.aAios~ ~a~~r~ca~e~~e~.t arc~aitect~~a°e~f~r ~~~cte~ a~et~v~a:~i~~. ~~~~-:iC, ~~rv~~p~3sio~~cc~~a cry ~.Ic~~mx~I~ pct°~.~i~:~~s ~.~°~ ~~~~gPr~~:n~ u~~p~si~~~:fi'~'~. ~-~E, ~i~c~,~~:~ra~, ~C~4~, ~1,~~. p. I?~-I~~..
~~7~ ~amr~°~ , ~., ~ , ~., x~sia ~~~, ~., ~.n~ ~3~ss?dcs, .~. ~e,~~6rc ~-~catser,~.~. ~tpe~xt.~ ~~
.~e~.~a~ale ~b~e~:t-~rie~te~ ~~yt~~are. ~~discr~-c~lc~, 1~~:=~.di~~.~, I~L~, i994.
~~.cc~~~r~ s.i: ~~~~~~~: ~ t~~a~~~'Se~vaae ~:naa~~oa~
~~~c~itectr~a~r~~~~~~~~'_~~~icc~tiore~~:ware ~~~,~~at~~ oJ,'~e~~~~iep l-i~a,~t~ti~~,~. I'~.~. ~F~csis, ~J~tJ~., ~~?I~
~.~~'~.
~~9~ ~.~. de Dicer. ~r~ ts~e ~'pecific:~ti~r off' ~"s~' ~o~ ~'o~tro~.
~~~cvcdi~gs ~i~ ~3~e ~5q~~e~97, DI~~ ~ I-~~, 199 f , I~c~r ~r~3;
Di.. ~~i~~~S. ~~~ltiYYGxZC~~~~%t ~~ ~~~~!'~~~iZLsil~i~~Ptc~~
~9~Y°JC!~3",Set, ~~.~ ~~a~~cZ~~SI.~. ~"~'~C~~~i~HY~~s ~af~~e ~°t~,~ a~~Ir~ ~~~°~g~eu~ elsir~k:~; .Ir:~g~ r~-3~, I99'~.
~~~1~ 'I'~° ,~tr~tcgis ~~~~ap. ~L ~. ~~~'~" i~"ar~a~ciaZ ~e~eh~ark~.
f~I~ ~~~I.
~~idar~-l~c~i~se~ ~~r~a::a~~. ~;~ ~:o~:~.ca~ieatio~s ~~~'r~=,~tructr~re cat a ~~~s~~-~c~c~.~: ~~~vrt~~it~es lx~.~~i~r' a~w~ ~~'r~o~~. I~~~~~st 21901 R. Al~r, ~. ~~~~rc~~a~c~is,1~~. ~~ai~~a~.c~~~, '6 .1~~. He~~i~~e:.°, ~-~ I~cr, ~.. I~Iic~iin, ~.
~if~kas, ~. ~~~ri~P. ~ ~e ~1~~-"it~~~ic ~,raiy,~es ~~~-~_~.erici ~'~~~te~~s.
'1 hc~~etic~i ~~r~ap~~ca Scicr.cc 1~~, pp. 3-~4'. I99~.
~44~~ ~isc~~ssa~~c c~licy I~c~~wa~~ki~~ ~r~r~ tj~a ~~d ~~~aliEy ~f ,~~;~~ricc-~I,~~~ hs~e ~~pcY, ~t~p:/l"~~~~d~r.ciscc.c~~~~v~~-~~~'~~~I.;c:'ccs'p~l~c~n~sw~~~p~~ec~c~~a~s_~p.l~~
I~~~ ~~~asse, ~~err~~cffr:cr, ~Ic~a~i~~~. ~~;~tay~c;~ir~e. ~7~~~a~r~øc ~o;~
~'o~tra~ off' !~~~~ita~~e~ia l~~apl~c.at~~~t5 .~a~-e~ ~n ~~~'~~. ~1~~-FcAstzs, i~a~tp:J> h~~~a:f~i~~s.~~d.del's~epl~c~~E~~ilac.I~~~~
~~dl s.~ v~r~ den I~icrwc,, ~. ~~~~~:~, i.l~!~:. ~slic ~~:~d. ~.~. ~~c~s~y.
7~e ~~,~~e.~t-.~
~9~act~ccai ~~ra~~cenor~ f~~ ~~leww~~:~ ~'.~~~ri ~aar~r~aabii~~y. ~:~J
l~ct~~rc~rk. ~r. i2 3a 3 ~.~~y/~~~.e 1998. i~~. 2~-2.~.
I~7 4~ I ~ ~~~is~~d~~r, ~. Ja~iss~_~a, ~. ~~~r~n7~> :~'.
~°e~~~°~Zi~g ~»a~~e~ ~ ~F~~ ~w~ar~c~~c~ ~'~~~
~~~g~°c~~.~.~ ~'h~ ~~i-~ggie '~r~~~-~-'~c~~~y~~~p~ct. ~.c~rQ~er~~~e iP~~er. lF'r~~;e~~ii~~s '~~~~~a~3~r~~I C~~~~~~~:v~ ~~ ~~~f~mar~,~ ~::~ii~~~,~'~~~; ~~~1. i~ 2~-~-2~2.
. ~~~e~sa~, Ice. ~~~y, ~. ~e?i~,, ~~. ~a~f~.~es~,a3. ~~hu~ is ~~har~~ ~~'~~,-~~°?
~e~~~g~ra3 sp~~iimatb~ris m' ~vasi~:ess~s ~.~d systerrfs, ~l~~~r A~~d~r~
~L~biisi~~,rs, ~ 99~.
~4~~ . ~~ii~.°, fir. ~r~i~~i~s~~, ~~. ~wd. ~~c~?--ti:~~ ~~~~~~-~~-ie~t~~~ 1~'r~~'~li~g. "~lihy :s~9~.
~5 s~ ~. F-°i~.r~i. ~<c~~~~h~~-~.s.- ~ ~i,~~~
~''~~~nca..~isc~,~~~° ~°~r~c~i~~: ~y,~~'~~ E. ,~~ie~a~~ o~.~
~'~r~~a~~er ~r~~ rnQ~~. .~aziy i ~~7.

~' ,: H
<'~X.I;Vu'Siti;1= s.~7- l>
<erusdi:definitians nams-"~I~ e~daqter"
?argeiilantes;pace="ht$p://xiuane.genie.aattaerbla.ca/qcs/"
xnrlns:',rsc9i-':http:/lschemas.xmdsoap.crgiNasdl'"
xn'iris:xs~="X12'~p:i/wrww.w3.C)rgJ~:701/~f~I_Schema.':
x;-~Insans--"http:JIldoOx.cOmhnrasp/i00lsl,ava2~rsdlro~ltputJ"
xr~lns:l~i~a=':htEp:l/schemes.xmlsoap.o~gJw;sdlh~stip/"
"Ire;~s:;s:="h~_t~:llwww.v~r;~.org/2t3C3~l~IVl~~chern~w-instance" xmlns:mime="htfpalschemas.xrnlsGap.~rg/wsdl/rs~irne/"
xmlosaoap="http://schernas,xmisoap.arg>vvsdl/soa.r~/" ~;rrtlns:Si~fa,P-!~="http://sohemas.~cm?soap.org/soa~!en,cadiQ7c~J">
<wsdiaypes>
<xsdaohema ~arge~;~~a~nespace-°Initp:lJl;l~,B»rle.s~enie.i~otta~fa.caJqo:>/''>
<rsd:cornplexTy;~e na;~e=:,~=olf~:r">
<xsdaequenoa>
<xsd:elerrtent name=':dtasz~cfdress'° tyqe="xsdatring::/>
<xsd:eiement '~anze-='filterType" type="xsdant"/>
<xsd:eiernewt game=,:r~r0tacol i yp~e° ~y~e_-"xsd:irit"/>
<xsd:eiernenf name="t~:~s:' tv~a="xsdah~rt"I>
<xsd:element ~~ame="srcAddress" Type=°xsdafring"/>
<xsd:elemeni :3ame= a,~st~tlask'' iv°le="xsdatrsng"/>
<xsd:eiement zarr~te-''sl.clYtlask" ~;%~a=°YSdatring"I>
</xsdaequence>
<J ;sd:cor;~plexT~pe>
<xsd:com~;lexTyqe name-_"~r"leter''>
<xsdaequence>
<xsd:element name=''~:~3nforming;~ctiOn" t~ye="xsdatring"/>
<xsd:elernenf name="rneteeType" .;a,pe="x~;d:int"/>
<xsd:eiernent ~aarr~e-::s~~~~n~a:~fa~~iry~,cticsn" iy~e="xsdatring"/>
<Ixsdaequence>
</xsd:ca~nplexT,iqe>
<xsd:complex i yz~e carne="i~irection''>
<xsdaequer:ce>
<xsd:element ;game=':clireciion" t.r~e-"xsd:i'~t"J>
<lxsdaequence>
<Jxsd:complexTy~pe>
<xsd:cot~nplexTyqe , afire=:,~'o~t,:>
<xsdaequence>
<xsd:element name=:'~crt" iyTqe=::xsdatring°/>
</xsdaequence>
</xsd:acl~tplexTyr~e> , </xsdacher~za>
</v~sdlaypes>
<vusdi:message name=':319~_~adapte;~ c;reaie f~;_~equest°>
<wsdl:part narrte="per" ,~~rpe="xsd:s~.;ring"/>
<wsdi:;~art r;ame~::~~., tyo~~,:tns:~iiter''l~~
<wsdi:~art nai~:>~"p2" tyr~~~-"2ns:ll~~lete: "/>
<wsdl:part name="e3" i,r~e="tns:Cj rection",r>

<'.NSdl:parr name="p~~" fya,°="fns:i~:r;"l>
</wsd!:rnessage>
<e~~sdi:rrsessage na~~e="s~>= .~dapfer_daiete~'C;_~e;~~esf">
<Sndsdl:par; n?rre-,:p~:, i~.~e-~~y;sd:sv~ring"/>
<e'vsdl:part name="off.. ~Ype=".~~s:Fiifer"l>
<yfvsdl:pari name="per,' ype="fr~s:~~efer''l>
<wsdl:part name="per" fype="frss:~5u.ecfion"!>
<t,~lsdi:par~ name="aei.° fyoe=ufns:i~C~r!"f,?
<Ivvsdi:rnessage>
<wsdl:rnessage name=::lv~_~dapver_de;efe'Ca F~esponse ">
<snrsdf:parf nars~e="response" :Il~e="~sdanf"!>
<i~~rdsdi:rr~essage>
<vusdl:rnessage na;-ne="~s~ ,~dapfer_creafe~~ ~espc>nse,">
<vvsdl:parf name="response" fype="~sd:inf"i>
<JwsaE:~Ynessage>
<wsdi:porf i ype naare="1~~~ ~dapfer°>.
<uvsdi:cperafion name=:'creafe~~" oararr~efer~rdes~="~e p~ p~ p3 p4">
<v~sdl:inpof name="crea8e ø ~" ,~;°:essage="f~-~s:~",=
.~~dapier_creafs:~~~_~ee~t~es~f"l>
<jrvsdl:ocatpc;f n~:r~~e="c;eafe~~~" ri~essaae=".ar<s:~~_=~,caapfer cre2~fe~~._~espor~se"/>
</vdsdl:o;,~eraiion>
<U~dsdl:operafsor= name="deLefe 'C" aararZ~efer~r;~er="pf3 p~ p~ p~ p~"~r <wsdl:inpuf narr~e-"dedefeT~° r:~essage="fns:~~ !~dapter_dzieie~~c~
~eefoesf"I>
«rsdf:oafp~i name="deiefe ~ ~:," r!3essac.e=".~i~~s:i~~_~.da.pfer delefea~'_~espor~se"/>
<IVVSdi:o,'"Jerafloil>
</wsdi:poriT,~pe>
«vsdi:bir;ding narc~e="~9~ ~,dapver'' ~r,~o="tr~s:~dlL t~,dapfeo.">
<soap:binding fransparf="a~tfpalsc~emas.~rnis;~ap.arglsoap/~ffp;' sf~~ie=°rpc"!>
«nrsdi:oper avian rtarne="creafe ~~":.
<soa.p:operafion -soap~uf~on=:':, s~~ip_:,~.~c:,Ji, <wsdl:inp~f r,ar~re="creafe'3~">
<soap:body ~,se-"encoded"
encodingve="~riip:liscrtes~as.x:r~alsoap.orgisoap/encoding!"
-~ar~espace="hffp://i<bane.genie.Ltoffavtra.c.algosl~li~_~.dapfer"J>
</v~'sdi:inpnf>
<wsdi:oufpof ;~a:~ne="cr eafe~~" >
<soa_p:body ~,sW="encoded"
encod:r~~t~~?u="in.a~:p://sc~erraas.x:rolsoap.org/saapler~coding/"
w;=;Eespa~e=:'i~sffp://kiaane.Belie.~otfawa.c,:~Jc~os,~f~3i_-~=:cfa;pfer°i>
<Iwsdf:oufp>.af>
<lwsdl:oper afion>
<~~~sdl:operafior na:re="deiefe~~">
<soapa7pEraflOr9 -SGa~i'Cli~r=..:: s~~l~~"~~1~C"/>
<v°~sdi:inpuf name=':deAefe~'~''>
, <soap:aody use="encoded"
e"codi~;;;gale="~fii:p:/iscbernas.x:rsCsoap.org/soap/er~codingl"
nairespace="l~ffp://kl~anv.genie.ooffa~wa..cagosl~#C_~~dapcer"l>
<Iwsdl:inpua>
<Snrsdl:o~sfpGf name=:,deiefe~":>
<soap:body ~~se="enooded"
enodir~g~zt,~~="h:r.p://scner~as.xrnlsoap.org/soap/eracodac;"
narriesaace-"i~=.sp://kleaarae.genie.s~offa°nfa.calgos;~v ~tdapfer"~'>
<l~dijsdl:oozp~af>
</wsdf:oaeration>
<,'~~9lsdl:b~ndinc>
<lAdsdI:SerS!9C° "lafi7'u,'="~e'~~i~'~~'C.'r"v~Ce:>
<L%~ISOl;pari nall'7e=Wtr ~adapfer" ~i1'3C~lilt~~="f?"!a:~i°~ s~-ld~l~fer">
<soap:address focafios3="hffv~:llkf~aoe.genie..t~offa~d~r;~.calgos/fc/"/:>
<uFIVSd(: porl>
<r'wsd~aervsoe>
</vvsdi:definificns>
i,.~P

<".'~~ ~~:p~Sv ~~ '~ ~a.S ~;~~~.~~5,~'-,fit 3~ °~~ a ~~i~~~a. ~"~9~i'~
'~;~~ ~,Li"6.~~;~;1~~ ~_ >~~~ '~,~'~~'tr ~'~~i3~~ui~i"2~: ~s'i.~S~ u~e~Cc i'r~~'~o:~~~~E ~; ~ui'21'L~~i,'~~~ ~~~~2'S9 ~~L~ n;~~: ~-~3~SgS a.r~cty~~"~3~~'I~, c~:'"z~$~(~~. "H, i~~..'~al~~d~~zY'i~~°~i ~~'ic'~I'~'$L°bt1'~i~"~ a~3 ~~ ~~,E~'a:~
~~'31a~'"~i;~
~~~ZT~~~1'd~.~°tlC2:g~'~s'Zl ~~~'~a~val~~"~S9' ~~J~ ~~:a,.z~~v~~c:
~';~tP aJ~ ~:~at~3_t~?=3~~ C~S_'1 ~~ ,no~~l~y'~6t 4:~ ~'~i~~~c~
S~~ ~~~l~~~b~~r~~~~~~~ '"i~J~ ~~~~~~'.'1'm/~Aa~~.C~1 e~~'~~~~~'w~~~~e~9 iSYCYI.V ~~~~~~~~~.
l~d~~l~~a.l~fi'1 S3u~ii~3~i1'Z'OY ~~~ ~,:~~~° CDk ~%4'J~R~ta;,~j;
~~s"~'i~~f~3.&~~~Sy ~~1~ .'w~y"~.Ee.°",~d~°~ "'S~!~~ ~~''~'t~l;
~~~11~:~9~°x~~~~ ~~'~~°~d'~_°~ ~°.5 ~~
~~°~~~ L~f m''~c°~~~d,S ~~ a ~~s"~~ ~,. C.~~~~~~12~i '~~
2i~°~~t~p~~~5fix ~~4e~:
~~,~2d~~~P~'F~:
~~~s~B~S~~~-~~,~ '~'v~~i ~i~JaS. v3/d~;~ .,'~i, ~~~~a~~~ 5~~~3~"A.:;
S'.3~~~.~SS~S t~~ ~''~l~hJa ~'~."u.~~. ~VC~v. ~ll~'~~~'~J~ly '.''~1 ~fit~.<~s~ ~~4~
~~>su~$:~~'~2~~~.C"~'vi ~I~~~~ ~~R6, ~~;C~°~',~ES~~ t.A~6'~3V_t :.~ ~%Jl~~ ~C2 'is;,~a~~S~ ~~ -~' ~r'~e~ ~iw~~,",ns~~~~gi~~ k'~~l~a~~ ~;~9 ~C
ei4 ::s ''~~$''d'V~.~e~~i.~7. ~.:r ~.~~ ~'iq~ca.'~5~,?~ai~W~° ~"~'~iil~;hy ar,(~ ~-r,~i:~h ~.1,~'a~~'~:~1~?. ~~~'~~~ ~''~15 ~iS 'eFJ~~~9 ~~'~~.~'~ ~1~~;~'~5,~-~
~~3.~9 '~CF'~ ~6~~''yV~3_~a~in's~.
o i~~~:~~r ~ ~~:~~z~ ~ r.~~~~~~~yvs~a~: ~~~~~ ~<~~ ~~ ~.~ ~~~~s~~~,.~~~~: ~~
~F~~, ~'~TSt~9 ~ TS ~~'.~~~Ya~~li,.i~: ~il~t"~1 ~~da~ ~I3~.' 't..7~~S "~c9~:~'i~jr,-~~a'~... h~'r~S a_~%_'~~S
~i$ ld~.l~z .~~,'~"~' ~;.~~' d4'~''i~'t ''a~ is'~'~'~e~-i9~~'~1 ~, C~~~~3a&_'~~ 2'~~uf°~" ~~:d'~IS:i'~'~ '',w~' "°~~~~?a;.
~J~~L~cuS~s°~9r'~9. a wG'l2'~ f~;~ ~u9~$~~
2~~.ar5~°eS~~°~~~C:~ ~~ Y2~~T~ ~~lSi .e~'1'~~~ G'%~~Y3~t'~3 ~'~F
~c.
8 ~.

a ~ ~d.d~~sS t~~ "~,'~."e'T~ ~>r'~~l~~d,h: ~ss~,:ecs, °:x,!c caY~~ ils~
e'~ 5~l~tL~~l :'Y:la~,dl~ff,f~ Sict'~lr~
~rescr~tcd in the ~g~~~~-e heio=aa.
~i __ ___ _ ___ 3rd i~a~~e ~ m ~t~ et~ re ~~~ tx~~ ~:~'~ ~ ~'~I~i~ ~~~ v ~~_ ~essi~
~:~siead of ha$~ing axed co~ne~;t-~ons f;o tie, 'T ext-b~se~l ~iient, ~lre can regroez~ the 'Text-'used c:~ie~r~ ~it~ the ~~T~i s~ro s r~e~~r ~°~x~;~or~°~t drat ~vN~ caii C~,i_~~;ssgo~a.
~.ater urn, the ~~.~ basses this co:nonent ~y rei°ercrtce to the ~S~R.
T'he ~'~l~
~j~rr~~crts" ~:'~e cii,sessi~~ aid c°~~~:~~~icafes ~.riti°3 :a.
iT s~ahcia:>ses c~ F~~z~ ~,ontair~
other ~~i~fis, then they ~riii he ai~:~ to send that saa°ne cliusessioa~ rcTerercc to the e~caps~ziated a ~I~s and sac for~,~ra~-din~ ~%iii ~e :~e~;ess~a~% anyrn~orc.
'i.'l~e. e~~iosi~ag '~lVt ren~air~s idie vrhiie enca~s~'~ated ~'~.~as take cor~roi o~~the cii~session.
~i~ce t~°~e ciPsessi~r~ ig~res ~::yo~~d vie ~~I~, tye ~:~I~ s.~:;rs alive and can r~aantain a cache or regniar expressio ns to ~~~her ii~ro~e ~eri'orrra~~ce,e 'his ec~anis~a ~s i~~e~~enred in ~~ s~~~Yees ~n~i~e~ a~ t~~ ~~e Ilsote that the c~snce~ts ~Sresented i~ the 'Thesis -rca~ain ~t~.~,~ ~risc ~r~cha~~;ed.

Claims (12)

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY OR
PRIVILEGE ARE CLAIMED ARE DEFINED AS FOLLOWS:

1. ~A computer system connected to a plurality of network elements (NE), said computer system for controlling in real-time said NE, said computer system comprising:
a first software component (control server) for controlling multiple said NE and a second middleware component allowing distributed behaviour of and client access to said first component.

2. ~The computer system of claim 1 wherein said control server further comprises: a uniform control interface for exposing high-level NE control operations to said client, said client being able to across said uniform control interface via said second middleware component; a dynamic number of Control Protocol Adapters (CPA) instances, which all implement the same said uniform control interface using possibly different implementations, each dedicated to a particular network element and responsible of mapping said uniform control interface to a series of specific low-level NE control operations; and a dispatcher component responsible of intercepting said client control requests and assigning them to appropriate said CPA instances.

3. ~The computer system of claim 2 wherein each said CPA runs in its own logical thread within a multi-threaded environment.

4. ~The computer system of claim 2 wherein said CPA further comprises: a finite state machine (FSM) component responsible of translating a particular said uniform control interface control operation to a series of textual commands to be sent to said network element via CLI
(Command Line Interface).

5. ~A method of controlling multiple heterogeneous network elements in a distributed, real-time, uniform manner, said method comprising providing a generic component based software architecture.

6. The method of claim 5 further comprising the steps of: intercepting a control command from the client, mapping said control command into an appropriate said CPA
within said CPA, determining the appropriate FSM class dynamically instantiating said appropriate FSM class in a separate logical thread, forwarding said control command to said FSM instance, waiting upon said FSM instance to carry out the CLI interaction, and terminate.

7. The method of claim 5 further comprising a method for extending the implementation of said generic architecture to expose any control interface to said clients.

8. The method of claim 5 further comprising encapsulating generic CLI
interactions with said network elements in a base FSM class.

9. The method of claim 8 wherein said generic interaction comprise the steps of: opening a TELNET or SSH (Secure SHell) connection to said network element, unless a connection is already in place with the same said network element, logging-in to said network element, providing entry and exit points for automating the CLI interaction with the NE, handing disconnections from said network element.

10. The method of claim 8 wherein said base FSM class relies on a regular expression module (REM) to parse NE CLI responses in a stream-oriented fashion.

11. The method of claim 8 further comprising providing a model and design steps to follow in order to allow asynchronous behaviour of said FSM component necessary for said control server.

12. A computer program product comprising a computer usable me~~~ having compound readable program code as well as human readable source code embodied therein, configured to control one or more NE in a network of computers; said computer program product comprising human readable source code implementing said generic software architecture.