UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Design and implementation of a ferry clip test system Parakh, Neville J. 1989

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1989_A6_7 P37.pdf [ 3.79MB ]
Metadata
JSON: 831-1.0051913.json
JSON-LD: 831-1.0051913-ld.json
RDF/XML (Pretty): 831-1.0051913-rdf.xml
RDF/JSON: 831-1.0051913-rdf.json
Turtle: 831-1.0051913-turtle.txt
N-Triples: 831-1.0051913-rdf-ntriples.txt
Original Record: 831-1.0051913-source.json
Full Text
831-1.0051913-fulltext.txt
Citation
831-1.0051913.ris

Full Text

D E S I G N A N D I M P L E M E N T A T I O N O F A F E R R Y C L I P T E S T S Y S T E M B y N E V I L L E J . P A R A K H B . S c , University of Br i t ish Co lumbia , Canada , 1987 A T H E S I S S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F M A S T E R O F S C I E N C E in T H E F A C U L T Y O F G R A D U A T E S T U D I E S ( D E P A R T M E N T O F C O M P U T E R S C I E N C E ) We accept this thesis as conforming to the required standard T H E U N I V E R S I T Y O F B R I T I S H C O L U M B I A June 1989 © Neville J . Parakh, 1989 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada Date 1 5 J O L L Y , 1 9 % ° ) . DE-6 (2/88) Abstract In order for Open Systems Interconnection (OSI) to work, protocol implementations must be tested as to their conformance to the specifications they purport to adhere. The International Standards Organization (ISO) has denned a set of abstract test methods for the conformance testing of computer communication protocols. The Ferry Clip concept is a test approach to realize those test methods. It is also a powerful tool that can be used for the diagnostic testing of communication protocols. This thesis describes the design and implementation of a Ferry Clip based test system in three different environments - UNIX, MPT and OSI-PTE. A method for structuring the system into a specialized set of modules is presented. Such a structuring scheme can considerably reduce the effort required to test different protocol implementations. Implementation issues encountered in building the system under the different hardware/software environments are discussed. The versatility of the Ferry Clip approach is further illustrated by presenting a scheme for its use in Multi-layer and Multi-party testing. ii Abbreviations ASP Abstract Service Primitive AFC Active Ferry Clip CCITT International Telegraph and Telephone Consulative Committee CPU Central Processing Unit C T M Coordinated Test Method D T M Distributed Test Method E/D Encoder/Decoder FCP Ferry Control Protocol FCTS Ferry Clip based Test System FSM Finite State Machine FTMP Ferry Transfer Medium Protocol FY-CNTL Ferry Control FY-DATA Ferry Data INET Internet IPC Interprocess Communication ISO International Standards Organization ITL Idacom Test Language LMAP Lower Mapping Module LT Lower Tester LTM Local Test Method MPT Multi-port Protocol Tester OSI Open Systems Interconnection PCO Point of Control and Observation PDU Protocol Data Unit PFC Passive Ferry Clip PT Protocol Tester P T E Protocol Testing Environment RTM Remote Test Method SAP Service Access Point iii SUT System Under Test T M Test Manager TMP Test Management Protocol UT Upper Tester iv Contents A b s t r a c t i i A b b r e v i a t i o n s iii Contents v List of Tables vi i List of Figures viii Acknowledgement ix 1 Introduction 1 1.1 Motivation 1 1.2 Introduction to Protocols 2 1.3 Introduction to Protocol Testing 3 1.4 ISO Abstract Test Methods 6 1.4.1 Local Test Method 6 1.4.2 External Test Methods 7 1.5 The Ferry Concept 9 1.6 The Ferry Clip Concept 12 1.7 Outline of Thesis 13 2 C o m p o n e n t s of a Ferry C l i p based Test System 15 2.1 Ferry Services 15 2.2 The Ferry Control Protocol 18 2.3 The Ferry Transfer Medium Protocol 19 2.4 Requirements on the System Under Test 20 2.5 Test Manager and Encoder/Decoder modules 20 2.6 Structuring the Ferry Clips 21 2.6.1 The Active Ferry Clip 21 2.6.2 The Passive Ferry Clip 22 v 3 Implementat ion of the Ferry C l i p based Test System 25 3.1 T h e Idacom M P T Implementation 25 3.1.1 Overview of the Implementation 26 3.1.2 T h e Active Ferry Cl ip 26 3.1.3 T h e Passive Ferry C l ip 31 3.1.4 T h e I U T Tested 35 3.2 T h e 0 S I - P T E Implementation 35 3.2.1 Overview of the Implementation 37 3.2.2 T h e Passive Ferry C l ip 37 3.2.3 T h e I U T Tested 41 3.3 T h e U n i x Implementation 41 3.4 Compar ison of the Lower Mapping Modules 42 3.5 Size of Modules 42 3.6 Loop-back Testing and Testing of a Nu l l I U T 44 4 F e r r y C l i p Applica t ions 45 4.1 Real izat ion of the ISO Abstract Test Methods 45 4.1.1 Realization of the Loca l Test Method 45 4.1.2 Realization of the Distr ibuted Test M e t h o d 47 4.1.3 Realization of the Remote Test Method 48 4.2 Mul t i - layer Testing using a Ferry C l ip based Test System 48 4.3 Mul t i -par ty Testing using a Ferry C l ip based Test System 53 5 Some Interesting Fer ry C l i p based Issues 58 5.1 T h e Order ing Problem 58 5.2 T h e T ime- lag Problem 62 5.3 T h e Need for using A S N . l 64 5.4 T h e Need for Exposed Interfaces 65 5.5 T h e Distr ibuted Test Method Logging Problem 66 6 Conclusions 67 6.1 Summary of Work Done 67 6.2 Future Research 69 B i b l i o g r a p h y 70 A F e r r y C o n t r o l P r o t o c o l and Ferry P D U s 72 B Passive F e r r y C l i p Lower M a p p i n g M o d u l e s 75 vi List of Tables 2.1 Ferry Data Services 16 2.2 Ferry Management Services 17 2.3 Ferry Transfer Services 18 3.1 Mapping between FT-ASPs and X.213 ASPs 40 3.2 Active Ferry Clip Module Sizes in MPT Environment 43 3.3 Passive Ferry Clip Module Sizes in MPT Environment 43 3.4 Passive Ferry Clip Module Sizes in OSI-PTE Environment 43 5.1 Incorrect Local Test Script Fragment for Transport Disconnect Phase 60 5.2 Correct Local Test Script Fragment for Transport Disconnect Phase 61 5.3 Incorrect Local Test Script Fragment for LAPB Connection/Disconnection Phase 64 vii List of Figures 1.1 OS I Reference Model 3 1.2 A Protocol Entity 4 1.3 Conceptual Testing Architecture 5 1.4 Local Test Method 7 1.5 Coordinated Test Method 8 1.6 Distributed Test Method 9 1.7 Remote Test Method 10 1.8 The Loopback Ferry Approach 11 1.9 A Ferry Clip based Test System 13 2.1 Components of a Ferry Clip based Test System 16 3.1 The Passive Ferry Clip's LMAP Command State FSM 33 3.2 The Passive Ferry Clip's LMAP Frames/Packets FSM 34 3.3 Structuring the Passive Ferry Clip in the 0SI-PTE Environment . . . 38 4.1 The Ferry Clip Local Test Approach 46 4.2 The Ferry Clip Distributed Test Approach 47 4.3 The Ferry Clip Remote Test Approach 49 4.4 Extended Multi-layer Testing using a Ferry Clip based Test System 51 4.5 A Local Single Multi-party Test Method 53 4.6 A Ferry Clip based Local Single Multi-party Test Method 55 4.7 A Modified FY-DATA PDU for Multi-party Testing 56 viii Acknowledgement First and foremost, I would like to extend a very special thanks to my supervisor Dr. Samuel T. Chanson for suggesting my thesis topic, for the many fruitful discussions we had and for always being there to advice and guide me through my research. A special thanks to my partner and close friend Bernard P. Lee for his support and deter-mination to see our project through to completion. Thanks to Dr. H X. Zeng for his advice and encouragement at the early stages of my research and for finding the time to be the second reader for this thesis. Thanks to Dr. D Rayner for his advice and encouragement. Thanks to B. Smith, I. Chan, H. See, S. Chan, V. Lee and C. Anderson for always finding the time to help me. Thanks is due to the support staff in the Department of Computer Science. A special thanks to Peter Phillips and Ming Lau for all the help they gave us is setting up our system. Thanks to the Department of Computer Science at the University of British Columbia, the Natural Sciences and Educational Research Council (NSERC) and Idacom Electronics for providing me with facilities and financial support during my research. Last but not the least, a heartfelt thanks to my parents and my brother for their endless help, support and love without which none of this would have been possible. ix Chapter 1 Introduction This chapter presents the motivation for our research. A brief introduction to protocols, O S I and some relevant features of protocol testing are presented. T h e Ferry and Ferry Cl ip concepts are also introduced, followed by a layout of the rest of the thesis. 1.1 Motivation T h e International Standards Organization ( ISO) has defined a set of abstract test methods for the purposes of protocol testing. T h e Ferry C l ip [2][3][4] concept was recently introduced as a technique for realizing these test methods. Due to its recent introduction, little work has been done to study the problems that would face the implementor of a Ferry C l ip based test system. T h e purpose of this research was to study the feasibility of using the Ferry C l i p concept in bui lding a test system. For generality in our results we chose to build the system in three different environments and use it to test a variety of protocol implementations [23]. T o study the flexibility of the Ferry Cl ip concept we chose to study its applicability to Mult i - layer and Mul t i -par ty testing. 1 CHAPTER 1. INTRODUCTION 2 1.2 Introduction to Protocols The last decade has seen major advances in the field of computer communications, to a point whereby it has been referred to as the "communication era". It is no longer accept-able for systems manufactured by a particular vendor to simply interface and communicate amongst themselves. Computers manufactured by different vendors must communicate reli-ably and efficiently with one another. To achieve this goal, standards have been established "to govern the physical, electrical and procedural characteristics" [5] of communication systems. Several standards-making bodies exist, two of the most influential being the International Stan-dards Organization (ISO) and the International Telegraph and Telephone Consulative Commit-tee (CCITT). At the basis of the procedural characteristics of a communication system lies the notion of a "communication protocol". A communication protocol (henceforth referred to as protocol) is a set of rules and conventions by which two separate entities communicate with one another. The task of providing reliable and efficient communication between two entities is far too complex to be handled by a single module. Hence, the technical committee of ISO in charge of information systems (TC97), developed a model for structuring such a system. The Open Systems Inter-connection (OSI) model organizes the communication system into 7 distinct protocol layers [9] (see figure 1.1). Each layer is entrusted with performing a subset of the overall communication tasks. It provides the layer directly above it with certain services, shielding it from the details of how these services are implemented [9]. Each layer in turn can use the services of the layer im-mediately below it. Communication between the layers is performed through well established communication points called service access points (SAPs), via the exchange of information units CHAPTER 1. INTRODUCTION 3 Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer Figure 1.1: OSI Reference Mode l called abstract service primitives (ASPs) (see figure 1.2). 1.3 Introduction to Protocol Testing Ensur ing different implementations of the same protocol will interwork involves verifying that each of the implementations conforms to the same standard. Section 21 of ISO T C 97 [8] defines a conformance testing methodology and framework. T h e "complexity of most protocols makes exhaustive testing impractical on both technical and economic grounds" [8]. Hence, ISO and C C I T T ' s goal is to develop a set of representative test cases called test suites for each O S I protocol standard. T h e test suites defined for a particular protocol are rarely "complete". Hence, conformance testing "cannot guarantee conformance to a specification since it detects errors rather than their absence. What it does do is give confidence that an implementation has the required capabilities and that its behavior conforms consistently in representative instances of communicat ion" [8]. CHAPTER 1. INTRODUCTION 4 (N • I) - entity (N • 1) - SAP (N) - entity (N) - SAP (N - 1) - entity Figure 1.2: A Protocol Entity CHAPTER 1. INTRODUCTION 5 T h e protocol being tested is referred to as the implementation under test ( IUT) and the system on which it resides is known as the system under test ( S U T ) . Figure 1.3 provides a conceptual view of the testing architecture. T h e upper tester ( U T ) provides control and obser-vation of the upper S A P of the I U T as does the lower tester ( L T ) over the lower S A P of the I U T . There is need for cooperation between the U T and the L T . T h e rules for such cooperation are called the test coordination procedures [8]. Upper Tester Test Coordination Procedures ASPs IUT ASPS PDUS Lower Tester Figure 1.3: Conceptual Test ing Architecture T o complicate matters further, the implementor need not provide access to both S A P s of the I U T . Furthermore, several protocol layers may be implemented together without respect to the layer boundaries. A t times it may even be necessary to perform testing via a system remote to the S U T , due to the fact that large and complicated testers cannot be implemented on an S U T with limited memory. CHAPTER 1. INTRODUCTION 6 1.4 ISO Abstract Test Methods To bring some order to the resulting chaos, ISO has defined four abstract test methods [8]. The choice of the appropriate test method depends on characteristics of the IUT and the SUT. For example, what SAPs access is provided to and whether the tester can reside in the SUT influence the choice of the appropriate abstract test method. Of the four test methods described, one is local and the other three external. In the local approach, the points of control and observation (PCOs) are at the service boundaries above and below the IUT. With the external approach, the LT is located remotely from the SUT and connected to it via a link or network. 1.4.1 Local Test Method In the local test method (LTM) the PCOs are located at the service boundaries above and below the IUT. "Test events are specified in terms of the ASPs above the IUT and the ASPs and protocol data units (PDUs) below the IUT" [8] (see figure 1.4). The L T M has several advantages over the external test methods. Since both the UT and the LT reside on the same system, coordination between them is quite simple. In fact a test system which uses the L T M may combine both the UT and the LT into a single tester to simplify matter even further [23]. A higher degree of control and observation over the IUT is possible in the L T M than that allowed by the external methods. This is due to the fact that the LTM has direct access to both SAPs of the IUT. However, a disadvantage of the LTM, which will be addressed again later in this chapter, is that the testers need to reside in the SUT. As explained earlier this may be difficult to accomplish on an SUT with limited memory. Even when the SUT has enough memory, protocol implementors may not desire a large and complex tester CHAPTER 1. INTRODUCTION 7 Test Coordination Procedures Figure 1.4: Local Test Method residing on their system. 1.4.2 External Test Methods ISO has defined three external test methods - the distributed, coordinated and remote test methods. "The coordinated test method (CTM) (see figure 1.5) requires that the test coordination procedures used to coordinate the realization of the upper and lower testers be achieved by means of test management protocols" (TMPs) [8). Work is currently in progress to define TMPs for the Transport and Session layer protocols. The IUT need not possess a clearly defined upper service boundary. If one is present and is accessible, the UT may use it to interface with the IUT. If the upper service boundary of the IUT is accessible via ASPs the UT can use them to observe and control the IUT. If ASPs are not provided by the IUT (e.g. X.25 packet layer in the MPT environment), the UT must use whatever mechanism the IUT provides to access and control it. CHAPTER 1. INTRODUCTION 8 It is important to note that the T M P is designed to coordinate the activities of the L T and U T . Furthermore, the T M P is dependent on the protocol layer being tested. Coordinat ion between the L T and U T can be greatly simplified by placing them in the same system. However, straightly speaking, the use of the C T M still requires a now redundant T M P be used between the L T and U T . T h e main disadvantage of the C T M is that separate T M P s must be defined for each protocol layer to be tested. Hence, a considerable amount of the test software has to be modified when testing different layers. Test •nanagementi Protocol ' POUs ASPs Service Provider Figure 1.5: Coordinated Test Method T h e distributed test method ( D T M ) (see figure 1.6) required test coordination procedures to synchronize the U T and remote L T . However, these test coordination procedures are not standardized as in the C T M . Unlike the C T M and D T M , the remote test method ( R T M ) (see figure 1.7) does not require specific functions of the U T . Hence, the R T M can be used in systems where access to the upper S A P of the I U T is not directly available. T h e R T M is favored by vendors since it places the CHAPTER 1. INTRODUCTION 9 Test Coordination Procedures PDUs Service Provider Figure 1.6: Distributed Test Method least requirements on the SUT and the IUT. However, it is incapable of control and observation of the upper service boundary of the IUT. Furthermore, the RTM "is the most complex [test method] for the test laboratory to use, because of the need to customize the means of control over the SUT during testing" [7]. The test coordination procedures are often achieved by means of a human operator who observes the test data received at the SUT and informs the remote test center of any abnormal activity. 1.5 The Ferry Concept According to Zeng [1], the D T M and C T M have become the dominant approaches due to "their applicability and comparatively complete testing capability". The D T M is primarily used for testing Application protocols, whereas the C T M is mainly used for the testing of the middle layers of the protocol stack, such as the Transport and Session protocols [7]. "However, experience shows that the usual method of realizing these approaches (using a portable test CHAPTER 1. INTRODUCTION 10 _ — _ , - Test m —Coordination-Procedures 1 UT | LT PDUs ASPS IUT Service Provider Figure 1.7: Remote Test Method responder for the IUT) is deficient in guaranteeing the synchronization between the distributed L T and U T . Also, the conflict between the power of a test responder and the ease of applying it to different SUTs is difficult to overcome without a radical architectural modification" [1]. In an attempt to solve these problems Zeng introduced a concept called the ferry concept. In essence, the ferry concept replaces the U T in the SUT by a relatively simple piece of software called the passive ferry (see figure 1.8). The U T is now moved to the remote machine on which the L T resides. The passive ferry in the SUT interacts with another module on the remote system, the active ferry, to transfer test data between the IUT and the tester. Synchronization between the U T and L T is simplified since they now both reside on the same system. At the same time the complexity of the U T can be enhanced since it is no longer limited by constraints on the S U T . Also, the portability of the software is greatly increased since now it is no longer necessary to rewrite the U T and L T when testing different protocol layers. CHAPTER 1. INTRODUCTION 11 Test Centre System System Under Test Lower Tester Upper Tester Active Ferry Passive Ferry Encoder/Decoder(E/D) IUT Ferry Channel Test Channel Figure 1.8: The Loopback Ferry Approach Figure 1.8 provides a view of a ferry based test system. The "test connection between the LT and the UT is looped back through the IUT". Both the test channel and the ferry channel go through the IUT" [1]. The active ferry is responsible for initiating the ferry channel at the start of a test session and bringing down the ferry channel at the end of a test session. The active ferry may also disconnect the ferry channel in the case where an error is detected during a test session. The passive ferry does not initiate or bring down a ferry channel connection. However, in case of an error it too may disconnect the ferry channel. Its main purpose is to transfer data received by it from the remote UT to the upper SAP of the IUT. Similarly, data sent to it from the upper SAP of the IUT is sent back to the remote UT via the ferry channel. An alternate approach suggested by Zeng is to use a separate protocol layer to provide the CHAPTER 1. INTRODUCTION 12 ferry transport medium [1]. In this case the ferry channel no longer passes through the IUT. This approach is preferable since the "ferry channel will not be affected by the misbehavior of the IUT" [3]. 1.6 The Ferry Clip Concept The ferry method is limited by the "fact that observation and control of the lower service boundary of the IUT is obtained indirectly through a peer SAP of the IUT" [4]. Hence, some state transitions such as triggering incorrect events or sending data to an unconnected IUT cannot be exercised. To overcome this problem Zeng introduced a new concept - the ferry clip concept [2][4] The ferry clip concept is an extension of the ferry concept to allow use of the L T M . A ferry clip system consists of two major components, an active ferry clip (AFC) which re-sides in the test system, and a passive ferry clip (PFC) which resides in the SUT (see figure 1.9). The two ferries use the services of the ferry control protocol (FCP) (described in chapter 2) to transfer test data between the test manager (TM) in the test system and an external IUT residing in the SUT. The FCP provides a standard interface on top of some existing protocol, such as X.25, which actually transfers the test data and which shall henceforth be referred to as the ferry transfer medium protocol (FTMP). The PFC in the SUT attaches directly to both the upper and lower SAPs of the IUT, like a clip. This allows the testers in the remote system to observe and control both SAPs of the IUT. Hence, the ferry clip concept is a way in which the LTM, D T M and RTM may be realized [4] (see figures 4.1, 4.2 and 4.3). Conformance testing can be done by the implementors during protocol development for diagnostic purposes [23]. Since diagnostic testing is performed by the vendor, all the available CHAPTER 1. INTRODUCTION 13 Test Centra System I 1 Test Manager Encoder/Decoder Active F< (try Cl ip Ferry Transrer Medium Protocol Figure 1.9: A Ferry Cl ip based Test System S A P s may be used, including those the vendor does not wish to expose to the outside world. Hence, a ferry clip based test system ( F C T S ) is ideally suited for diagnostic testing and has been successfully used by us to test the X.25 packet layer protocol and the Transport Class 0 protocol [23]. 1.7 Outline of Thesis This thesis describes the design, implementation and application of a F C T S on different hardware/software environments. A s of this date we have implemented the system on three different environments - Un ix , M P T and O S I - P T E . Unix is a popular operating system which runs on many different mainframes and workstations; M P T [20] is a general-purpose protocol tester manufactured by Idacom Electronics; and the O S I - P T E [22] is a sophisticated test system currently being built at the University of Brit ish Columbia . Th is thesis will focus on the design CHAPTER 1. INTRODUCTION 14 and experience gained in the implementation for the M P T and the O S I - P T E environments, with a brief mention of the Un ix implementation. Chapter 2 describes the ferry clip concept in more detail and provides a model for the structuring of the active and passive ferry clips in an F C T S . Chapter 3 describes the imple-mentation of the F C T S in the three environments. Chapter 4 describes describes a scheme for extending the ferry clip concept to perform Mult i - layer and Mult i -party testing. Chapter 5 discusses potential problems and describes their solutions. Chapter 6 summarizes the thesis and provides direction for future research. Append ix A contains the state transition tables for the A F C and P F C together with diagrams for the format of a ferry data and control P D U . Append ix B contains the relevant source code for the P F C L M A P modules in the M P T and O S I - P T E environments. Chapter 2 Components of a Ferry Clip based Test System T h e previous chapter introduced the ferry clip concept. Th is chapter begins with a discus-sion of the ferry service and the F C P . T h e individual components of a F C T S are described in more detail followed by a model for structuring the active and passive ferry clips. 2.1 Ferry Services T h e active and passive ferry clips provide services to their users and make use of the services provided by the underlying F T M P [4]. T h e services can be grouped into three categories. 1. Ferry Data Services T h e ferry data services constitute those services provided by the active and passive ferry clips to the T M and the I U T for the transfer of test data. T w o A S P s are provided (see table 2.1). T h e F D - D A T A r e q A S P is used by the T M to send data to the A F C and by the I U T to send data to the P F C . T h e F D - D A T A i n d A S P is invoked by the A F C to send data to the T M and by the P F C to send data to the I U T . T h e I U T is unaware of the existence of the 15 CHAPTER 2. COMPONENTS OF A FERRY CLH> BASED TEST SYSTEM 16 Test System System Under Test Test Manager (UT and LT) Encoder/Decoder I J Active Ferry Clip FSM Active Ferry Clip LMAP I Active Ferry Clip Passive Ferry Clip Passive Ferry Clip FSM IUT iterface Passive Ferry Clip LMAP I U T " 7 T J Ferry Transfer Medium Protocol Figure 2.1: Components of a Ferry Clip based Test System ASP Abbreviated as FD-DATArequest FD-DATAreq FD-DATAindication FD-DATAind Table 2.1: Ferry Data Services CHAPTER 2. COMPONENTS OF A FERRY CLIP BASED TEST SYSTEM 17 ferry data service. A n y data sent to the upper or lower S A P s of the I U T is mapped onto a F D - D A T A r e q A S P by the I U T interface module (see section 2.6.2). 2. Ferry Management Service T h e ferry management services are the services provided by the A F C to the T M for the management of the ferry channel and control functions. Six A S P s are provided (see table 2.2). ASP Abbreviated as F M - C O N N E C T r e q u e s t F M - C O N N r e q F M - C O N N E C T c o n f i r m F M - C O N N c n f F M - D I S C O N N E C T r e q u e s t F M - D I S C r e q F M - D I S C O N N E C T i n d i c a t i o n F M - D I S C i n d F M - C O N T R O L r e q u e s t F M - C N T L r e q F M - C O N T R O L c o n f i r m F M - C N T L c n f Table 2.2: Ferry Management Services T h e F M - C O N N and F M - D I S C A S P s are used to set up and bring down a ferry channel connection. T h e F M - C N T L A S P s allow the T M to change the state of the active and passive ferry clips. This can be used to perform functions such as loopback testing of the ferry channel and flow control between the two ferries (described in chapter 3). 3. Ferry Transfer Service T h e ferry transfer service constitutes those services provided by the active and passive lower mapping modules (see sections 2.6.1 and 2.6.2) to their respective finite state ma-chine modules (see sections 2.6.1 and 2.6.2). Nine A S P s are provided (see table 2.3). T h e F T - A S P s are mapped onto the A S P s of the underlying F T M P by the active and passive ferry clip's lower mapping modules. T h e F T - C O N N and F T - D I S C A S P s are used CHAPTER 2. COMPONENTS OF A FERRY CLLV BASED TEST SYSTEM 18 ASP Abbreviated as F T - C O N N E C T r e q u e s t F T - C O N N r e q F T - C O N N E C T i n d i c a t i o n F T - C O N N i n d F T - C O N N E C T r e s p o n s e F T - C O N N r s p F T - C O N N E C T c o n f i r m F T - C O N N c f m F T - D I S C O N N E C T r e q u e s t F T - D I S C r e q F T - D I S C O N N E C T i n d i c a t i o n F T - D I S C i n d F T - D A T A r e q u e s t F T - D A T A r e q F T - D A T A i n d i c a t i o n F T - D A T A i n d F T - E R R O R i n d i c a t i o n F T - E R R O R i n d Table 2,3: Ferry Transfer Services to set up the ferry channel. T h e F T - D A T A A S P s are used to send data between the two ferry clips. T h e F T - E R R O R A S P is generated by the lower mapping module when it detects the occurrence of an error. 2.2 The Ferry Control Protocol T h e purpose of the F C P is to provide a transparent, data transfer service between the two ferries, independent of the F T M P . T h e F C P is defined in terms of the ferry data, management and transfer services. Append ix A provides two tables which define the state transition rules for the active and passive ferry clips. Also provided in appendix A are the formats for the ferry data ( F Y - D A T A ) and ferry control ( F Y - C N T L ) P D U s . T h e F C P is functionally equivalent to the ISO Transport Class 0 protocol [16]. It has facilities for setting up and disconnecting a ferry channel connection. In the data transfer phase it has facilities for fragmenting and reassembling data packets. However, it has no provision for recovering from errors and thus requires a reliable F T M P . It should be noted that replacing the F C P with the ISO Transport Class 0 protocol, or for CHAPTER 2. COMPONENTS OF A FERRY CLLP BASED TEST SYSTEM 19 that matter any ISO protocol has several disadvantages. T h e F C P is a very simple and compact protocol designed to be independent of the F T M P . El iminat ing the F C P and building the ferry clips directly on the F T M P results in a rewrite of much of the ferry clips when the F T M P , which is not designed with the ferry clips in mind, is changed. Us ing a F C P has the advantage that only the A F C L M A P and P F C L M A P need to be rewritten. Furthermore, certain ferry based functions such as loop-back testing and identifying the I U T layer and S A P to which test data is to be sent need to be implemented even if the F C P is el iminated. These functions are provided by the F C P and hence little saving is made in eliminating the F C P . T h e passive ferry clip has only two states. There are several advantages to keeping the P F C portion of the F C P simple. A simpler P F C control protocol results in a smaller P F C module. Th is is important since the P F C must reside in the S U T , including S U T s with stringent memory limitations. Since part of the P F C , namely the I U T interface module, needs to be rewritten for each new protocol to be tested, keeping the P F C simple reduces the amount of work that needs to be performed to test different protocols. 2.3 The Ferry Transfer Medium Protocol In order to keep the F C P simple and easy to implement, certain requirements were placed on the F T M P . Since the F C P cannot handle lost, mangled or out of sequence packets, it is necessary that the F T M P guarantees end-to-end error free delivery of data and does not resequence data packets (i.e., Transport functionality according to the O S I / R M terminology 1 ) . T h e protocol used as the F T M P may be connection-oriented or connectionless, and either stream (e.g., Unix 'However, in the case that the tester and the SUT are directly connected, Data Link or Network layer functionality is sufficient. CHAPTER 2. COMPONENTS OF A FERRY CLLP BASED TEST SYSTEM 20 INET stream sockets [6]) or packet (e.g., X.25 [10]) oriented. 2.4 Requirements on the System Under Test In order to use the ferry clip approach the SUT should satisfy the following requirements. It must provide a communication medium for the transfer of information to and from the test system. Furthermore, the IUT must provide an interface through which the ferry clip can be attached. Ideally both the upper and lower SAPs of the IUT are exposed thereby allowing maximum degree of control and observation; this is, for example, often possible in diagnostic testing. However, the ferry clip concept can be used even if only one of the interfaces is exposed, as demonstrated by our testing of the X.25 packet layer in the MPT environment [23]. 2.5 Test Manager and Encoder/Decoder modules The T M is that component of the FCTS that oversees the operation of the system. It reads and executes the test script and logs all incoming and outgoing data exchanges for future analysis. Furthermore, it is the responsibility of the T M to continue or abort the execution of a test script if an abnormal condition is detected. The T M communicates with the AFC through the E /D module (see figure 2). The T M uses the services of the AFC by means of the FM-ASPs. The test data is encoded by the E /D module so as to make it easy for the IUT Interface to convert the test data into a form that the IUT accepts. Similarly, data received by the AFC is sent to the T M through the E /D module so that it can be converted into a format the T M understands. With the ferry clip approach, events for both SAPs of an IUT can be specified in the same test script. Furthermore, since both the UT and LT can be merged together within the T M CHAPTER 2. COMPONENTS OF A FERRY CLLP BASED TEST SYSTEM 21 on the test system, the synchronization problems between the U T and L T do not occur in a F C T S . The ferry clip concept could be extended to incorporate multiple ferry clips inside the S U T . Interaction and synchronization between different IUTs could be specified in a single test script. This could prove to be a useful feature for testing a protocol stack, allowing observation of the protocol exchanges at various layer boundaries. 2.6 Structuring the Ferry Clips This section presents a scheme for structuring the active and passive ferry clips in a F C T S (see figure 2). Structuring the system in this manner considerably reduces the amount of work necessary to test different protocol implementations. It also reduces the effort required to use a different F T M P . 2 . 6 . 1 T h e A c t i v e F e r r y C l i p The functions performed by the A F C are independent of the particular IUT being tested. Hence, changing the IUT has no effect on the A F C . However, since the A F C uses the services of an underlying F T M P , part of its code is F T M P specific. Nevertheless, a considerable portion of the A F C ' s functions such as fragmenting, reassembly and buffering of test data are operations that are independent of the F T M P . To simplify the task of modifying the A F C when a different F T M P is used, it was decided to structure the A F C into two modules (see figure 2.1) as follows. 1. The Active Ferry Clip Finite State Machine Module (AFC FSM) All functions of the A F C that are independent of the F T M P are incorporated into this module. The main function of this module is to implement the A F C ' s protocol state CHAPTER 2. COMPONENTS OF A FERRY CLLP BASED TEST SYSTEM 22 machine (see appendix A) - hence its name. Fragmenting and reassembly of test data packets as well as buffering of test data to be sent to the PFC are also performed by this module. The A F C FSM provides services to the T M module through a single interface via the FM-ASPs. It also uses the services of the the Lower Mapping Module (LMAP) through another interface by means of the FT-ASPs. 2. The Active Ferry Clip Lower Mapping Module (AFC L M A P ) This module contains all the code that is dependent on the particular FTMP. Specifically, it maps the AFC's ASPs (namely the FT-ASPs) into the ASPs or commands specific to the F T M P being used. The complexity of this mapping and hence the corresponding size of the AFC LMAP module depends on both the FTMP as well as the interface it provides. By localizing the code specific to the FTMP in this module, it is possible to change the FTMP by simply rewriting this module. No change to any other part of the AFC is required. A library of LMAP modules corresponding to different FTMPs can be set up. Thus, the problem of configuring an AFC to use a particular FTMP supported by the SUT is reduced to simply selecting an appropriate A F C LMAP module from the library. 2.6.2 The Passive Ferry Clip The chief goal in designing a PFC is to keep it small and compact so that it may be possible to implement it in a SUT with memory limitations. The PFC's code depends on both the IUT as well as the FTMP being used. Once again, our aim was to structure the PFC so CHAPTER 2. COMPONENTS OF A FERRY CLIP BASED TEST SYSTEM 23 as to facilitate the easy replacement of both the F T M P and the I U T . Hence, it was decided to structure the P F C into three modules (see figure 2) as follows. 1. Pass ive F e r r y C l i p F i n i t e State M a c h i n e M o d u l e ( P F C F S M ) This module contains all the functions of the P F C that are independent of the I U T and F T M P . It implements the P F C protocol state machine (see appendix A ) . Fragmentation, reassembly and the buffering of test data packets are also performed by this module. T h e P F C F S M provides services to the IUT Interface Module (described below) through a single interface via the F M - A S P s . It in turn uses the services of the P F C L M A P through another interface by means of the F T - A S P s . 2. Pass ive F e r r y C l i p L o w e r M a p p i n g M o d u l e ( P F C L M A P ) This module contains the code for all the P F C functions that are specific to a particular F T M P , but independent of the I U T . It maps the P F C ' s A S P s ( F T - A S P s ) into the A S P s or commands specific to the F T M P being used. Hence, it is the only module in the P F C that needs to be modified when the F T M P is replaced by a new one. 3. I U T Interface M o d u l e This module contains all the code specific to the I U T . T h e P F C interfaces with the I U T through its upper a n d / o r lower S A P s . Some data conversion is usually necessary to convert the data received by the P F C in a ferry P D U (see appendix A ) into the format used by the I U T . Th is format is often implementation dependent and therefore unique to each I U T ; hence this module needs to be rewritten or modified for each new I U T . T h e I U T interface module is subdivided into two parts - the Upper and Lower I U T Interface modules, which perform the conversions required by the upper and lower S A P s CHAPTER 2. COMPONENTS OF A FERRY CLLV BASED TEST SYSTEM of the IUT respectively. Chapter 3 Implementation of the Ferry Clip based Test System The previous chapter described a scheme for structuring the active and passive ferry clips in a FCTS. This chapter describes the use of this scheme to implement the AFC and PFC in the MPT, OSI-PTE and Unix environments. Each environment is described in detail, followed by a description of the implementation of the AFC and PFC in the environment. The discussion will focus on the MPT and OSI-PTE environments with a brief description of the Unix imple-mentation. A detailed description of the implementation of the T M and E/D can be found in [23]. 3.1 The Idacom M P T Implementation The MPT368.2 [20] is a portable protocol tester (PT) manufactured by Idacom Electronics. It runs a proprietary operating system with a built in Forth interpreter and contains three Motorola 68000 CPUs, two of which are available for implementing the FCTS. The third CPU does not have access to the RS-232 interface. However, it does have access to the modem and printer ports and can be used to control these devices. Even though memory is partitioned 25 CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 26 between the three C P U s , a C P U can access another C P U ' s memory partition. Communicat ion between the C P U s is v ia i n t e r - C P U messages. T h e operating system only allows one process per C P U and is event driven. Events are triggered by an incoming frame, a keyboard entry, a timer expiration or an i n t e r - C P U message. 3.1.1 Overview of the Implementation O u r goal was to build a F C T S that would allow us to test protocols on a P T . T w o P T s were used for this purpose - one for the test system and the other for the S U T . T h e two P T s were connected v ia an RS-232C serial cable. T h e T M , E / D and A F C were implemented as a single M P T process on one of the two available C P U s of the test system. T h e P F C and I U T were each implemented on a different C P U in the S U T . T h e P F C was separated from the I U T so as to minimize any interference it may cause on the operation of the I U T . T h e F T M P used was the X.25 packet layer protocol. 3.1.2 The Active Ferry Clip T h e A F C was structured into two modules - the A F C F S M and A F C L M A P (see figure 2.1). The Active Ferry Clip Finite State Machine Module Fragmentat ion and reassembly of data packets is necessary since the F T M P places a limit on the m a x i m u m size of a packet it will accept. T h e A F C accepts data packets of arbitrary size (upto some m a x i m u m limit) from the T M and fragments it so that each fragment can fit into an F T M P packet. T h e packet fragment size chosen must be the lesser of the active and passive ferry clip's F T M P maximum packet size. T h e packet fragments are reassembled at the P F C . T h e P F C performs similar fragmentation of data packets received from the I U T before CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 27 transmitting them to the A F C . The underlying FTMP could refuse to accept data from the A F C FSM once the FTMP's local buffers fill up. Since the AFC FSM does not buffer the data sent to it by the T M , some mechanism is needed to inform the T M to retransmit when the FTMP cannot accept a packet because its buffers are full. The scheme used is described below. When the T M sends a packet to the AFC FSM for transmission to the PFC, the AFC FSM extracts data from the packet and packs it into a FY-DATA PDU (see appendix A). It then sends the FY-DATA PDU to the AFC LMAP via a FT-DATAreq ASP for transmission to the PFC. If the F T M P accepts the packet for transmission to the PFC, the AFC LMAP returns a "packet accepted" message to the AFC FSM. The AFC FSM then extracts more data from the packet sent to it by the T M and repeats the process of sending it to the AFC LMAP until the whole data packet has been sent. Once the entire data packet is sent, the A F C FSM returns a "Ferry send completed" message to the T M . The T M can now attempt to send another packet if it so desires. If the F T M P does not accept the FY-DATA PDU due to the fact that its local buffers are full, the AFC LMAP returns a "packet not accepted" message to the AFC FSM. The AFC FSM in turn returns a "Ferry send blocked" message to the T M to inform it that the packet has not yet been sent. The process of calling the T M results in the underlying FTMP being run to clear out the FY-DATA PDUs thereby clearing the FTMP's local buffers. The T M calls the A F C FSM repeatedly with a FM-DATAreq ASP until the AFC FSM returns a "Ferry send completed" message. In this manner the T M is kept in sync with the underlying FTMP. The T M , E / D , A F C and FTMP were all implemented as a single MPT process, since they all resided on the same CPU in the test system. Hence, it was essential that the FTMP be CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 28 invoked periodically so that it could clear any waiting packets. To keep the structure of the system uniform it was decided that the T M would invoke the A F C periodically with a special service primitive, FM-FLUSH, so that the AFC could in turn invoke the FTMP to send out any waiting data packets. Hence, the T M would not have to invoke the F T M P directly. If the T M invoked the FTMP directly, part of its code would in turn be dependent on the FTMP, thereby destroying the modularity of the system. The AFC control protocol was implemented by building the A F C FSM as a simple finite state machine with three states - Disconnected, Connecting and Connected (see Appendix A). Entry to the AFC FSM was achieved through two interface points - the T M module (via the E / D module) and the AFC LMAP. Depending on the current state of the A F C FSM and the service primitive it received from the interface point, an action specified by the AFC control protocol was performed. T h e A c t i v e F e r r y C l i p L o w e r M a p p i n g M o d u l e The FTMP used in this implementation was the X.25 packet layer protocol. In the MPT version of X.25, the user must specify the frames and packets to be generated. For example, a "SABM" command would send across a data link layer "set asynchronous balanced mode" frame, and a " C A L L " command would send a packet layer "call request" packet to the peer entity. It is LMAP's responsibility to map the FT-ASP's (see table 3) into the MPT X.25 com-mands and vice-versa. For example, an FT-CONNreq requires the A F C LMAP send a "set asynchronous balanced mode" frame and wait for an "unnumbered acknowledgement" frame, after which it must send a "call request" packet and wait for a "call confirm" packet before CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 29 returning a FT-CONNcnf to the A F C FSM module. This is complicated further by the fact that other frames and packets could be received by the AFC LMAP module during the process of setting up the ferry channel connection. These must be handled by the LMAP module. With this sort of interface, the mapping between the Ferry ASPs and the FTMP commands is non-trivial. To best realize this mapping it was decided to implement the LMAP modules as a set finite state machine. An example of the FSM used to implement the PFC LMAP in the MPT environment can be found in figures 3.1 and 3.2. An F T M P Independent Flow Control Scheme The F T M P buffers test data packets until the AFC FSM or PFC FSM is ready to accept them. The PFC FSM also maintains a set of buffers to temporarily hold test data packets received from the AFC until the IUT accepts them. It is often difficult for the PFC FSM to use the same buffers that the FTMP uses as modification to the FTMP can be very complex and is sometimes not possible due to the unavailability of source code. In the general case where a different set of buffers is used by the FTMP and PFC FSM, the flow control scheme used by the FTMP is insufficient in guaranteeing that the PFC FSM's buffers will not overflow. To guarantee that the AFC will not swamp the PFC and overflow its FSM's buffers a flow control scheme independent of that used by the FTMP is required. This second level of flow control operates between the AFC FSM and PFC FSM. Since this increases the functionality of the A F C and PFC, thereby increasing the size of their code, the flow control scheme should be as simple and compact as possible. The scheme used was as follows. The "reserved bits" in the control field of a FY-CNTL PDU [4] (see appendix A) were used to implement two additional control functions, namely "flow CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 30 control on" (FT-FLOWon) and "flow control off' (FT-FLOWoff). When the P F C discovers its local buffers have filled past a certain "high-water mark" it sends a FT-FLOWon control message to the AFC. The AFC then ceases to send any further data to the PFC. However, it continues to accept data packets sent to it by the PFC, thereby allowing the P F C to clear its buffers. When the PFC's local buffers clear below a "low-water mark", it sends a FT-FLOWoff control message to the the AFC, informing it to resume sending data packets. The "high-water mark" must be chosen carefully. This is because there is a time lag be-tween the P F C discovering that the "high-water mark" has been reached and the FT-FLOWon control message reaching the AFC. During this time lag, data may still be sent to the PFC which must be ready to accept them. Hence, the "high-water mark" must be chosen so that there will still be enough space in the PFC's local buffers to accept data until the FT-FLOWon control message gets to the AFC. The additional buffers required can usually be estimated quite easily as follows: E = Maximum packet delay from P FC to AFC. B = Baud rate of the line. P = Maximum number of bits in a packet fragment. N = Number of buffers required above the "high-water mark". N =\Bx E/P] Generally, there is no problem in estimating "AT". Only in the case of long haul networks where the end-to-end delay has a high degree of variance does UE" become tricky to estimate. Overestimating uEn simply results in some buffer space being unused. However, underestimat-ing it could result in the PFC's local buffers overflowing. CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 31 It should be noted that in most cases simply allocating a large amount of buffers in the PFC FSM is adequate in insuring that the buffers will not be exhausted and hence the flow control scheme described need not be implemented. However, if the SUT has stringent memory limitations, allocating a large buffer pool in the PFC FSM may not be practical. In such a circumstance the simple flow control scheme described may be used. We note that the flow control mechanism constitutes only about 10% of the PFC code and about 5% of the AFC code. 3.1.3 The Passive Ferry Clip The PFC was implemented on one of the two available CPUs in the SUT. The other available CPU was used to run the IUT. The structuring was done in this manner so that the PFC would not interfere with the operation of the IUT. The PFC was structured into three modules - PFC FSM, PFC LMAP and the IUT Interface module. The IUT Interface module resides on the same CPU as the IUT. Communication between the PFC FSM and the IUT Interface modules was achieved by means of inter-CPU messages. T h e P a s s i v e F e r r y C l i p F i n i t e S t a t e M a c h i n e M o d u l e Three sets of buffers were maintained in the PFC FSM. The first set was to store data packets received from the A F C before they were processed. The other two sets of buffers were used to store packets to be sent to the AFC - one set for data packets and the other for control packets. The reason for separating the "data" and "control" buffers was so that higher priority could be given to packets in the control buffer. This would ensure that a FT-FLOWon control message could be sent promptly to the AFC without being delayed by waiting data packets. The PFC control protocol was implemented by building the PFC FSM as a simple finite CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 32 state machine with two state - Disconnected and Connected (see Appendix A). Entry to the PFC FSM was achieved through two interface points - the IUT Interface module and the PFC LMAP. Depending on the current state of the PFC FSM and the service primitive it received from the interface point, an action specified by the PFC control protocol was performed. The Passive Ferry Clip Lower Mapping Module As explained above, the PFC LMAP was implemented as a FSM. The FSM to realize the PFC LMAP is considerably smaller and less complicated than its A F C LMAP counterpart. The FSM for the PFC LMAP can be found in figures 3.1 and 3.2. The FSM is divided into two parts for the purpose of readability. The first FSM (figure 3.1) represents the actions taken by the LMAP module when it receives FT-ASPs from the PFC FSM. The second FSM (figure 3.2) represents the actions taken on receipt of a frame or packet from the FTMP. The IUT Interface Module In the MPT environment, the IUT interface was placed together with the IUT on a single CPU. The IUT Interface module was divided into three parts: the PFC interface, an input handler and an output handler. Simple message passing IPC is used to communicate between the PFC FSM and the IUT interface. The PFC FSM can send two types of messages to the IUT interface, namely initialize-IPC and incoming-packet. When the PFC first attaches itself to the IUT, it sends it an initialize-IPC message. On receiving this message the PFC interface initializes the IPC structures required for subsequent communication. When the PFC has a packet for the IUT, it sends the buffer address of the CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 33 Notation: +A1+B / - C means on receipt of A or B transmit C B ' — X < 3 (JX . y — > K E Y : A : +FT-CONNrsp / -FT-DISCind +FT-DATArcq / -FT-ERRORind +FT-DlSCreq / +• / -FT-ERRORind B: +FT-CONNrsp/ -FT-DISCind +FT-DATAreq / -FT-ERRORind +FT-DlSCrcq/ +• / -FT-ERRORind C: +FT-CONNrsp/ +FT-DATAreq / - D A T A p k t +•/ -FT-ERRORind D : +FT-DISCrcq/ -DlSC Passive Ferry Cl ip L M A P (Command State) F S M Figure 3.1: The Passive Ferry Clip's LMAP Command State FSM CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 34 F D A ( I B 2 I ) E KEY: A : +*frarae/ B: +CALLreq / -FT-CONNuxl C: +RESTARTreq / -FT-DISCind +DISC 1 +DM 1 +UA / D: +*pkl/ +*frame / •RRpkt 1 +RNRpkt / E: +DATApkl / -FT-DATAind +*pkt / -FT-ERRORind ••frame/ p- +REST ART req 1 + CLEAR req / -FT-DISCind +DISC1 +DM / -FT-DISCind Passive Ferry Clip LMAP (Frames/Packets) FSM Figure 3.2: The Passive Ferry Clip's LMAP Frames/Packets FSM CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 35 packet along with the destination S A P identifier to the I U T Interface module via an incoming packet message. T h e P F C interface simply puts the packet into the IUT 's buffer, and frees the buffer allocated by the P F C by replying to the incoming message. Whenever the I U T has output, the output handler is invoked. It simply allocates a common buffer and messages the P F C to handle the packet. T h e entire I U T interface was implemented in about 250 lines of For th code. Further details on the implementat ion of the I U T Interface module may be found in [23]. 3 . 1 . 4 T h e I U T T e s t e d T h e X.25 packet layer protocol was used as the I U T in the M P T environment. Only the lower S A P of the I U T was accessible; yet the F C T S proved to be an effective tool in testing the I U T . Details of the test language, procedures used and results obtained may be found in [23]. 3.2 The OSI-PTE Implementation T h e Open Systems Interconnection - Protocol Testing Environment ( O S I - P T E ) [21] [22] is a sophisticated system recently developed at the University of Br i t ish Co lumbia for the implementation and testing of communication protocols. In essence, it is the realization of the OSI reference model [9] within a single operating system process for the purpose of efficiency. Besides providing an operating environment which is close to the OSI reference model , the O S I - P T E also allows the incorporation of a T M into the system. T h e system supports all the test methods recommended by ISO, as well as passive monitoring, logging and even provides analysis capabilities. E a c h protocol is structured as a single or a group of protocol entities. E a c h protocol entity provides the entity directly above it with certain services; it in turn uses the services of the CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 36 entity directly below it. In addition to protocol entities the OSI-PTE also uses "test entities". Test entities are user programs which utilize the protocol entities to control and observe the IUT. Test entities may be specified to span several protocol layers and access several protocol entities with ASPs through SAPs located at several different service boundaries simultaneously. Communication between the entities is by means of an event-posting scheme, whereby a protocol entity posts an event to the protocol entity directly above or below it in the protocol hierarchy. An event is defined in terms of the event-id, event parameters and the service data unit. The event-id is an encoding of the service primitive for that protocol. The event param-eters are the service parameters for the service primitive encoded in the event-id. The service data unit is the data that is being sent with the service primitive. As an example, consider the ISO Transport protocol connect request service primitive. T-CONNECTreq ( src, dst, option, qos, tsdu ) where: src: Calling Transport address. dst: Called Transport address. option: Transport connect options. qos: Transport quality of service parameter. tsdu: Transport service data unit. In this example the event-id is T-CONNECTreq, the event parameters are "src", "dst", "option" and "qos" and the service data unit is "tsdu". The OSI-PTE, like the MPT's operating system, is event driven. At the heart of the system is a central dispatcher which oversees the operation of the system. The two important event types are the "message event" and a "timer expiry event". Each protocol entity can receive a CHAPTER 3. IMPLEMENTATION OF THE FERRY CLW BASED TEST SYSTEM 37 "message event" posted to either its upper or lower S A P . T h e message event would contain the event-id, event parameters and the service data unit for that event. A protocol entity may also receive notification on the expiry of a timer that it started. This notification is sent to it from the dispatcher. T h e current version of the O S I - P T E was built on a Sun 3/50, running S u n / O S 3.2 ( B S D U n i x 4.2). However, since the O S I - P T E is operating system independent, it should be possible to port our O S I - P T E portion of the F C T S to most other systems. T h e " C " programming language was used to write both the O S I - P T E and the F C T S . 3.2.1 Overview of the Implementation O u r goal was to use the existing T M and A F C built-in the M P T environment to test protocols in the O S I - P T E environment. Th is represents the typical case where the S U T and test system differ in architecture. Hence, problems faced in this implementation would be typical of the types of problems that would face the designers of a F C T S . T o achieve this goal we needed to build a P F C in the O S I - P T E environment. It was decided to use the X.25 packet layer protocol as the F T M P , since this was the protocol used as the F T M P in the M P T environment. T h e ISO Transport Class 0 protocol [16] was chosen as the I U T . 3.2.2 The Passive Ferry Clip T h e first problem faced was how to structure the P F C in the O S I - P T E environment. A normal ISO protocol has two well defined S A P s by which it interfaces to the protocol directly above and below it in the protocol hierarchy. T h e O S I - P T E was designed to implement pro-tocols of this nature. T h e P F C is different in that it requires three access points, one to the CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 38 protocol being used as the FTMP and the other two to the two SAPs of the IUT. Hence, some restructuring was necessary to build a PFC in this environment. Using the scheme for structuring the PFC discussed in chapter 2, it was decided to structure the PFC as depicted in figure 3.3. i Upper IUT Interface IUT Lower IUT Interface Passive Ferry Clip FSM LMAP X25 Packet Layer Figure 3.3: Structuring the Passive Ferry Clip in the OSI-PTE Environment CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLP BASED TEST SYSTEM 39 The PFC FSM was implemented as a single protocol entity. The IUT Interface was sub-divided into the Lower and Upper IUT Interface modules, each implemented as a separate protocol entity. The system is now modular and fits well into the general structure of the OSI-PTE. The Passive Ferry Clip Finite State Machine Module Functionally, the PFC FSM is very similar to that implemented in the MPT environment. Received packet fragments are unpacked from the ferry PDU format and sent via the event posting scheme to the Lower or Upper IUT Interface. Similarly, packets received from the Upper or Lower IUT Interface entities are fragmented and sent to the AFC. The Passive Ferry Clip Lower Mapping Module The F T M P used was the X.25 packet layer protocol which provides the user with an X.213 interface [11] [12]. The user may use this protocol by invoking it with the X.213 service primitives. With this interface the mapping between the ferry FT-ASPs and the X.213 ASPs is one-to-one (see table 3.1). Hence the LMAP module is trivial. The code for the LMAP module can be found in appendix B. The IUT Interface Module The IUT Interface module was subdivided into two entities - the Upper and Lower IUT Interfaces. The Upper IUT Interface converted data received from the AFC in an FY-DATA PDU into a form that could be accepted by the upper SAP of the IUT. It also converted data sent by the IUT to its upper SAP into a format that could be sent in a FY-DATA PDU and that CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 40 X.213 ASP FT-ASP N-CONNECTindication FT-CONNind N-CONNECTresponse FT-CONNrsp N-DISCONNECTrequest FT-DISCreq N-DISCONNECTindication FT-DISCind N-DATArequest FT-DATAreq N-DATAindication FT-DATAind All other ASPs FT-ERRORind Table 3.1: Mapping between FT-ASPs and X.213 ASPs the E/D in the test system could understand. The Lower IUT Interface performed a similar set of mappings for the lower SAP of the IUT. The IUT expects data in the form of a message event. Hence, it is necessary to convert the bit stream received in a FY-DATA PDU into an event-id, event parameters and a service data unit. It was decided that the E / D module on the MPT make three FD-DATAreq calls to the A F C FSM for each IUT event. The first call would contain the event-id, the second a linear encoding of the event parameters and the third call would contain the service data unit. Each call results in separate a FY-DATA PDUs being sent to the PFC. The reason for separating the ASP into three calls is for generality and reasons dictated by the OSI-PTE environment. Not all IUT events require event parameters and service data units. To handle this the first byte of the second FD-DATAreq was used to indicate the absence or presence of the event parameters. If this byte was set to "1" the IUT Interface could expect the event parameters to follow. Similarly, the second byte was used to indicate the absence or presence of a service data unit. This scheme is sufficiently general so that it can be used for any protocol in the OSI-PTE environment. CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLV BASED TEST SYSTEM 41 3.2.3 The IUT Tested T h e ITJT tested by this implementation of the F C T S was the ISO Transport Class 0 protocol. B o t h S A P s of the protocol were accessible and so a thorough diagnostic testing could be performed. In fact, the F C T S proved to be quite an effective tool in detecting problems with the I U T and aiding in their solution. A detailed description of the diagnostic testing of this I U T can be found in [23]. 3.3 The Unix Implementation U n i x is a powerful and widely used operating system. T h e U n i x environment used to develop the F C T S consisted of a pair of S U N 3/50 workstations connected v ia an ethernet local area network. E a c h workstation ran a version of U n i x B S D 4.2 ( S u n / O S 3.2). T h e F C T S was implemented as a set of three processes. T h e T M , E / D and A F C were struc-tured into a single process running on one workstation. T h e P F C and I U T were implemented as two separate processes running on the other workstation. Communicat ion between the ferry clips was achieved using U n i x stream sockets in the internetwork domain ( T C P / I P ) [6]. Th is particular type of socket was chosen since it best fit the F T M P requirements (see chapter 2). T h e protocol tested using this F C T S implementation was the X.25 packet layer protocol [23]. T h e main challenge faced in this implementation was devicing a scheme to prevent a deadlock occurring between the A F C and P F C processes. W h e n a process writes to a socket, the "write operation" will block if the socket's internal buffers are full. T h e socket's buffers are cleared when the process at the other end reads data off the socket. If both the A F C and P F C processes send data to an F T M P socket whose buffers are full , both will block and wait for the other to CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLV BASED TEST SYSTEM 42 clear the socket's buffers. This problem may be solved by making the write operation performed by the A F C non-blocking. Hence, the A F C could always clear a blocked PFC's buffers, thereby preventing a deadlock from occurring. 3.4 Comparison of the Lower Mapping Modules The size of the LMAP module depends not only on the protocol used as the FTMP, but also on the type of interface the protocol provides. In our implementations, the X.25 packet layer protocol was used as the FTMP in both the MPT and OSI-PTE implementations. Appendix B contains the sources for the PFC LMAP in both these environments. The MPT version of the PFC LMAP constitutes a large portion of the overall size of the PFC. It is considerably more complicated than its OSI-PTE counterpart and required more time to write and test. In contrast the OSI-PTE version of the PFC LMAP constitutes only a small portion of the overall size of the PFC and was trivial to write and test. This difference was due to the different user interfaces provided by the two different protocol implementations. The LMAP module should not need to be changed if a different implementation of the same protocol is used as the FTMP on the other system. In our case, the same A F C LMAP was used to interface with the PFC LMAP in both the MPT and OSI-PTE environments. 3.5 Size of Modules The MPT implementation of the AFC and PFC was coded in Forth. The OSI-PTE imple-mentation of the PFC was coded in C. The following tables summarize the size of the various FCTS modules in terms of number of lines of code excluding comments. CHAPTER 3. IMPLEMENTATION OF THE FERRY CLLV BASED TEST SYSTEM Module Lines of Forth code A F C F S M 580 A F C L M A P 540 Support Routines 420 Table 3.2: Act ive Ferry Cl ip Module Sizes in M P T Environment Module Lines of Forth code P F C F S M 600 P F C L M A P 300 I U T Interface Module 250 Support Routines 500 Table 3.3: Passive Ferry Cl ip Module Sizes in M P T Environment Module Lines of C code P F C F S M 540 P F C L M A P 190 I U T Interface Module 1250 Tab le 3.4: Passive Ferry Cl ip Module Sizes in O S I - P T E Environment CHAPTER 3. IMPLEMENTATION OF THE FERRY CLIP BASED TEST SYSTEM 44 3.6 Loop-back Testing and Testing of a Null IUT The FCP has a facility called "loop-back testing" to aid in the testing of the PFC FSM and the test channel. The A F C puts the PFC into loop-back mode by sending it a FY-CNTL PDU with the L-bit set (see appendix A). While in loop-back mode the PFC returns any data it receives from the AFC to the AFC after toggling the upper/lower (U/L) bit in the FY-DATA PDU. The data is not sent to the IUT. Also, while the PFC is in loop-back mode any data received by it from the IUT is discarded. In this manner the A F C can check the FY-DATA PDU it sends against what it receives to ensure that the PFC is functioning properly and that data is not being altered by the FTMP. The PFC is put back into normal mode when it receives a FY-CNTL PDU from the A F C with the L-bit turned off. Loop-back testing is a useful feature that allows testing of a new PFC FSM or FTMP. How-ever, since no data is sent to the IUT it cannot test if the IUT Interface module is functioning correctly. It is very important to test the IUT Interface module before actually using the FCTS. To do this we used a "Null IUT". The Null IUT is a trivial protocol which simply returns data it receives without altering it in any way. Data received by the Null IUT on its lower SAP is returned via its upper SAP and vice-versa. Hence, the AFC can check if the IUT Interface module is functioning correctly. On bringing up a new system, we first performed loop-back testing to verify that the PFC FSM was functioning properly. Once this was done, we added a Null IUT to the system to test the IUT Interface module. If data was altered in any way, we would know immediately that the problem was caused by a faulty IUT Interface module. Chapter 4 Ferry Clip Applications The previous chapter described the implementation of a F C T S . This chapter illustrates the versatility of the ferry clip concept by describing some of its applications. The manner in which the ISO Abstract Test Methods (see chapter 1) can be realized using a F C T S is described. Also described are extensions to the ferry clip concept to perform Multi-layer and Multi-party testing. 4.1 Realization of the ISO Abstract Test Methods A F C T S can be used to realize the Local, Distributed and Remote abstract test methods. There are several advantages in using a F C T S to do this. The L T and U T no longer need to reside in the S U T . Since both the L T and U T now reside in the test system, synchronization between them is simplified. 4.1.1 R e a l i z a t i o n of the L o c a l T e s t M e t h o d The L T M is the most powerful of all the test methods. Since it has access to both the upper and lower service boundaries of the IUT it is possible to use it to exercise those state transitions of the IUT that would be difficult or impossible to reach using the other test methods. The 45 CHAPTER 4. FERRY CLIP APPLICATIONS 46 main disadvantages of the conventional LTM, which often makes its use impractical, are that both the LT and UT need to reside in the SUT and the need to have direct access to both the upper and lower service boundaries of the IUT. T e s t S y s t e m L _ J S y s t e m U n d e r T e s t F T M P Figure 4.1: The Ferry Clip Local Test Approach Figure 4.1 shows how the ferry clip approach can be used to realize the LTM. The PFC is the only part of the FCTS that must reside in the SUT; the LT and UT now both reside in the test system. The PFC is small and simple to write. Due to its small size it can even be implemented in systems with stringent memory limitations. Hence, the ferry clip approach makes the LTM feasible. Furthermore commercial protocol testers which offer many facilities CHAPTER 4. FERRY CLIP APPLICATIONS 47 already built i n , such as data logging and analysis capabilities can be used as the external tester. We have used the ferry clip based L T M quite successfully to test the X.25 packet layer protocol and the ISO Transport Class 0 protocol. For further details see [23]. 4.1.2 R e a l i z a t i o n of the D i s t r i b u t e d Test M e t h o d In the D T M the lower service interface of the I U T is accessed indirectly v ia the protocol layers below the I U T . Us ing a F C T S to realize the D T M , the upper service interface of the I U T can be accessed v ia the ferry clips as shown in figure 4.2. T e s t S y s t e m L U p p e r T e s t e r L o w e r T e s t e r Layers Below IUT Figure 4.2: T h e Ferry C l ip Distr ibuted Test Approach CHAPTER 4. FERRY CLIP APPLICATIONS 48 T h e main problem with using the conventional D T M is that synchronization procedures are required between the L T in the test system and the remote U T in the S U T . Using a F C T S to realize the D T M simplifies this problem since both the L T and U T now reside on the same system. In fact the L T and U T may now be combined into a single tester [23] thereby eliminating the synchronization problem altogether. 4.1.3 Realization of the Remote Test M e t h o d In the R T M no access is provided to the upper service interface of the I U T . In the conven-tional R T M , the lower service interface of the I U T is accessed indirectly via the protocol layers directly below the I U T . W h e n a F C T S is used to realize the R T M , test data is sent directly to the lower service interface of the I U T via the two ferry clips (see figure 4.3). Since the lower service interface of the I U T is accessed directly, certain test cases (e.g. sending the I U T incorrect data via its lower service interface) which cannot be handled by the conventional R T M can now be performed. Hence, the F C T S version of the R T M is considerably more powerful than its conventional counterpart. It has been suggested that the C T M can be used as an alternative to the ferry clip approach. T h e disadvantage of doing so is that the C T M requires a specific T M P s be written for each layer to be tested. Hence, a considerable amount of tester software needs to be modified for testing different layers. 4.2 Multi-layer Testing using a Ferry Clip based Test System Mult i - layer testing involves testing "a set of any number of adjacent layers of the S U T " [8] in combination with access only to the lower and /or upper service boundaries of the protocol stack. Lit t le addit ional work needs to be done to use a F C T S to test a Mult i - layer I U T . CHAPTER 4. FERRY CLIP APPLICATIONS 49 T e s t S y s t e m r S y s t e m U n d e r T e s t 1 I I A c t i v e ] ] P a s s i v e L o w e r T e s t e r F e r r y 1 , F e r r y C l i p 1 1 C l i p IUT _ J I I F T M P Figure 4.3: The Ferry Clip Remote Test Approach CHAPTER 4. FERRY CLIP APPLICATIONS 50 Replacing the term "IUT" in figures 4.1, 4.2 and 4.3 with the term "Multi-layer IUT" depicts how a FCTS can be used to perform Multi-layer testing. It is important to note that only the upper service interface of the highest layer and the lower service interface of the lowest layer in the Multi-layer IUT are accessed by these methods. At times it is convenient to observe and control the data exchanges at some or all the service boundaries within a Multi-layer IUT. It is important to note that this form of testing a Multi-layer IUT is no longer ISO Multi-layer testing due to the fact that service boundaries other than the upper and lower ones are being accessed. It is possible to adapt a FCTS to do this. We refer to this form of testing a Multi-layer IUT as "Extended Multi-layer testing". To observe the data exchanges at the boundary between two layers requires the data that is normally sent between two adjacent layers is also trapped by the PFC and sent to the remote T M . Figure 4.4 illustrates how a FCTS may be used to perform Extended Multi-layer testing. Only the PFC needs to be modified. The existing FCP already has a provision (the Li-bits in an FY-DATA PDU) to send data to and receive data from several protocol layers in the SUT simultaneously (see appendix A). However, if the PFC clips on to the upper and lower service interfaces of the individual layers within a Multi-layer IUT, the links between the individual layers will now be broken. This means that data sent by a (N)-entity to its upper service inter-face, normally destined for (N-f-l)-entity, is now sent to the PFC instead. Similarly, data sent by a (N)-entity to its lower service interface, normally destined for (N-l)-entity, is also rerouted to the PFC. To rectify this the PFC control protocol needs to be modified slightly as follows. UN' Data sent to upper service interface of layer N and received by the PFC FSM. LN'- Data sent to lower service interface of layer N and received by the PFC FSM. h: Highest layer of Multi-layer IUT. CHAPTER 4. FERRY CLIP APPLICATIONS 51 T e s t S y s t e m I 1 S y s t e m U n d e r T e s t T e s t M a n a g e r I E n c o d e r / D e c o d e r 1 J L Figure 4.4: Extended Multi-layer Testing using a Ferry Clip based Test System CHAPTER 4. FERRY CLIP APPLICATIONS 52 /: Lowest layer of Multi-layer IUT. case(i): (UN AND N = h) OR [LN AND N = I) Response: Forward data to AFC. case(ii): (UN AND N ^ h) Response: (a) Forward data to AFC, and (b) Send data to lower service interface of layer ( T V + 1). case(iii): (LN AND N ^ I) Response: (a) Forward data to AFC, and (b) Send data to upper service interface of layer (N — 1). The PFC FSM can easily be modified to incorporate this change in the PFC control protocol. In this fashion data sent between two adjacent layers of a Multi-layer IUT can also be trapped and sent to the T M on the remote system. The T M can also send data to any of the service interfaces of the Multi-layer IUT. Hence, for example it could send incorrect data to a particular service interface and observe the responses produces at the other service interfaces of the Multi-layer IUT. CHAPTER 4. FERRY CLIP APPLICATIONS 53 4.3 Multi-party Testing using a Ferry Clip based Test System Multi-party test methods "involve one or more LTs cooperating with one or more UTs" [15] via a number of connections through a IUT. Tester Synchronization Procedures Lower T t s u r Cooratnation Proceoure» Figure 4.5: A Local Single Multi-party Test Method Figure 4.5 illustrates how the L T M can be adapted to perform Multi-party testing of a single or multi-layer IUT. Traditionally one of the LTs is designated as the "master" LT. It initiates a test case and collects observations from the other LTs and UTs so that it may analyze the CHAPTER 4. FERRY CLIP APPLICATIONS 54 observations and assign a verdict. "There is a one-to-one correspondence between each LT and UT, making pairs of testers surrounding the IUT" [15]. Some form of synchronization is required between the LTs. Also required is an ability for the LTs to communicate synchronously and asynchronously amongst themselves. Furthermore, coordination procedures are also required between the LTs and UTs. This coordination is more difficult to achieve in the conventional distributed Multi-party test method than with the conventional local Multi-party method due to the fact that in the distributed Multi-party method the UTs and LTs reside on different systems. There are numerous instances where Multi-party testing of an IUT is necessary. For exam-ple, to test the ability of a MHS entity [13] to create a second copy of a message so that it may be relayed to two different domains requires the use of a Multi-party test method with three LTs. One of the LTs is the originator of the message and the other two are the recipients. Most protocols that support multiple connections do so by using a field in the data sent or received by them to specify the connection identifier. In this case the existing FCTS can be used without modification to do Multi-party testing. However, in the case that the protocol provides different physical connections (e.g. Unix socket connections) for sending and receiving data, a small modification is required to use the FCTS to perform Multi-party testing as illustrated in figure 4.6. Each individual connection is handled by an upper and lower IUT Interface module pair. Test data sent to the PFC FSM now requires some indication of what connection (IUT Interface) the data is to be sent to. Similarly, data received by the PFC FSM from a particular connection of the IUT requires that an indication of the data connection be sent to the AFC along with the test data. To handle this we propose a minor change in the format of a FY-DATA PDU. CHAPTER 4. FERRY CLIP APPLICATIONS Test System System Under Test UpperIUT Interface l Uppe inte rlUT -face UpperIUT Interface 3 Lower IUT interface I Lower IUT interface 2 Lower IUT Interface 3 Figure 4.6: A Ferry Clip based Local Single Multi-party Test Method CHAPTER 4. FERRY CLIP APPLICATIONS 56 Header Field Connection Field Length Field Data Field 1 Byte 1 Byte 2 Bytes Connection Id = 8 Bits = 256 possible connections Figure 4.7: A Modified FY-DATA PDU for Multi-party Testing Figure 4.7 illustrates the new proposed format of the FY-DATA PDU. The only change is the addition of a "connection byte" which specifies the connection the test data is being sent to or received from. In reality a separate IUT Interface pair is not required for each connection through the IUT. A single upper and lower IUT Interface would suffice. The IUT interface would now be responsible for the mapping between a connection-id (indicated by the connection byte) and an actual connection through the IUT and vice-versa. There are several advantages to using a FCTS to realize a Multi-party test method. The LTs and UTs can all be moved to the test system, thereby simplifying the coordination procedures between the LTs and their corresponding UTs. Furthermore since all the testers now reside on the same system, it may be possible to implement them as a single tester, thereby eliminating CHAPTER 4. FERRY CLIP APPLICATIONS 57 the synchronization problem altogether. The space requirements of placing several LTs and UTs in the SUT would often render the Local Multi-party test method infeasible, were it not implemented using a FCTS. Even the Distributed Multi-party test method requires several UTs to be placed in the SUT. This too may be infeasible if not realized using a FCTS. Finally, the tester software (LT and UT) in a FCTS completely resides on the test system unlike the conventional test method which requires part of the tester software to reside in the SUT. Hence, in a FCTS the tester software need only be written once for the test system instead of having to be rewritten for each new SUT. This is probably the greatest advantage of using a FCTS to implement a Multi-party test method, considering the potential size and complexity of the tester software required to perform Multi-party testing. Chapter 5 Some Interesting Ferry Clip based Issues The previous chapter described some applications of a FCTS. This chapter deals with some interesting issues that arise from using a FCTS. These issues can be broadly divided into two classes - conceptual and implementation based. The conceptual issues discussed are the "ordering" and "time-lag" problems. Chapter 3 described some implementation based problems encountered while building a FCTS. This chapter addresses two other implementation based issues, namely the need to use ASN.l [14] and the requirement that the IUT have exposed interfaces. Some other miscellaneous issues are also discussed. 5.1 The Ordering Problem When a protocol entity needs to communicate with the entity directly above it in the protocol stack, it invokes an ASP at its upper SAP. This ASP is received by the layer directly above the sending entity via its lower SAP. Similarly, when a protocol entity needs the services of the entity directly below it, it invokes an ASP at its lower SAP which in turn is received by the entity below it via its upper SAP. 58 CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 59 In the case of an event driven system, when an entity invokes an A S P at its upper or lower S A P , an event is automatically generated by the system for the recipient of that A S P (see OSI-P T E in chapter 3). Normal ly , protocol entities are combined into a single operating system process (e.g. the O S I - P T E environment). A t most each protocol entity may be implemented as a single process. In both of these cases, events can never be generated simultaneously at both S A P s of a protocol entity. N o ambiguity exists here since even if an A S P is invoked almost simultaneously at each S A P of the entity, the system will generate events for the respective recipient entities in the order in which they were generated by the sending entity. When a F C T S is used to realize the L T M , the P F C will be the recipient of the A S P s from both S A P s of the I U T . In an event driven system, the P F C is guaranteed to receive the A S P s in the order in which they were sent by the I U T . Since neither the P F C nor the A F C reorder the A S P s , the tester in turn receives the A S P s in the order in which the I U T generated them. In a non-event based system (e.g. the U n i x environment), the P F C often needs to poll both S A P s of the I U T to check if an A S P has been invoked at a particular S A P . A potential problem could occur with poll ing the S A P s . If the I U T generates an A S P almost simultaneously for both its upper and lower S A P s , the order of polling the S A P s could result in the second A S P invoked by the I U T being detected first by the P F C . This phenomenon is referred to as the "ordering problem". A number of protocols were studied to see if A S P s were ever invoked simultaneously at both S A P s of a protocol and if so whether it could cause a problem. T h e protocols studied were X.25 (data link and packet layer protocols)[10], the ISO Trans-port protocols ( T P O to T P 4 ) [16] and F T A M [17]. It was observed that in the few cases that a protocol generated an A S P (or P D U ) almost simultaneously at both its upper and lower S A P s , the protocol standard did not specify the order in which the A S P s (or P D U s ) were to be sent CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 60 by the protocol. Hence, no harm was done if the PFC received the second ASP (or PDU) sent by the IUT before the first one. An example of such behavior can be seen in the disconnect phase of the ISO Transport protocol. When the Transport protocol receives a "DR" (disconnect request) PDU from its lower SAP it responds by sending a " D C " (disconnect confirm) PDU to its lower SAP and a T_DISCind ASP to its upper SAP. The ISO standard does not specify which event should be performed first and hence no assumption can be made about the relative order of these events in a test script. Table 5.1 contains an example of an incorrectly written "local test script" fragment to test the disconnect phase of the Transport protocol. Event Verdict L! DR L? DC U? T_DISCind PASS Default FAIL Table 5.1: Incorrect Local Test Script Fragment for Transport Disconnect Phase The problem with this test script fragment is that it assumes that a " D C " PDU will be received at the lower SAP before the "TJDISCind" ASP is received at the upper SAP. Since the protocol standard specifies no such ordering, different implementations of this protocol may generate these events in different order. Hence, with the above test script it is possible that a "conforming" IUT is given a FAIL verdict. A correct test script fragment to test the disconnect phase of the Transport Protocol would CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 61 Event Verdict L! DR U? TJDISCind L? DC Default PASS FAIL L? DC U? T_DISCind Default FAIL PASS Default FAIL Table 5.2: Correct Local Test Script Fragment for Transport Disconnect Phase be as provided in table 5.1. In this test script no order is implied of the ASPs (or PDUs) to be received at the upper and lower SAPs. A protocol that generates ASPs (or PDUs) almost simultaneously at both its upper and lower SAPs may require one of the ASPs (or PDUs) be received first by the recipient entity. To achieve this, the protocol must send the first ASP (or PDU) and then wait for an acknowl-edgement from the recipient entity. On receipt of this acknowledgement, the protocol may then send the second ASP (or PDU). Our study of a number of ISO protocols showed that this mechanism was always employed whenever the order of packets to be received is significant. In this case, since the ASPs (or PDUs) are no longer sent simultaneously, the ordering problem does not arise. In the case when order of receipt of ASPs (or PDUs) does not matter, the ISO document does not specify which ASP (or PDU) is to be sent first. Hence, no problem results if the order of polling the SAPs results in the second ASP (or PDU) sent by the protocol being received first by the PFC. CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 62 5.2 The Time-lag Problem In a FCTS, the tester and IUT reside on different computer systems. Hence, there is a time lag between the IUT generating an ASP (or PDU) at one of its SAPs and the corresponding ASP (or PDU) being received by the tester. Correspondingly, there is a time lag between the tester sending test data and the IUT receiving it. The tester assuming the IUT to be in a certain state could send it some test data and in doing so expect a certain reaction from the IUT based on the test data it has sent. In the meantime the IUT not yet having received this test data from the tester may also send the tester some data, based on the state it thinks the tester is in. It too may expect a response from the tester based on the data it has just sent. Each system now possesses incorrect state information about the other system. Our concern was whether this apparent inconsistency of states could cause the FCTS to give an incorrect verdict. This problem is referred to as the "time-lag problem". It is important to note that the time-lag problem is not unique to test systems based on the ferry clip concept. It can occur in conventional test systems too. The probability of it occurring in the ferry clip version of the L T M is higher due to the fact that both the LT and UT are on a physically different system from the IUT, thereby stretching the time-lag even further. Furthermore, the problem is even more likely to occur when the two systems are connected by a long-haul network, where there may be long time delays associated with data traveling between the two systems. No time-lag based problems were detected in our implementations. Hence, once again X.25, the Transport protocols and F T A M were studied to see if the time-lag problem was possible and whether it could cause a problem. CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 63 From the protocols studied it was observed that a protocol entity normally responds only when data is sent to it. Hence, in normal operation the time-lag problem will not occur since the protocol being tested will only send data after it has received data from the tester. As long as the test script is correctly written and the IUT conforms, the tester will know exactly what it should receive from the IUT. Any unexpected data received by the tester from the IUT would result in a "FALL verdict". Some unusual behavior is possible when a protocol that uses timers has its timeout value set too small. The solution is to increase the value of the timeout variable in the protocol. Care must be taken in writing a test script to handle such a situation as illustrated by the following example. Consider a FCTS being used to test the LAPB protocol's [10] link connection and discon-nection capability. Furthermore, consider the IUT to be set up as a DCE. The IUT initiates the connection by sending a SABM frame with the poll-bit set and expecting a UA frame with the final-bit set. At the same time it starts timer T l . If the timeout value of timer T l is too short and expires before the UA frame arrives from the tester, the IUT will resend a SABM frame with the poll bit set and restart timer T l . The tester will receive two SABM frames instead of just the one it expects. Table 5.2 contains an incorrect test script fragment to test LAPB link setup and disconnection. When the tester receives the second SABM frame instead of the DISC frame it expects it concludes the IUT is non-conforming and passes a "FALL verdict". Hence, as can be seen from this example, if the test script writer is not careful to account for the possibility of a timeout, a "fail verdict" could be passed for a conforming IUT. No situation was observed where the time-lag problem would cause incorrect operation of CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 64 Event Verdict U! Set_Up_Link L? S A B M ( P o l l bit set) L! U A ( F i n a l bit set) U ! Disconnect_Link L? D I S C L! U A P A S S Default F A I L Default F A I L Tab le 5.3: Incorrect Local Test Script Fragment for L A P B Connect ion/Disconnect ion Phase the F C T S . Hence, from our case study, we conclude that the time-lag issue is not generally a problem. 5.3 T h e N e e d for u s i n g A S N . l In all three environments in which our F C T S was built , the test system and the S U T had the same C P U architecture, namely all were Motorola 68000 based processors. Hence, the basic data types had the same representation on both the test system and the S U T . A more general situation would be one in which the architecture of the test system and the S U T differ, resulting in incompatible basic data types between the two machines. For example on one machine (e.g. I B M - P C ) the representation for the basic data type "integer" may be 16 bits and on another (e.g. Sun 3/50) it may be 32 bits. In such a heterogeneous environment, it is the E / D module's job to convert the test data to be sent to the S U T into the data representation that is accepted by the S U T . Similarly, the E / D module is also responsible for mapping the data received from the S U T into the data CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 65 representation accepted by the test system. Bochmann [19] suggested using a standard data representation technique, such as ASN.l . Using ASN.l has the advantage that a large portion of the E/D module that was previously involved with mapping between incompatible data representations can be written once in ASN.l with little or no change required to it when testing different implementations of the same protocol on different SUTs. However, this assumes that an ASN.l compiler is available on both the test system as well as the SUT. In practice this may not be the case. We were unable to use ASN.l in our system due to the fact that although an ASN.l compiler was available for the SUT, none was available for our test system. 5.4 The Need for Exposed Interfaces One of the main objections from opponents of the ferry clip approach is that the use of the ferry clip method requires the IUT expose one or both of its service interfaces. Recent trends have shown that vendors do not wish to expose the service interfaces of their products. Furthermore, several layers are usually implemented together as a single product, with no exposed interfaces in between the layers. However, the need for exposed interfaces is not unique to the ferry clip method. The conventional L T M requires direct access to both service boundaries of an IUT. The conventional D T M requires direct access to the upper service boundary of an IUT. With the coordinated test method, some interface is required to connect the UT with the IUT. Hence, all in all, the ferry clip method is no better nor worse than the conventional test methods in its requirement for exposed interfaces. CHAPTER 5. SOME INTERESTING FERRY CLIP BASED ISSUES 66 The choice of the appropriate test method depends to a large extent on which service boundaries of the IUT are accessible. If both service boundaries are exposed, the ferry clip version of the L T M is the preferred approach. If the lower service boundary is exposed, the ferry clip version of the RTM can be used. Similarly, if only the upper service boundary of the IUT is exposed the ferry clip version of the D T M may be used. In the case where several protocol layers are implemented together with no exposed interfaces between the intermediate layers, the Multi-layer version of the ferry clip approach can be used. For higher layer IUTs requiring Multi-party testing (e.g. MHS) the Multi-party variant of the ferry clip method can be used. In everyone of these approaches the ferry clip realization of the conventional test methods have several advantages over their conventional counterparts. 5.5 The Distributed Test Method Logging Problem Recently a serious difficulty was discovered with the requirement to produce a conformance log for the conventional D T M . "It was realized that with the [conventional] D T M it was not possible to avoid placing logging requirements on the SUT. Furthermore, in the [conventional] D T M , the upper boundary may be a human interface, leaving the responsibility for recording the conformance log unclear" [18]. When a FCTS is used to realize the D T M , the UT is placed in the test system. Since both LT and UT reside on the same system, the logging problem does not arise. Logging data exchanges is a simple matter in a FCTS, requiring the T M log any data received from or sent to the AFC FSM via the E / D module. For further details of how logging is performed in a FCTS refer to [23]. Chapter 6 Conclusions This chapter summarizes the work done and draws some conclusions about the ferry clip test approach. Areas of future research are also mentioned. 6.1 Summary of Work Done The ferry clip approach to protocol testing was recently introduced as an attempt to overcome some problems associated with the conventional test methods. The ferry clip method allows both the LT and UT to reside on the test system, thereby reducing the amount of software that must be implemented in the SUT as well as enhancing the synchronization between the LT and UT. A model is provided for structuring a FCTS so as to reduce the amount of work necessary to modify the test software to test different protocol implementations and/or use a different underlying protocol as the FTMP. The model is at a sufficiently high level so that it can be implemented in almost any environment. Three implementations of the FCTS were built in three different environments. The thesis has focused on the implementations in the MPT and OSI-PTE environments. The model for structuring the FCTS was used consistently in all the environments. Interesting design 67 CHAPTER 6. CONCLUSIONS 68 and implementation issues were encountered. The need for a F T M P independent flow control scheme was pointed out and implemented. The nature of the OSI-PTE environment required refining our basic model to split the IUT Interface module into a Lower and Upper IUT Interface. Using the F C T S it was possible to effectively test the X.25 packet layer protocol in the M P T environment and the ISO Transport Class 0 protocol in the OSI-PTE environment. The F C T S proved to be an extremely effective tool for diagnostic testing and was used to correct certain problems in our test implementation of the Transport protocol. A F C T S can be used to realize the abstract L T M , D T M and R T M . Furthermore, it can also be adapted to perform Multi-layer testing. A scheme to perform Extended Multi-layer testing was described. Some high level protocols such as MHS require Multi-party test approaches. A scheme for extending the F C T S to perform Multi-party testing was also presented. The versatility of the ferry clip approach was illustrated by how easily it can be adapted to realize all these different test approaches. Some interesting issues associated with the use of the ferry clip concept were also discussed. We believe that the "ordering" and "time-lag" problems will not cause incorrect operation of the F C T S if care is taken when writing local test scripts for the F C T S . A S N . l can aid in reducing the encoding/decoding effort when the test system and SUT have a different architecture. However, its use requires that an A S N . l compiler be available on both the test system and the S U T . It was also pointed out that the logging problem that affects the conventional D T M will not occur when a F C T S is used to realize the D T M . CHAPTER 6. CONCLUSIONS 69 6.2 Future Research Our implementations have shown that the FCTS is an extremely powerful and effective tool to perform diagnostic testing. Furthermore, the structuring scheme suggested proved to be extremely useful in all the environments in which the FCTS was built. Like any project, however, some interesting areas of research remain and are discussed below. • ISO has recently put emphasis on Multi-party test approaches. Currently, however, little work has been done in the area. The ferry clip approach provides a useful means for performing Multi-party testing and has several advantages over the conventional approach. A FCTS implemented to perform Multi-party testing would not only prove interesting study but also provide some useful and much needed input to ISO. A lot more work needs to be done in designing the T M (LT and UT) to perform Multi-party testing. • The need for using ASN.l in a heterogeneous environment was pointed out. The effort required to use ASN.l is an issue not addressed by this thesis since an ASN.l compiler was not available on our test system. A comparison of the current approach of encod-ing/decoding and that using ASN.l would make an interesting and useful study. • Even though a scheme was provided for implementing a Extended Multi-party test system using a FCTS, no actual implementation was performed. The use of such a system to test a multi-layer IUT would provide an interesting area of study. Bibliography [1] H . X . Zeng and D. Rayner, The impact of the ferry concept on protocol testing, in Diaz , M . (ed.), Protocol Specification, Test ing, and Verification V , p.533-544, North-Hol land, 1986. [2] H . X . Zeng, X . F . D u and C . S. He, Promoting the "Local" Test Method with the New Concept "Ferry Clip", Proceedings of the 8th IFIP Symposium on Protocol Specification, Testing and Verification, At lant ic Ci ty , June 1988. [3] H . X . Zeng. Q . L i , X . F . D u and C . S. He, New Advances in Ferry Testing Approaches, Journal of Computer Networks and I S D N Systems, 15,1 (1988). [4] H . X . Zeng, S. T . Chanson and B. R. Smi th , On Ferry Clip Application in Protocol Testing, to appear in Journal of Computer Networks and ISDN Systems, 1989. [5] W . Stall ings, Data and Computer Communications, Macmi l lan Publishing Company, New Y o r k , 1985. [6] S. Sechrest, An Introductory 4-3BSD Interprocess Communication Tutorial, M T X I N U M a n u a l , 4 .3BSD with N F S , Programmer's Supplementary Documents, Vol -ume 1, P S I , 1986. [7] D . Rayner , The Impact of ISO 9646 on Test System Design, Proceedings of the International Workshop on Protocol Test Systems, Vancouver, Canada , 1988. [8] I S O / T C 9 7 / S C 21 N , 2nd D P 9646, Conformance Testing Methodology and Frame-work, 1987. [9] C C I T T Draft Recommendation X.200, Reference Model of Open System Interconnec-tion for CCITT Applications, 1988. [10] C C I T T Draft Recommendation X.25, Interface Between DTE and DCE Terminals Operating in Packet Mode, 1988. [11] C C I T T Draft Recommendat ion X.213, Network Service Definition for 0SI for CCITT Applications, 1988. 70 BIBLIOGRAPHY 71 C C I T T Draft Recommendat ion X.223, Use of X.25 to Provide OSI Connection-Mode Network Service, 1988. Recommendat ion X.400, Message Handling Systems - Systems Model - Service Ele-ments, D a t a Communicat ions Standards, Ed i t ion III, V o l . 2, 1984. Recommendat ion X.409, Message Handling Systems: Presentation Transfer Syntax and Notation, D a t a Communicat ions Standards, Ed i t ion III, Vo l . 2, 1984. I S O / I E C J T C 1 / S C 2 1 / W G 1 S 31, Working document on Multi-party Test Methods, December 1988. Transport Protocol Specification for Open System Interconnection for CCITT Appli-cations, D a t a Communicat ions Standards, Edi t ion III, V o l . 2, 1984. ISO DIS 8571/1, 2, 3, 4, Information Processing Systems - OSI - File Transfer, Access and Management, I S O / T C 9 7 / S C 21 N1215, N1216, N1217, N1218, July 1986. O . Monkewich, Report on the Meeting of ISO/IEC JTC1/SC21/WG1 Group on Con-formance Project 1.21.23, Sydney, Austral ia, November 1988. G . V . B o c h m a n n and C . S. He, Ferry Approaches to Protocol Testing and Service Interfaces, Proceedings of the 2nd International Symposium on Interoperable Infor-mation Systems, Tokyo , Japan , November 1988. I D A C O M Electronics L t d . , MPT368.2 User Manuals - Forth Programming, November 1987. R. I. C h a n , OSI PT Environment, Version 1.32, U B C - I D A C O M Project Documenta-tion, 21 September 1988. R. I. C h a n et el., A Software Environment for OSI Protocol Testing Systems, Proceed-ings of the 9th EFIP Symposium on Protocol Specification, Test ing and Verification, Enschede, T h e Netherlands, June 1989. B . P. Lee, Portability Issues in Designing a Test System, M .Sc . thesis, Department of Computer Science, University of Brit ish Columbia , 1989. Appendix A Ferry Control Protocol and Ferry P D U s Passive Ferry Clip State Transition Table State Event Action Next State idle FT-CONN ind PI: FT-CONN rsp P2: FT-DISPrp/] connected irllp. FT-DISC ind FT-ERROR ind none FT-DISC req idle FD-DATA req none idle connected FT-DISC ind FT-ERROR ind none FT-DISC req idle FT-DATA ind P3: FT-DATA req (loop back) P4: FD-DATA ind P5: cnnrml Actions connected FD-DATA req P6: FT-DATA req(FY-DATA) P3: none connected Notes: • In any state, the action and transition taken for events not listed in the table are the same as those listed for the FT-ERROR ind event. PI (predicate 1) - the incoming FT-CONN ind is acceptable. P2 - the incoming FT-CONN ind is unacceptable. P3 - the passive ferry clip is in loop-back mode. P4 - received data is FY-DATA PDU and the passive ferry clip is not in loop-back mode. • P5 - received data is FY-CNTL PDU and the passive ferry clip is not in loop-back mode. Per-form appropriate control actions and generate FY-CNTL (using FT-DATA req) back to active ferry. P6- the passive ferry clip is not in loop-back mode. 72 APPENDIX A. FERRY CONTROL PROTOCOL AND FERRY PDUS 73 Active Ferry Clip State Transition Table State Event Action Next State idle FM-CONNreq FM-DISC req FT-CONN req none connecting idle FM-CNTLreq FD-DATA req FM-DISC ind idle FT-DISC ind FT-ERROR ind none FT-DISC req idle connecting FM-DISC req FT-DISC req idle FT-CONN cnf FT-DISCind FT-ERROR ind FM-CONNcnf FM-DISC ind EXCEPTION connected idle idle connected FM-DISC req FT-DISC req idle FM-CNTLreq FD-DATA req FT-DATA req(FY-CNTL) FT-DATA req(FY-DATA) connected FT-DATA ind PI: FD-DATA ind P2: control actions connected FT-DISC ind FT-ERROR ind FM-DISC ind EXCEPTION idle Notes: In any state, the action and transition taken for events not listed in the table are the same as those listed fa- the FT-ERROR ind event, e.g. if an FM-CNTL req is received in the connect-ing state, the EXCEPTION action should be taken and the state should change to idle. • EXCEPTION indicates the dual actions FT-DISC req and FM-DISC ind. • PI (predicate 1) - the FT-DATA received is an FY-DATA PDU. P2 (predicate 2) - the FT-DATA received is an FY-CNTL PDU; action is to process FY-CNTL flag bits and generate FM-CNTL cnf. APPENDIX A. FERRY CONTROL PROTOCOL AND FERRY PDUS 74 F Y - D A T A P D U Format FY-PDU header (3 bytes) t r*- control field (1 byte)—*** 2 bytes -byte stream LI U/L E M length test data T - FY-PDU Type. T = 0 for FY-DATA PDUs. LI - Layer Identifier. LI = 1 7 to correspond to OSI layers 1 through 7. U/L - Upper/Lower Interface Bit. 0 => test data to/bom lower service interface of IUT. 1 => test data to/from upper service interface of IUT. * - Reserved. M - More. 0=> test data is not segmented or is last of a series of segments. 1 => at least one segment follows this one. length- number of bytes of test data within the FY-DATA PDU. F Y - C N T L P D U Format FY-PDU hei r*— control field (1 byte) —*• ider (3 bytes) *H m extra control field „ i (2 bytes) i T L 1 1 1 1 1 * i * T - FY-PDU Type. T = 1 for FY-CNTL PDUs. L - Loop-Back Bit. 0 => set passive ferry into normal (non loop-back) mode. 1 => set passive ferry into loop-back mode. • n — —— -i — Keservea. Appendix B Passive Ferry Clip Lower Mapping Modules "Forth" Source Code for Lower Mapping Module in M P T Environment (  ( F i l e T i t l e ( Document I d ( P r o j e c t I d ( Date ( System ( V e r s i o n ( A u t h o r ( F . C S T A T E S . F P a s s i v e F e r r y C l i p Component F e r r y C l i p August 16, 1988 PT 3 .2 / MPT 1.2 1.0 N e v i l l e J . P a r a k h ( T h i s f i l e c o n t a i n s r o u t i n e s t h a t implement t h e s t a t e s f o r the ( r e c e i p t o f COMMANDS f r o m t h e " P a s s i v e F e r r y FSM" ( R o u t i n e c a l l e d when an INVALID COMMAND i s r e c e i v e d ) : INVALID.COMMAND ( STATE — ) CR . " C S T A T E " . . " : INVALID COMMAND RECEIVED" CR ( Send t h e DATA PACKET t o t h e ACTIVE FERRY ) : SEND.BP2 ( — SUCCESS I FAILURE ) BUFFER-P00L2 REMOVE.FROM.QUEUE SUCCESS = IF 75 APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES DUP 1+ DUP CO 256 * 3 » # 3+ LOCAL-BUFFER C! LOCAL-BUFFER 1+ LOCAL-BUFFER C® CMOVE LOCAL-BUFFER SENDD SUCCESS ELSE FAILURE THEN SWAP 1+ CO + ( FY-DATA PDU LENGTH ) ( NUMBER OF BYTES ) ( STORE LENGTH IN FIRST BYTE OF STRING ) ( DESTINATION FOR CMOVE ) ( LENGTH FOR CMOVE ) ( SEND DATA FRAGMENT TO ACTIVE FERRY ) ( DATA GOT SENT ) ( NO DATA TO SEND ) ( Send the CONTROL PACKET to the ACTIVE.FERRY ) : SEND.BP3 ( — SUCCESS I FAILURE ) BUFFER-P00L3 REMOVE_FROM_QUEUE SUCCESS = IF 3 LOCAL-BUFFER C! LOCAL-BUFFER 1+ 3 CMOVE LOCAL-BUFFER SENDD SUCCESS ELSE FAILURE THEN ( STORE LENGTH IN FIRST BYTE OF STRING ) ( DESTINATION FOR CMOVE ) ( LENGTH FOR CMOVE ) ( SEND DATA FRAGMENT TO ACTIVE FERRY ) ( CONTROL PACKET WAS SENT ) ( NO CONTROL PACKET TO SEND ) ( C State 0 - Diconnected s ta te , waiting f o r X.25 to send a ) ( CALL-CONNECTED packet ) : CSTATEO ( COMMAND — ) DOCASE CASE FT-CONNresp { ( RETURN FT-DISCind ) FT-DISCind ADD_TO_LMAP_RETURN } CASE FT-DATAreq { ( RETURN FT-ERRORind ) APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES FT-ERRORind ADD_TO_LMAP_RETURN > CASE FT-DISCreq { } ( IGNORE SINCE ALREADY DISCONNECTED ) CASE DUP { ( INVALID COMMAND ) 0 INVALID.COMMAND } ENDCASE ( C State 1 - Transmitted DISC, waiting f o r a response ) : CSTATE1 ( COMMAND — ) DOCASE CASE FT-CONNresp { FT-DISCind ADD_TO_LMAP_RETURN ( RETURN FT-DISCind ) > CASE FT-DATAreq { FT-ERRORind ADD_TO_LMAP_RETURN ( RETURN FT-ERRORind ) } CASE FT-DISCreq { } ( IGNORE SINCE ALREADY DISCONNECTED ) CASE DUP { 1 INVALID.COMMAND } ( INVALID COMMAND RECEIVED ) ENDCASE ( C State 2 - Connected state , waiting f o r data from "Active Ferry" ) : CSTATE2 ( COMMAND — ) DOCASE CASE FT-CONNresp { } CASE FT-DISCreq { DISC 1 LSTATE ! } CASE FT-DATAreq { WINDOW? 1 = IF SEND.BP3 SUCCESS = IF FT-DATAsent DATA-RESULT ! ELSE SEND.BP2 ( IGNORE FT-CONNresp ) ( TRANSMIT DISC FRAME ) ( MOVE TO STATE 1 ) ( CAN DATA BE SENT ? ) ( YES IT CAN ) APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES SUCCESS = IF FT-DATAsent DATA-RESULT ! ELSE " PASSIVE FERRY: OUTPUT BUFFERS EMPTY" OQ.EMPTY FT-DATAnotsent DATA-RESULT ! THEN THEN ELSE ( NO DATA CANNOT BE SENT ) FT-DATAnotsent DATA-RESULT ! THEN > CASE DUP { 2 INVALID.COMMAND > ( INVALID COMMAND RECEIVED ) ENDCASE APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES 79 F i l e T i t l e : F.FPSTATES.F Document Id : Passive Ferry C l i p Component Project Id : Ferry C l i p Date : August 15, 1988 System : PT 3.2 / MPT 1.2 Version : 1.0 Author : N e v i l l e J . Parakh ( This f i l e contains routines that implement the states f o r the ( receipt of FRAMES and PACKETS by the "Lower Mapping Module" ( Routine that i s c a l l e d i f a request i s made to remove an ( element from an EMPTY OUTPUT QUEUE : OQ.EMPTY ( STRING — ) CR COUNT TYPE CR ( Routine that i s c a l l e d i f the LMAP-RETURN queue i s f u l l ) : LMAP.RETURN.FULL ( STRING — ) CR COUNT TYPE CR ( Routine to add a message to the LMAP-RETURN queue ) : ADD_TO.LMAP_RETURN ( VALUE — ) LMAP-RETURN ADD_TO_QUEUE SUCCESS = IF ( SPACE AVAILABLE ) ! ( STORE MESSAGE IN QUEUE ) ELSE ( NO SPACE AVAILABLE ) DROP ( DROP VALUE FROM STACK ) " LMAP RETURN QUEUE FULL" LMAP.RETURN.FULL THEN » ( Frame/Packet State Routines handle incoming Frames and ) ( Packets ) ( FP State 0 - Diconnected s tate , waiting f o r our X.25 to send a ) ( CALL-CONNECTED packet ) APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES : FPSTATEO ( ~ ) FRAME-TYPE 0 ( FRAME TYPE ) R*I = ( I-FRAME ? ) IF PACKET-TYPE 0 ( PACKET TYPE ) DOCASE CASE R*CALLREQ { DOER.INITIALIZE.FERRY 0 PAINT CLEAR.TEXT " PASSIVE FERRY CONNECTED" BTYPE WCR FT-CONNind ADD_TO_LMAP_RETURN ( RETURN FT-CONNind ) 2 LSTATE ! ( MOVE TO STATE 2 ) } CASE DUP { > ( IGNORE ALL OTHER PACKETS ) ENDCASE THEN ( IGNORE ALL FRAMES ) ( FP State 1 - Transmitted DISC - waiting f o r a response ) : FPSTATE1 ( — ) FRAME-TYPE <8 ( FRAME TYPE ) R*I = ( I-FRAME ? ) IF PACKET-TYPE 0 ( PACKET TYPE ) DOCASE CASE R+RESTARTREQ { FT-DISCind ADD_TO_LMAP_RETURN ( RETURN FT-DISCind ) 0 LSTATE ! ( MOVE TO STATE 0 ) } CASE DUP { } ( IGNORE ANY OTHER PACKETS ) ENDCASE ELSE FRAME-TYPE <3 DOCASE CASE R*DISC ORCASE R*DM ORCASE R*UA { 0 LSTATE ! ( MOVE TO STATE 0 ) } CASE DUP { } ( IGNORE ANY OTHER FRAMES ) APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES ENDCASE THEN ( FP State 2 - Connected s tate , waiting f o r data from "Active Ferry" ) : FPSTATE2 ( — ) ( FRAME TYPE ) ( I-FRAME ? ) FRAME-TYPE G R*I = IF PACKET-TYPE « DOCASE CASE 0 CASE R*RRP CASE R*RNRP CASE R*DATAP ( PACKET TYPE ) •C } ( IGNORE NULL PACKET ) { } (IGNORE RR PACKET ) { } ( IGNORE RNR PACKET ) •C FT-DATAind ADD_TO_LMAP_RETURN ( RETURN FT-DATAind ) DATA-POINTER 0 ( X.25 DATA BUFFER ) INPUT-BUFFER ( INPUT BUFFER ) DATA-LENGTH ffl ( LENGTH OF FY-PDU ) CMOVE ( MOVE DATA FROM X.25 BUFFER INTO INPUT BUFFER ) } CASE R*RESTARTREQ { FT-DISCind ADD_TO_LMAP_RETURN ( RETURN FT-DISCind ) 0 LSTATE ! ( MOVE TO STATE 0 ) } CASE R*CLEARREQ { FT-DISCind ADD_TO_LMAP_RETURN ( RETURN FT-DISCind ) 0 LSTATE ! ( MOVE TO STATE 0 ) } CASE DUP { FT-ERRORind ADD_TO_LMAP_RETURN ( RETURN FT-ERRORind ) " PASSIVE FERRY GETS UNDEFINED EVENT = " RTYPE PACKET-TYPE Q W. WCR > ENDCASE ELSE FRAME-TYPE <8 DOCASE CASE R*DISC ORCASE R*DM { FT-DISCind ADD_TO_LMAP_RETURN ( RETURN APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES FT-DISCind ) 0 LSTATE ! ( MOVE TO STATE 0 ) PASSIVE FERRY GOT DISC FROM ACTIVE" YTYPE WCR } CASE DUP { } ( IGNORE ANY OTHER FRAMES ) ENDCASE THEN APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES 83 " C " Source Code for Lower Mapping Module in O S I - P T E Environment /************************************* **************************/ /* */ / * PROGRAM: Passive Ferry C l i p . * / / * MODULE: Lower Mapping Module routines to use X.25 PLP * / /* */ / * AUTHOR: N e v i l l e J . Parakh * / / * DATE: January 12, 1989 * / /* */ / * DESCRIPTION: * / / * This module contains two main routines : * / / * (1) LMAPUp: * / / * This i s the routine c a l l e d as the r e s u l t of an * / / * incoming event from the FTMP. I t i s wri t ten as a * / / * s tate machine. Furthermore, i t i s dependent on the * / / * FTMP being used. A l l references to the FTMP being * / / * used are l o c a l i z e d i n t h i s module. * / / * (2) LMAPDown: * / / * This i s the routine c a l l e d to send a FY- packet to * / / * the Act ive Ferry v i a the FTMP on the Passive Ferry * / / * s i d e . I t i s c a l l e d as a procedure from routines i n * / / * the Passive Ferry FSM Module. * / /* */ / * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * « * * * * * * * * * * * * * * * * * * / #include <stdio.h> #include "n_header.h" #include " p a s s i v e / e r r o r . h " #include "passive/param.h" #include "pass ive /events .h" #include " p a s s i v e / f s m / f r _ n v a . h " #include " p a s s i v e / f s m / f r _ c c b . h " #include " p a s s i v e / f s m / f r _ s t a t e s . h " #include " p a s s i v e / f s m / f r _ a s p . h " # include "pass i v e / f sm/decode.h" / * Variables to hold the Network address f o r the Passive and Active FTMPs - assigned i n LMAPUp when we get a N_CONN_REQ_EID * / s t a t i c N_ADDR passive_ftmp.addr; APPENDIX B. PASSIVE FERRY CLE? LOWER MAPPLNG MODULES s t a t i c N_ADDR active_ftmp.addr; s t a t i c N_QOS qos; void LMAPUp(frn,cid,eid,epa) s t ruc t f r . n v a * f r n ; CID * c i d ; EID e i d ; EPA *epa; •C i n t fr_decode() ; void PassiveFSMO ; void ERRORO; s t ruct f r . c c b *ptr_ccb; s t ruct N_CONN_IND_EPA *ptr_conn_ind; s t ruct N.DATA.IND.EPA * p t r _ d a t a . i n d ; s t ruct N_EXPD_IND_EPA *ptr_expd_ind; s t ruct N_DISC_IND_EPA * p t r _ d i s c _ i n d ; FerryPDU token; extern N_ADDR passive .f tmp.addr ; extern N.ADDR active_ftmp_addr; extern N_Q0S qos; switch(eid) •C case N_CONN_IND_EID: ptr_conn_ind = (s truct N_CONN_IND_EPA *)epa; passive_ftmp_addr = ptr_conn_ind->dst_naddr; active_ftmp_addr = ptr_conn_ind->src_naddr; qos = ptr_conn_ind->nqos; i f (ptr_conn_ind->nsdu != RXBUF.NULL) FreeRxBuf(ptr_conn_ind->nsdu); / * C a l l Passive Ferry FSM * / PassiveFSM(FT_CONNind,frn->ccb,(FerryPDU *)NULL, TX_NULL,RXBUF_NULL); break; case N_DATA.IND.EID: p t r . d a t a . i n d = (s truct N_DATA.IND.EPA *)epa; bzero(&token,sizeof(token)) ; fr_decode(&token,(b8)0,ptr_data_ind->nsdu,(b8)0); APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES / * Decode the header byte * / i f ( t o k e n . t . b i t == (b8)0) { / * Decode FY-PDU header byte * / t o k e n . l i . b i t s = (token.header ft 0x70) >> 4; t o k e n . u l . b i t = (token.header ft 0x08) » 3; token.reservedl = (token.header ft 0x06) >> 1; token.m_bit = token.header ft 0x01; TruncateRxHead(ptr_data_ind->nsdu,token.data); PassiveFSM(FT_DATAind,frn->ccb,fttoken,TX.NULL, ptr_data_ind->nsdu); } else { / * Decode the FY-CNTL PDU * / t o k e n . l _ b i t = (token.header ft 0x40) » 6; token.reserved2 = token.header ft 0x3f; TruncateRxHead(ptr_data_ind->nsdu,token.data); PassiveFSM(FT_DATAind,frn->ccb,fttoken,TX.NULL, ptr_data_ind->nsdu); > break; case N_DACK_IND_EID: PassiveFSM(FT_ERRORind,frn->ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); break; case N_EXPD_IND_EID: ptr_expd_ind = (struct N_EXPD_IND_EPA *)epa; i f (ptr_expd_ind->nsdu != RXBUF.NULL) FreeRxBuf(ptr_conn_ind->nsdu); PassiveFSM(FT_ERRORind,frn->ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); break; case N_RSET.IND.EID: p t r . c c b = frn->ccb; PostEvent(ptr_ccb->nid2,ft(ptr_ccb->cid2).N.SERVICE.DN, (EID)N_RSET_RSP_EID,(EPA *)NULL); i f (frn->state == CONNECTED) PassiveFSM(FT_ERRORind,ptr.ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES break; case N_RSET_CFM_EID: p t r . c c b = frn->ccb; i f (frn->state == CONNECTED) PassiveFSM(FT.ERRORind,ptr.ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); break; case N.DISC.IND.EID: p t r . d i s c . i n d = (struct N.DISC.IND.EPA *)epa; / * i f (ptr_disc_ind->nsdu != RXBUF.NULL) FreeRxBuf(ptr.conn.ind->nsdu); * / PassiveFSM(FT_DISCind,frn->ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); break; d e f a u l t : ERROR(INVALID_ASPl,(void *)NULL); PassiveFSM(FT_ERRORind,frn->ccb,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); > } void LMAPDown(frc , fr .asp.ptr . txbuf) s t ruct f r . c c b * f r c ; i n t f r . a s p ; TXBUF *ptr_ txbuf ; •C void ERRORO ; void PassiveFSMO ; s t ruct N_CONN.RSP.EPA n.conn.rsp .epa ; s t ruct N.DISC.REQ.EPA n . d i s c . r e q . e p a ; s t ruct N_DATA.REQ.EPA n_data.req.epa; extern N.QOS qos; switch(f r .asp) { case FT.CONNrsp: n . conn. rsp .epa . rsp .naddr = passive.f tmp.addr ; APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES n_conn_rsp_epa. modified = FALSE; n_conn_rsp_epa.modification.reason = (OCTET)0; n_conn_rsp_epa.rcpt = FALSE; n_conn_rsp_epa.expd = FALSE; n_conn_rsp_epa.nqos = qos; n_conn_rsp_epa.extra = (N_EXTRA)0; n_conn_rsp_epa.nsdu = TX_NULL; PostEvent(frc->nid2,&(frc->cid2),N_SERVICE_DN, (EID)N_C0NN_RSP_EID,&n_conn_rsp_epa); break; case FT_DISCreq: n_disc_req_epa.rsp_naddr = passive_ftmp_addr; n_disc_req_epa.modified = FALSE; n_disc_req_epa.modification_reason = (OCTET)0; n_disc_req_epa.nreason = N_DISCONNECT_UNDEFINED; n_disc_req_epa.cause = (OCTET)0; n_disc_req_epa.diagnostic = (OCTET)O; n_disc_req_epa.nsdu = TX_NULL; PostEvent(frc->nid2,&(frc->cid2),N_SERVICE_DN, (EID)N_DISC_REQ_EID,4n_disc_req_epa); break; case FT.DATAreq: n_data_req_epa.nsdu = p t r . t x b u f ; n_data_req_epa.creq = FALSE; n_data_req_epa.qbit = FALSE; n_data_req_epa.mbit = FALSE; PostEvent(frc->nid2,&(frc->cid2),N_SERVICE_DN, (EID)N_DATA_REq_EID,&n_data_req_epa); break; case FDL.CONNind: PostEvent(frc->nid3,&(frc->cid3),L0WER_IUT_SERVICE_UP, (EID)L0WER_IUT_C0NN_IND,(EPA *)NULL); break; case FDL.DISCind: PostEvent(frc->nid3,&(frc->cid3),LOWER_IUT_SERVICE_UP, (EID)LOWER_IUT_DISC_IND,(EPA *)NULL); break; APPENDIX B. PASSIVE FERRY CLIP LOWER MAPPING MODULES 88 case FDU.CONNind: PostEvent(frc->nid4,&(frc->cid4),UPPER_IUT_SERVICE_DN, (EID)UPPER_IUT_CONN_IND,(EPA *)NULL); break; case FDU_DISCind: PostEvent(frc->nid4,&(frc->cid4),UPPER_IUT_SERVICE_DN, (EID)UPPER_IUT_DISC_IND,(EPA *)NULL); break; / * I n v a l i d ASP's * / / * case FT.CONNind: * / / * case FT.DISCind: * / / * case FT.DATAind: * / / * case FT.ERRORind: * / / * case FD.DATAreq: * / / * case FD.DATAind: * / defaul t : ERROR(INVALID_ASP2,(void *)NULL); PassiveFSM(FT_ERRORind,frc,(FerryPDU *)NULL, TX.NULL,RXBUF.NULL); } } 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051913/manifest

Comment

Related Items