UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Open systems interconnection passive monitor OSI-PM Lo, Jeffrey Kin Hung 1990

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

Item Metadata

Download

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

Full Text

O P E N SYSTEMS I N T E R C O N N E C T I O N PASSIVE  MONITOR  OSI-PM By Jeffrey Lo (Kin Hung) Bachelor Of Computer Science (BCS), Carleton University, 1988  A THESIS 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 REQUIREMENTS FOR T H E D E G R E E OF M A S T E R O F SCIENCE in T H E F A C U L T Y O F G R A D U A T E STUDIES ( D E P A R T M E N T O F C O M P U T E R SCIENCE)  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 BRITISH C O L U M B I A August 1990 © Jeffrey Lo (Kin Hung), 1990  In  presenting  degree freely  at  this  the  available  copying  of  department publication  of  in  partial  fulfilment  University  of  British  Columbia,  for  this or  thesis  reference  thesis by  this  for  his thesis  and  scholarly  or for  her  Department The University of British Columbia Vancouver, Canada  (2/88)  I  I  further  purposes  gain  the  shall  requirements  agree  that  agree  may  representatives.  financial  permission.  DE-6  study.  of  be  It not  that  the  be  Library  an  by  understood allowed  the  advanced  shall  permission for  granted  is  for  make  extensive  head  that  without  it  of  copying my  my or  written  Abstract The Open Systems Interconnection Passive Monitor (OSI-PM), which is based on the principles of the OS I-Reference Model (OSI-RM), provides a framework for the development of multi-layer passive monitoring and testing. It adopts the same seven-layer architecture of the OSI-RM and provides the capability of selectively displaying, capturing, and analyzing the protocol events on single or multiple connections for any subset or all of the seven layers. Different from conventional monitors, the OSI-PM is able to detect protocol violation as they occur in addition to the monitoring functions.  The  current OSI-PM is able to monitor and test up to the transport layer of the OSI-RM. This thesis discusses the design, prototype implementation and testing of the OSI-PM.  11  Contents Abstract  ii  Contents  iii  List of Figures  v  Abbreviations  v  Acknowledgement 1  vii  Introduction  1  1.1 1.2  2 3 3 4 5 6  1.3 1.4  A brief introduction to the OSI-RM Related Work 1.2.1 MPT386.2 X.25 monitor 1.2.2 Trace Analysis Goals of the Thesis Outline of the Thesis  2 Architecture 2.1 Data Extraction Module (DEM) 2.2 Data Storage Module 2.3 Monitor Module ( M M ) 2.3.1 Synchronization 2.3.2 Protocol Stack Submodule (PSS) 2.3.3 Data Processing Submodule (DPS)  7 9 9 10 12 13 14  3 Implementation 3.1 The environment 3.1.1 The Synchronous Serial Driver 3.2 Data Extraction Module  18 18 19 20  iii  3.3 3.4  4  Data Storage Module Monitor Module (MM) 3.4.1 Data Processing Submodule 3.4.2 Protocol Stack Submodule  Testing of the O S I - P M 4.1 MPT386.2 X.25 Monitoring 4.2 Report Generation 4.2.1 Report of Error 4.3 Report of Sample Traces 4.3.1 Report #1 4.3.2 Report #2 4.3.3 Report #3 4.3.4 Report #4 4.4 Error Report 4.4.1 Error Report #1 4.4.2 Error Report #2 4.4.3  21 21 21 24 29 29 33 34 35 35 41 42 43 45 45 46  Error Report #3  48  5  Conclusion and Future Work  50  A  User Manual  55  B  Software and Hardware Configuration B . l Software Configuration B.2 Hardware Configuration  59 59 60  C  Guide for adding a new entity  63  iv  List of Figures 1.1  Test architecture with arbiter  4  2.1  OSI-PM  7  2.2  Structure of the Monitor Module  11  3.1  Format of Packed Data  20  4.1 4.2 4.3 4.4 B.l  Connecting the D T E , the D C E and the OSI-PM Connecting the D T E , the D C E and the MPT386.2 Throughput of ean line, Thur., July 27, 1989 Report Format Configuration of the Cables  30 31 32 33 61  v  Abbreviations ASP  Abstract Service Primitive  CPU  Central Processing Unit  DCE  Data Circuit-Terminating Equipment  DPS  Data Processing Submodule  DEM  Data Extraction Module  DSM  Data Storage Module  DTE  Data Terminal Equipment  FSM  Finite State Machine  ISO  International Standards Organization  IUT  Implementation Under Test  MM  Monitor Module  MPT  Multi-port Protocol Tester  OSI-PM  Open Systems Interconnection Passive Monitor  OSI-RM  Open Systems Interconnection Reference Model  PDU  Protocol Data Unit  PSS  Protocol Stack Submodule  SAP  Service access point  VI  Acknowledgement I sincerely thank Dr. Samuel T . Chanson, my thesis supervisor, for his invaluable guidance, commitment and supportiveness. Thanks also go to Dr. Son Vuong who acts as the second reader of my thesis. Thanks to my friends Bernard P. Lee and M . Lau for the many discussions on this work and all the help they gave me. Thanks to all of my friends in the department. Last but not the least, my deepest thanks go to my parents for their endless help, support and love without which none of this would have been possible.  vn  Chapter 1 Introduction The Open Systems Interconnection Passive Monitor (OSI-PM), which is based on the principles of the OSI-Reference Model (OSI-RM), provides a framework for the development of multi-layer passive monitoring and testing. The term passive means the monitor is capable of performing its functions without interfering with the normal operations of the communicating entities.  The OSI-PM adopts the same seven-layer architecture of  the OSI-RM representing the seven protocol layers from the Physical layer up to the Application layer. It provides the capability of selectively displaying, capturing, and analyzing the protocol events on single or multiple connections for all of the seven layers or any subset. Protocol events include decoded PDUs, internal state changes, protocol violations and timeouts. The major differences of the OSI-PM from conventional monitors are its ability to detect protocol violation as they occur (passive testing) and the modular design that allows easy extension to multi-layer monitoring and testing. The monitor is especially useful in capturing errors which tend to occur from time to time, and monitoring the behavior of two implementations which have been tested separately and have just been put into use. It should be pointed out, however, that unlike active testing, passive testing is unable (nor is it meant) to conclusively determine if a protocol  1  CHAPTER 1.  INTRODUCTION  2  implementation conforms to the specifications it purports to adhere. This thesis discusses the design of the O S T P M and describes a prototype implementation. In the following sections, we present an overview of the O S T R M , related work and goals of the research. A layout of the rest of the thesis is also given.  1.1  A brief introduction to the OSI-RM  The seven-layer OSI Reference Model developed by the International Standards Organization (ISO) provides a framework for the production of standards for communication and distributed data-processing systems [1], The idea of layering is that the communications functions are partitioned into a vertical set of layers. Each layer performs a related subset of the functions required to communicate with another system. A lower layer performs more primitive functions and provides services to the next higher layer. Layers are independent with each others so that changes in one layer do not disrupt the other layers. Each layer is known as the n  th  n— I  th  and n + I  th  layer, the layers below and above being known as the  layers respectively. The active elements in each layer are called entities.  Two entities communicate with each other through service access points (SAPs). Each entity will only communicate with the entities directly above and below it. The lower layer of two adjacent layers is called the service provider and the upper layer is called the service user. In other words, if the n  th  layer is the service provider, the n + l  tk  layer  is the service user. The service user uses the service provided by its service provider. Services are specified by a set of abstract service primitives (ASPs) available to a user or other entity to access the service. There are four classes of (ASPs) defined in the OSI-RM: request, indication, response and confirm.  CHAPTER 1.  INTRODUCTION  3  The rules and conventions used for the conversation between layer n on two different machines, i.e. conversation between two peer entities, are collectively known as the layer n protocol. In reality, data are not directly transferred from layer n on one machine to layer n on another machine. Each layer passes the data to the layer immediately below it, until the lowest layer is reached. The lowest layer, known as the physical layer in the OSI-RM is actually a physical medium through which actual communication occurs. Data exchanged between two layer n entities using a layer n protocol is called Protocol Data Units (PDU). PDUs contain either data or control information necessary for the conversation.  1.2 1.2.1  Related Work M P T 3 8 6 . 2 X.25 monitor  The Multi-port Protocol Tester (MPT386.2) manufactured by I D A C O M Electronics, is a new generation of portable protocol tester.  It includes most of the capabilities of  dedicated protocol test systems and all of the capabilities of commercial portable testers [6]. It has a built-in Forth interpreter by which most of its applications are implemented. The X.25 monitor [5] is written in Forth and is one of the applications that runs on the MPT386.2. It is able to capture and display the decoded X.25 packets from the physical interface between the D T E  1  and the D C E . This information may be printed 2  on a display screen, stored in a capture ram, or recorded on disk. Its trigger and filter functions allow the user to select desired events to report, capture and record. The data transmission throughput between the D C E and the D T E can also be measured. 1  2  the terminal or computer is officially called a DTE (Data Terminal Equipment) the modem is officially called a DCE (Data Circuit-Terminating Equipment  CHAPTER 1.  INTRODUCTION  4  user 1 Arbiter Protocol  analysis module  entity 1  analysis module  Underlying communication service  Figure 1.1: Test architecture with arbiter The main advantage of the X.25 monitor is its portability. However, it is restricted to packet layer monitoring only and it is not easily expandable. It is also not able to perform passive testing.  1.2.2  Trace Analysis  There are two major concerns in conformance testing:  test sequence generation and  trace analysis [7]. The test systems which correspond to these are the test engine and the arbiter (sometimes called observer or trace analyzer) respectively. The test engine is responsible for determining and sending the test sequence to the IUT (Implementation Under Test), and the arbiter is responsible for checking whether the trace conforms to the protocol specification. Test sequence generation is an active test method whereas trace analysis is a passive  CHAPTER 1.  INTRODUCTION  5  test method. A n arbiter for testing between two OSI Transport Protocol implementations is developed in [7] as shown in Figure 1.1. The arbiter observes the PDUs exchanged between two protocol implementations and detects any inconsistency caused by the IUT(s) not conforming to the protocol specification.  The arbiter contains two trace analysis  modules, one for each observed IUT. The observed trace of PDUs received from the different IUTs is recorded in a trace file for later processing. The reference specification of the two trace analysis modules is the same as that for a lower tester in the distributed test architecture. Only the properties visible at the lower interfaces of the IUTs can be checked by the arbiter. Many protocol properties, such as the correct transfer of user data cannot be checked [7]. The arbiter was first specified in Estelle.  After this specification was sufficiently  completed, it was translated into Pascal and combined with run-time support routines. These routines include an interface to the underlying Network service (provided by an X.25 network) and functions for operator control and copying the trace onto a file.  1.3  Goals of the Thesis  The goal of this thesis is to design and implement an OSI multiple layer passive monitor. The monitor is to include most of the capabilities found in the MPT386.2 X.25 monitor and it is to be expandable up to the application layer. Its architecture should be as close to the architecture of the OSI-RM as possible. It is also to be a seven layer passive tester and each layer is responsible for testing the corresponding layer in the OSI-RM. Like the OSI-RM, layers are independent with each other so that changes in one layer do not require change in the other layers. The monitor is designed to monitor the conversation between the D C E and the D T E  CHAPTER 1.  INTRODUCTION  6  in real time. The D C E and the D T E will not wait for the monitor to finish processing one P D U before sending the next one; in fact, they are unaware of the existence of the monitor. Therefore, the monitor should be fast enough to catch all interactions between the two terminals without missing any of the packets exchanged. The design should allow protocol layer(s) to be selected for displaying and testing. Only those desired information will be captured and displayed. Each layer contains a decoder and one (or more) finite state machine(s) (FSM) . Testing in each layer can be 3  done by driving the decoded P D U through the FSM(s) of that layer.  1.4  Outline of the Thesis  Following the introduction, Chapter 2 describes the detailed design and architecture of the monitor. Descriptions of the prototype implementation are contained in chapter 3. Chapter 4 discusses the results of using the monitor to monitor a life communication line. Chapter 5 concludes the thesis and outlines some future work.  For protocols that contain sublayers or more than one class (such as X.400 and ISO Transport), more than one FSM will be needed. 3  Chapter 2 Architecture The OSI-PM, as shown in Figure 2.1, contains three modules: Data Extraction Module (DEM), Data Storage Module (DSM) and Monitor Module (MM). The D E M extracts data from the physical interface between the D T E and D C E by using a Synchronous Serial (ZSS) interface. Data are sent by the D E M to the D S M for temporary storage until the M M is ready to process it. The amount of code of the D E M and D S M is much smaller Physical Communication Line  S  OSI-PM  DEM  DSM  Figure 2.1: O S I - P M  7  MM  CHAPTER 2.  ARCHITECTURE  8  than that of the M M , since the functions of the D E M and D S M are simple though the processing overhead is high. The three modules are actually implemented on three different machines so that they can run concurrently in a pipeline fashion to increase packet processing speed. The whole system was originally implemented on one single machine and it contained only the D E M and M M . The two modules ran in pseudo parallelism as two interleaved concurrent processes. Data extracted by the D E M from the communication line were stored in a buffer and processed by the M M directly from that buffer.  However, the  system was too slow and could not keep up with a line rate of 4800 b/s of a X.25 line . 1  The M M took most of the C P U cycles so that the ZSS driver could not keep up. This caused some of the X.25 packets to be missed and the testing could not be done correctly. Therefore, the design was changed to build the two modules on two different machines, and they communicated with each other via an Ethernet socket. The speed of the monitor increased and it could handle throughput at a rate between 4800 and 9600 b/s. However, it was still not fast enough for a standard 9600 b/s line. The D E M was found to be the bottleneck since the ZSS driver performs a lot of i/o and interrupt operations and thus requires much C P U processing. The design was changed again by introducing a new D S M which is implemented on a third machine. The D E M is only responsible for extracting data and sending them to the D S M . As a result, the final version of the monitor is capable of handling more than 19200 b/s throughput rate. The following sections describe the detailed design of each of the three modules.  *Dataflowingthrough the X.25 line consist not only of X.25 packets but also the higher level PDUs, since the higher level protocol PDUs are embedded in the X.25 packets  CHAPTER  2.1  2.  ARCHITECTURE  9  Data Extraction Module (DEM)  The current D E M and the ZSS driver are both developed on a Sun-3/50 workstation. The main function of the D E M is to catch all data flowing along the communication line without missing any of them. Since the driver and the module are running on the same machine, the D E M should be as efficient as possible in order to allow more C P U cycles for the ZSS driver. The original version of the D E M contained code only for reading data from the driver and sending it to the DSM. Measurement data show that the read and send system calls are quite expensive. In order to minimize the number of these calls, several data frames are packed into a buffer to form a larger data unit before being sent to the D S M . The whole buffer is sent when it is full, and the D E M starts to fill the buffer again. The number of frames to be packed in a buffer is determined by the size of each individual frame. The frame size of the line being tested varies from 2 bytes (flow control frame) to 256 bytes (information frame). All frames from the line and their lengths are stored in the buffer. The buffer size should be made as large as possible so that more frames can be sent by one call. Since Unix running on an Ethernet is not able to transmit data larger than 2 K bytes, a buffer size of 2 K bytes is chosen.  2.2  Data Storage Module  A requirement of a passive monitor is to catch all data passing through the communication line and not miss one single packet. Since the M M is the most processing intensive part of the system, a storage module is needed for temporarily storing data when the monitor is too busy. This module is implemented on a Sun-S parestation and is connected to the DSM and M M via Ethernet sockets.  CHAPTER  2.  ARCHITECTURE  10  The D S M is structured as a circular buffer with data units of 2K bytes each. Data from the D E M are copied directly into a data unit of the buffer without making any modification. The total buffer size should be chosen to ensure that it will not overflow even at peak load. From our measurement results, the buffer is almost always empty since the M M is typically faster than the rate of data extraction. Currently, the buffer consists of 100 data units but a much smaller circular buffer would be sufficient. There are four different message types from the M M to the D S M concerning the current state of the monitor:  1. Ready state: the M M is ready to process the next data unit and the D S M may send data to it. 2. Stopped state: the monitor is stopped by the user and therefore all data from the D E M should be discarded. 3. Restart state: the monitor is back to its normal working condition after being stopped. The D S M should start buffering data again. 4. Shut down state: the monitor is shut down and the D S M should also be shut down. Note that the D S M will send data to the M M only if a ready message is sent by the M M , thus there is no need to have a MM_not_ready message.  2.3  Monitor Module (MM)  The D E M and D S M described previously are responsible for data extraction and storage, but the actual processing of the packets takes place in the M M . The M M is connected to the D S M and sends a ready signal to the D S M when it is ready to process  CHAPTER  2.  ARCHITECTURE  11  Monitor Module PSS Application Entit  *• Presentation Entity  D a t a from  Session Entity  theJDSM  DPS *"  Transport Entitj  Network Entity  *• Data Link Entity  Figure 2.2: Structure of the Monitor Module  CHAPTER 2.  ARCHITECTURE  12  the next data unit. The MM consists of two submodules: data processing submodule (DPS) and protocol stack submodule (PSS) (see figure 2.2). The following subsections describe the two submodules and how the monitor synchronizes its state with the two terminals (the D T E and the DCE).  2.3.1  Synchronization  The monitor passively monitors and tests the two data terminals, and the initial internal states of the two terminals are not known to the monitor at the start of a session. Therefore, it is necessary to synchronize the monitor with the current states of the two terminals to start the analysis. There are two ways to do this. The first way is to wait for a restart request packet from the D T E or a restart indication packet from the DCE. When the two terminals are doing a restart procedure, they will be reset to their ready state (Pl), and the state of the monitor can also be set to the ready state. The second method is to wait until all current calls or connections to be completed and the states of the two terminals return to their ready state. The monitor waits until there are no data flowing between the two terminals for a short period of time, and assumes that all current calls are completed. Our measurement data show that for the X.25 line being tested by the current OSI-PM, the longest idle time between two packets within one call is around 10 to 12 seconds. If the waiting time is longer than 12 seconds, the synchronization procedure should be completed correctly. However, the waiting time should be as short as possible, and finally 15 seconds is chosen based on experimental results. This wait time can be changed by the user (see section 2.2.2.4).  CHAPTER 2.  2.3.2  ARCHITECTURE  13  Protocol Stack Submodule (PSS)  The Protocol Stack submodule is constructed as a seven-layer protocol stack. The name of each layer inside the protocol stack is chosen to be the same as the corresponding layer of the OSI-RM for easy reference. For example, layer 2 of the protocol stack submodule is called the data link layer and it performs monitoring and testing of the data Link layer of the OSI-RM. Like the OSI-RM, the layer boundaries should be chosen to minimize the information flow across the interface between the two layers. Each layer in the protocol stack has exactly one entry point. Information is passed from a lower layer to the layer above it through the upper layer entry point. Information will never flow in the reverse direction since it is a receive-only implementation. The active elements in each layer are called entities. Protocol entities are analogous to OSI-RM entities. They are basically reference implementation of the supported protocols.  The implementation of each of the entities follows the corresponding protocol  specification. Each entity contains a decoder and one (or more) finite state machine(s). In order to achieve more efficient execution time, only the D T E is being tested. Therefore, the F S M is built for the D T E only. This is sufficient because if a protocol violation is detected by the D C E F S M , it will also be detected by the D T E F S M . Therefore, testing the D C E is redundant and it will make the implementation more complex and slow down the monitor. The F S M of each entity is driven by two types of data, the data which are sent and received by the D T E . They can be distinguished by knowing the host which sent the data, and this information is available to the data processing submodule (DPS) and is passed to the protocol stack submodule (PSS) as a parameter. Thus, if the sending host  CHAPTER  2.  ARCHITECTURE  14  is the D C E , the data are received by the D T E , and if the sending host is the D T E , the data are sent by the D T E . When a protocol violation has occurred, the entity which detects the error reports this to the DPS which performs error handling (discussed in section 2.3.3). Each entity contains its own reset function, filter function and entry point. The addresses of those functions and entry point are known to the monitor from the initialization procedure of that entity. The reset function is used to reset an entity when the monitor needs to restart or when a protocol violation has occurred. The filter function allows the user to add or delete selected protocol data units for displaying and capturing for a particular layer. These functions are only called by the data processing submodule.  2.3.3  Data Processing Submodule (DPS)  The data processing submodule is the main control module inside the M M . It sits between the protocol entities and the DSM. Its functions include interfacing between the M M and the D S M , capturing and displaying decoded PDUs, error handling, and user interface handling.  2.3.3.1 Interfacing between the M M and the D S M Data are read from the socket connecting the DSM and the M M . As described in section 2.1, frames are packed together in the D E M before being sent to the DSM. Therefore, data units coming from the D S M contain packed data. The M M analyses all the frames inside the packed data and acknowledges to the D S M when it is done. The length of a frame inside the packed data is available to the M M since the first byte of a frame (which is added by the DEM) contains the length field of the frame. After reading the length of the frame, the DPS extracts the exact number of bytes from the  CHAPTER 2.  ARCHITECTURE  packed data and passes the frame (and control) to the PSS for further analysis.  15  The  entry point of the PSS is the entry point of the data link layer. When control is passed back from the PSS, the DPS starts capturing and displaying the information (see section 2.3.3.2 below). After the whole process is completed, the DPS extracts the next frame from the packed data or sends an acknowledgement to the D S M when all frames from the packed data have been processed.  2.3.3.2 Capturing and Displaying The monitor extracts data from the physical medium between the D T E and the D C E , so only external events, such as PDUs, can be captured. The DPS maintains a capture buffer for temporary storage of the output data. Like the receive buffer in DSM, the capture buffer is structured as a circular buffer but its size can be changed by the user. Each element of the buffer contains the completely decoded information of a physical packet which contains PDUs from every layer from one of the two terminals. That is to say, the information contains the decoded PDUs from the data link layer up to some higher layer and the information is stored in a human readable form. Information is stored as character strings so that it can be printed on the display screen or saved into a file directly. This module contains a macro to be used by the entities of the PSS to insert data into the buffer. The organization of each of the elements of the buffer is as follows. Starting from the data link entity (if selected), the DPS stores the output from this entity at the beginning of an empty character string. Any additional data will be appended to the end of the string, until control is passed back from the PSS. The DPS will then add the name of the sending host ( D T E or D C E ) in front of the character string. The whole string is  CHAPTER 2.  ARCHITECTURE  16  then printed on the screen and the pointer advanced to the next element of the buffer.  2.3.3.3 Error Handling One of the important features provided by the ISO-PM is its passive testing capability. The actual testing procedure is done by the PSS, with each entity of the PSS responsible for the corresponding protocol.  When a protocol violation occurs, the corresponding  entity reports the error, and the whole system is reset.  The DPS is responsible for  handling the procedures after an error has occurred. The DPS provides a macro for dealing with error messages. When a protocol violation is detected, the entity which detected the error may call that macro to report an error message to the user. The error message is stored in the capture buffer before being saved in an error record file and displayed on the screen. The DPS keeps track of the history of the conversation between the D C E and the D T E in order to allow the user to examine how the error has occurred. Since all the information has been stored in the capture buffer, the DPS simply dumps the whole capture buffer into an error record file. This file is a regular text file so that it may be printed on the display screen or line printer. After a protocol violation has occurred, the monitor resets the whole protocol stack, i.e., every entity inside the PSS, to its original state. As described in the previous section, each entity contains a reset function whose address is known to the DPS. To reset the PSS, the DPS simply calls the reset function of each of the entities. The monitor will stop monitoring, and the synchronization procedure has to be restarted if monitoring is to be resumed.  CHAPTER 2.  ARCHITECTURE  17  2.3.3.4 User Interface Handling The monitor contains a simple menu driven user interface. Its functions and their descriptions are as follows: 1. Display Error Record File: displays the error record file on the display screen. Since the file is a UNIX text file, the DPS calls the corresponding UNIX command to print it. 2. Filter: selects specific PDUs within each layer for display and capture. 3. Select Layer: this function is used to add or delete layer(s) for display or capture. This gives the user the flexibility to look at the decoded PDUs for all seven layers or any particular layer(s). This can be done by disabling or enabling the display function(s) of that layer(s). 4. Disable or Enable Layer: this function is to allow the user to shut down or turn on the FSM of any particular layer(s). Note that if the user wants to study a specific layer, all the layers beneath it must be enabled. 5. Change size of Capture RAM: changes the size of the capture buffer (this affects the amount of history that will be dumped in case of error). 6. Save Capture RAM to a file: saves the whole capture buffer into a text file for off line analysis. 7. Read File: reads a file. 8. Change Synchronization Wait Time: changes the waiting time for the synchronization procedure.  Chapter 3 Implementation The three modules of the current OSI-PM have been implemented on top of the UNIX operating system in three different Sun-3/50 workstations. They are written in C and the monitor is able to test up to the transport layer of the OSI-RM. This chapter discusses the prototype implementation of the monitor and its environment.  3.1  The environment  There are two existing environments available for developing the OSI-PM - the MPT386.2 and UNIX running on Sun-3 workstations. We chose the second environment for the following reasons: 1. UNIX provides a much better programming, debugging and text processing environment. The development time will be reduced significantly. 2. It contains a huge C - programming library, almost all needed primitive functions are implemented. 3. It is one of the most popular operating systems for minicomputers, workstations, and now PCs.  18  CHAPTER 3.  IMPLEMENTATION  19  There is one advantage for building the OSI-PM on the MPT386.2. We do not have to worry about the interface between the monitor and the communication line since there is an existing X.25 monitor built on the MPT386.2. The OSI-PM may use the interface built in the X.25 monitor. If the OSI-PM is developed on the Sun-3 workstation, it requires a synchronous serial driver for the workstation in order to communicate with the X.25 line. Fortunately, we managed to get hold of a driver and modified it for our use.  3.1.1  T h e Synchronous Serial Driver  The synchronous serial driver (ZSS) contains two layers. The lower layer is used to send and receive raw data through a set of low level interrupt handlers. The higher layer consists of some kernel interface routines which passes data through mbufs using 1  software interrupts. The driver has a socket interface that is accessible to the user programs. When an inet socket is opened with domain AF_CCITT and interface name 2  zssn, an entry in the protocol switch table of the kernel will be created and the socket will be connected to the serial port n. Since the kernel end of the socket interface also uses mbufs to pass data in and out of the sockets, data are passed directly between the serial port and the socket interface so that the user program is able to read data from the serial port. There are two serial ports installed at the back of a Sun-3 workstation - serial ports A and B. The two serial ports can be used to connect the Sun workstation with the D T E and DCE respectively, so that serial port A is used to collect data from the D T E and serial port B is used to collect data from the DCE. However, a socket of family AF_CCITT mbufs are standard Unix system memory buffers Unix Internet Domain.  1  2  CHAPTER 3.  IMPLEMENTATION  20  2K bytes-  1 byte  Figure 3.1: Format of Packed Data opens the synchronous driver on both serial ports A and B and the user program is not able to distinguish from which port the data are read. Since only the lower layer of the driver knows where the data come from, we had to modify the lower layer of the driver so that it passes also the port name to the mbufs. In order to minimize the change to the driver, we modified the address field of the data link layer's frame. Since only bit one and bit two are used in the address field, we use bit eight to indicate the port number such that the bit is set to one if the data are from port B, and zero otherwise.  3.2  Data Extraction Module  The implementation of the data extraction module (DEM) is relatively simple since the DEM contains only code for reading, packing and sending data. When a frame is read from one of the serial ports, the frame and its length are inserted into a buffer before sending to the DSM. The buffer is constructed as a one dimension array of size 2K bytes and has the format shown infigure3.1. In figure 3.1, the first frame contains 2 bytes of data, the second frame contains 5 bytes of data and so on. The buffer is sent to the DSM when it is full or when the 3  3  In fact the buffer is sent if the new frame inserted brings the total information in the buffer above  CHAPTER 3.  IMPLEMENTATION  21  communication line is idle, and the DEM starts to fill the buffer again.  3.3  Data Storage Module  As described in section 2.2, the data storage module (DSM) is structured as a circular buffer with data units of 2K bytes each. Each data unit is formatted as follows: typedef s t r u c t RxbufRecord{ int len;  byte  data[2000] ;  >  Each data unit contains the data and its length. When a packed data is received from the DEM, it is stored at the head of the circular buffer. The packed data at the tail of the buffer will be sent to the Monitor Module (MM) when a ready signal is received from the MM.  3.4  Monitor Module (MM)  As described in chapter 2, the Monitor Module (MM) contains two submodules : Data Processing Submodule (DPS) and Protocol Stack Submodule (PSS). The following subsections describe the implementations of the two submodules.  3.4.1  Data Processing Submodule  3.4.1.1 Entity Management The entity table is the data structure which connects the DPS with the entities in the PSS. The table records the locations of the reset functions, filter functions and entry 1.5K bytes.  CHAPTER 3.  IMPLEMENTATION  22  points of the PSS entities. It is structured as an array of entity table records indexed by the name of the entities. There is an entity table record for each protocol entity of the PSS and this record is formatted as follows: typedef struct { void (*entryPt)(); void (*resetProc)(); void (*filterProc)(); }entitieslableRecord; entitiesTableRecord  entitiesTable[MAX_LAYER+l];  • entryPt is a pointer to the entry point of the entity. • resetProc is a pointer to the reset function. • filterProc is a pointer to the filter function. 3.4.1.2 Capture Buffer Management The capture buffer is structured as a circular buffer. It is implemented as a circular link list with elements as follows (the capture buffer is called the script buffer inside the program): typedef struct scriptBufStruct-( char data[100]; struct scriptBufStruct *next; }scriptBufRecord; scriptBufRecord *scriptHead, *scriptBase; The buffer is created at system initialization time. Data are inserted into the buffer using the two macros: • outdata(X) : used to insert decoded PDUs into the buffer. X is the data to be inserted.  CHAPTER 3.  IMPLEMENTATION  23  • errorMsg(X) : used to insert error message into the buffer in case a protocol violation has occurred. The DPS contains a set of routines to maintain the buffer at system run time. The names and descriptions of these routines are as follows: • flushScriptBuffer(outputFile) : this routine simply copies all data from the circular buffer into the file outputFile. • resetScriptBufftr() : resets the buffer so that it contains no data. • changeScriptBufSize () : this routine is used when the user wants to change the buffer size. It destroys the original buffer, frees all the memory space, and creates a new buffer with the new size. • saveScriptBuf() : it callsflushScriptBufferto dump the buffer into a file specified by the user. 3.4.1.3 Data Passing Data are received from the socket connecting the DSM and MM. The DPS uses the system call select to check if there are data waiting. After the data are received from the DSM, the DPS extracts frames from the packed data and determines the host which sent the data. As described in section 3.1.1, bit eight of the address field of a link packet is one if the packet was from the D T E , and zero if it came from the DCE. The DPS passes the frame and whether the host is the D T E or DCE as parameters to the data link entity by the following procedure call: entitiesTable[DATA_LINK] .entryPtO;  CHAPTER 3.  IMPLEMENTATION  24  The DPS uses DATAXINK as an index to locate the entry of the data link entity from the entity table and retrieve the entry point of this entity. It then passes frames to this entity through the entry point. This procedure call is also used by all entities to pass data to the entities above them. For example, the packet entity passes data to the transport entity by calling entitiesTable[TRANSPORT].entryPt(). 3.4.1.4 Error Handling The actual testing procedure is done by the PSS with each entity of the PSS testing the corresponding protocol entity of the OSTRM. When a protocol violation is detected, the entity which detects the error uses the macro errorMSG to report the error. The entity then calls the routine resetAULayer in DPS to deal with the error. This routine resets all entities inside the PSS by calling the reset function of each of the entities.  Since the reset functions are accessible through the entity table, the  procedure call: entitiesTable[DATA_LINK] .resetProcO ; calls the reset function of the data link entity (for example) with DATAXINK as an index to the entity table. After resetting the entities, the DPS callsflushScriptBufferto dump the entire capture buffer into the error record file, and resetScriptBuffer to reset the buffer. The current time and date are also recorded in the file.  3.4.2  Protocol Stack Submodule  The current protocol stack submodule (PSS) contains three protocol entities : data link entity, network entity, and transport entity. The system is capable of testing up to the  CHAPTER  3.  IMPLEMENTATION  25  transport layer of the OSI-RM. Each entity consists of an entry point (which is actually a procedure call), decode function, reset function, filter function, display function, initialization function and a set of supported routines. It is up to the implementer to design his own set of functions. The following sections give a general overview of the implementation of the PSS. 3.4.2.1 Initialization The implementer of the entity is responsible to add the initialization routine to the main routine of the DPS in the program named monitor.c. initialization routine is XXJnit()  A typical name for the  where XX is the short form of the entity name. For  example, DL_init() is the initialization routine for the data link entity and PK_init() is the initialization routine for the packet (or network) entity.  3.4.2.2 Creation of Entities A new entity is added to the OSI-PM by executing its initialization routine which calls the setEntryPoint routine. The setEntryPoint routine is one of the supported routines for the DPS. It adds a new entity table record to the entity table. void setEntryPoint(layer, entryPoint, resetProc, filterProc) ; The entity passes the following parameters to the routine: • the name of the layer such as DATA-LINK and NETWORK. The entity table record is referenced by this name. • the entry point of the entity. • the addresses of the reset and the filter functions.  CHAPTER 3.  IMPLEMENTATION  26  3.4.2.3 Decoding and Testing For each of the current three entities of the PSS, decoding and testing are implemented as one single routine in order to minimize the number of procedure calls. The PDUs are driven through the Finite State Machine (FSM) immediately after they are decoded. Each FSM of the entities is implemented as a cascaded switch statement. The entity performs action that corresponds to the decoded PDU within the current state of the DTE. For example, part of the FSM for the packet entity is as follows: switch(decoded PDU type){ case N_PTI_CALL_REQ: switch(DTE current FSM){ case CALL_SETUP_STATE: switch(DTE current state){ case P l : statement1; break; case P2: statement2; break; case P3:  case P7: }  break; case DATA.TRANSFER:  }  break; case N_PTI_CALL_CONN:  >  CHAPTER 3.  IMPLEMENTATION  27  For the above FSM, if the decoded PDU type is the CALL REQUEST packet and the current FSM used is CALLJSETUPJSTATE and the current state of the DTE is the 4  ready state P l , then statementl will be executed. We assume the reader of this thesis is familiar with the X.25 packet layer protocol, and will not go into details. The FSMs for the data link entity and the transport entity also follow this format. 3.4.2.4 Reset Function The reset function is used to reset an entity when the monitor needs to restart or when a protocol violation has occurred. This function simply resets the FSMs of the DTE of a particular entity to their ready state. For example, the reset function for the packet entity resets the current FSM of the DTE to its ready state (Pl).  3.4.2.5 Filter and Display Functions The filter function allows the user to add or delete selected protocol data units of a particular layer for display and capturing. The typical implementation of the filter function is as follows (using the packet layer as an example). A variable PKmaskfpk-narne] is defined for each packet of the packet entity where pk-name is a variable representing the name of the packet such as CALL_REQUEST and RESTART_REQUEST. The variable PKmask[pk-name] is set to a constant MASK if the user does not want to capture and display the packet named pk-name; it is set to zero otherwise.  This variable is used  by the display function to determine whether the information should be inserted in the capture buffer or discarded. The display function of the packet entity is as follows: There are three different FSMs built in the packet entity, they are RESTARTJ3TATE, CALLJSETUPJSTATE and DATA.TRANSFER 4  CHAPTER  3.  IMPLEMENTATION  28  s w i t c h ( p a c k e t name I PKmask[packet name]){ c a s e INCOMING_CALL :  outdata("INCOMING CALL"); break; c a s e CALL.REQUEST :  outdata("CALL REQUEST"); break; c a s e CALL.CONNECTED : outdataC'CALL CONNECTED") ; break; c a s e CLEAR_REQUEST : outdata("CLEAR REQUEST");  c a s e DIAGNOSTIC :  >  If the packet INCOMING_CALL is sent or received by the DTE, it is or-ed with the variable PKmaskflNCOMING.CALLj before it is inserted in the capture buffer. Therefore, unless PKmaskflNCOMING-CALL] is equal to zero (i.e., the user wants to capture and display this packet) the information "INCOMING CALL" will not be added to the buffer using outdata.  3.4.2.6 Error Handling Function The error handling function of an entity is called when a protocol violation is detected by the entity. It constructs the error messages to be reported to the user and calls the resetAULayer routine to instruct the DPS to reset the monitor.  Chapter 4 Testing ofthe O S I - P M The OSI-PM was tested by using it to monitor the traffic to and from the ean gateway. 1  The OSI-PM was connected between the D T E and the DCE as shown in figure 4.1. As described in section 3.1.1, the DTE, which represents the host (the ean gateway), was connected to serial port B and the DCE, which represents the outside world, was connected to serial port A at the back of the Sun-3 workstation. All seven layers of the OSI-RM were implemented on the host. The following sections describe the result of monitoring the ean gateway using the MPT386.2 X.25 monitor, report generation for the OSI-PM, and some sample traces and error reports generated by the OSI-PM.  4.1  MPT386.2 X.25 Monitoring  The ean gateway was monitored by the MPT386.2 X.25 monitor before the OSI-PM was designed and implemented. The reasons for monitoring the line were as follows: • to find out the bit patterns of the data traffic of a live communication line, l  ean  is one of the major electronic mailing systems used in the University of British Columbia.  29  CHAPTER 4. TESTING OF THE OSI-PM  30  OSI-PM SeriaJ port B  Serial port A I  II  i  J  DTE  DCE  Figure 4.1: Connecting the D T E , the D C E and the O S I - P M • to find out the peak data rate of the communication fine, • to understand how a passive monitor works in order to design the OSI-PM. The X.25 monitor was connected to the ean gateway, using a Y cable , following the 2  connection shown in figure 4.2. As mentioned in Section 1.1.2, the monitor is restricted to packet layer monitoring only and it is not able to perform passive testing. Some sample traces were collected and they were useful for designing the output format of the OSI-PM. The following example is a short report produced by the X.25 monitor: DCE  01  DTE  01  UA  SABM  DTE  03  I  DCE  03  RR  0  RESTART  INDICATION  A Y cable is a standard RS-232C cable which has three heads. It is used to connect three components together 2  CHAPTER 4. TESTING OF THE OSI-PM  31  Y cable  DTE s v.—  MPT386.2 X.25 Monitor  DCE  Figure 4.2: Connecting the D T E , the D C E and the MPT386.2 DCE DTE DTE DCE DCE DTE DTE DCE DCE DTE DTE DCE DCE  01 01 03 03 01 01 03 03 01 01 03 03 01  I RR I RR I RR I RR I RR I RR I  0  RESTART CONFIRM  1  INCOMING CALL  1  CALL ACCEPTED  1  DATA 256  1  RR  1  RESET INDICATION  1  RESET CONFIRM  IDAC0M  After monitoring the line for a few days, the peak data rate of the line was found to be around 7100 b/s. Therefore, the OSI-PM must be designed to handle more than that peak data rate. The throughput measurement of the ean line on Thursday, July 27, 1989, which contains the peak data rate, is shown in figure 4.3. The remainder of this chapter discusses report and error generations of the OSI-PM.  CHAPTER 4. TESTING OF THE OSI-PM  32  700C  6000  Throughput (b/s)  4000  2000  20  10  Time (o'clock)  Figure 4.3: Throughput of ean line, Thur., July 27, 1989  24  CHAPTER  4. TESTING  33  OF THE OSI-PM  Data Link Entity  D L  Frame name Additional Information  Packet Entity P K  lcn#  Packet name  Transport Entity T P  PDU name Additional Information  Figure 4.4: Report Format  4.2  Report Generation  Each entity of the OSI-PM is responsible for reporting its decoded PDUs and internal state changes. It is up to the implementer of that entity to design the format of the report. However, a general format is used for all the entities of the current implementation of the OSI-PM. The format of the report of each entity is as follows: Four spaces are skipped at the beginning of the report line followed by a two-character entity name, followed by the information to be displayed. Figure 4.4 shows the report format of each of the entities. If there is an internal state change to be reported, the name of the state is displayed after seven empty spaces. (Note, only the state of each entity of the DTE is reported, see section 2.3.2.) The reason for skipping four spaces before the entity name is to allow space to display the name of the host ( D T E or D C E ) which sent the data.  CHAPTER 4. TESTING OF THE OSI-PM  34  An example of the report generated by the OSI-PM is as follows: DTE DL I NR=3 NS=4 PK LCN=7 CALL.REQUEST DTE CALL REQUEST (P2) DCE DL RR NR=5 DCE DL I NR=5 NS=3 PK LCN=7 CALL_CONNECTED FLOW CONTROL READY (Dl) DTE DL I NR=4 NS=5 PK LCN=7 DATA PR=0 PS=0 TP CONNECTION REQUEST WFCC DCE DL I NR=7 NS=6 PK LCN=7 DATA PR=1 PS=0 TP CONNECTION CONFIRM OPEN In the above example, the D T E establishes a call in logical channel number seven (LCN=7) at the packet layer level. It sends a C A L L R E Q U E S T packet and changes its state to D T E C A L L R E Q U E S T (P2). The D C E replies with a C A L L C O N N E C T E D packet. The state of the D T E is changed to F L O W C O N T R O L R E A D Y (Dl) after it has received the packet. After the network connection is established, the transport layer of the D T E sends a C O N N E C T I O N R E Q U E S T using the connection and changes its state to W F C C (wait for connection confirm). Finally, the connection is completed after the transport entity of the D T E has received a C O N N E C T I O N C O N F I R M from the D C E , and it changes its state to O P E N .  4.2.1  Report of Error  An error report is generated when a protocol violation occurred in a particular entity. It reports the name of the entity, the cause of the error, and the time and date the error occurred. The following is an example of an error reported by the packet entity:  CHAPTER 4. TESTING OF THE OSI-PM  35  Packet layer error for DTE, unexpected packet sent Packet DATA i s sent i n state DTE CALL REQUEST (P2), LCN = 10... Error occurred on Thursday July 5, 90, time 10:52:44 The packet entity of the OSI-PM detected an unexpected packet sent by the D T E at the packet layer of the communication line. The unexpected packet was a D A T A packet which was sent in the state D T E C A L L R E Q U E S T (P2) in logical channel number 10 on Thursday July 5, 90, at 10:52 am. Note that in state D T E C A L L R E Q U E S T (P2), the D T E should be waiting for a C A L L C O N N E C T E D packet from the D C E (as in the previous example). A D A T A packet should not have been sent before the connection is established.  4.3  Report of Sample Traces  The ean gateway was monitored by the OSI-PM for several days. Traces of the traffic to and from the gateway were collected, and sample reports produced by the OSI-PM are shown in the following sections. Detailed comments of the traces are given in report #1 only since the other reports are similar. Note that the states shown in the report are the states for the D T E (refer to section 2.3.2).  4.3.1  Report #1  This report contains data of all three entities - data link entity, packet entity and transport entity - of the current OSI-PM. Four calls are recorded in the following report. Two calls were requested by the D C E on logical channel number 1, and two calls were requested by the D T E on logical channel number 10. Both calls from the D T E were rejected by the D C E .  DCE DL I  NR=1  NS=6  * The DCE sent an INCOMING CALL  CHAPTER 4. TESTING OF THE OSI-PM  PK  LCN=1 INCOMING.CALL DCE INCOMING CALL (P3)  DTE DL PK  I NR=7 NS=1 LCN=1 CALL.ACCEPTED FLOW CONTROL READY (Dl)  DCE DL DCE DL PK TP  RR NR=2 I NR=2 NS=7 LCN=1 DATA PR=0 PS=0 CONNECTION REQUEST WFTRESP  DTE DL PK DTE DL PK TP  I NR=0 NS=2 LCN=1 RR PR=1 I NR=0 NS=3 LCN=1 DATA PR=1 PS=0 CONNECTION CONFIRM OPEN  DCE DL RR NR=3 DCE DL RR NR=4 DCE DL I NR=4 NS=0 PK LCN=1 RR PR=1  * * * *  packet at logical channel number (LCN) 1, the DTE changed to state DCE INCOMING CALL (P3) after the packet was received. The DTE replied with a CALL ACCEPTED packet and changed i t s state to FLOW CONTROL READY (Dl) The connection between the DTE and the DCE was established at the packet layer level. The two terminals were ready to exchange data using this packet connection.  The transport entity of the DCE sent a CONNECTION REQUEST to the DTE using the network connection. The TPDU was embedded i n the DATA packet of packet layer. The transport entity of the DTE changed i t s state to WFTRESP. * The DTE replied with a RR packet * at the packet layer level. * * * * * * *  The DTE replied with a CONNECTION CONFIRM at the transport layer level, and changed i t s state to OPEN. The transport connection was established and the two terminals were able to transmit data using this connection.  CHAPTER 4. TESTING OF THE OSI-PM  DCE DL I NR=4 NS=1 PK LCN=1 DATA PR=1 PS=1 TP DATA DTE DL PK DCE DL DTE DL PK TP  * This was the f i r s t DATA TPDU * sent by the DCE.  I NR=2 NS=4 LCN=1 RR PR=2 RR NR=5 I NR=2 NS=5 LCN=1 DATA PR=2 PS=1 DATA  DTE DL I NR=2 NS=6 PK LCN=10 CALL_REQUEST DTE CALL REQUEST (P2)  * * * *  The DTE wanted to establish another network connection at LCN #10, in addition to the connection at LCN #1.  * * * * * *  However, the DCE rejected the c a l l by returning a CLEAR INDICATION packet. After receiving the packet, the DTE changed its state to DCE CLEAR INDICATION (P7).  DCE DL RR NR=6 DCE DL RR NR=7 DCE DL I NR=7 NS=2 PK LCN=1 RR PR=2 DTE DL RR NR=3 DCE DL I NR=7 NS=3 PK LCN=10 CLEAR.INDICATION DCE CLEAR INDICATION (P7)  DTE DL I NR=4 NS=7 * The DTE replied to the DCE using PK LCN=10 CLEAR.CONFIRMATION * a CLEAR CONFIRMATION packet and READY (Pl) * changed its state to READY (Pl). DCE DL RR NR=0 DCE DL I NR=0 NS=4 PK LCN=1 DATA PR=2 PS=2 TP DATA  * The two terminals were s t i l l * exchanging data using the * previous connection.  CHAPTER 4. TESTING OF THE OSI-PM  DTE DL PK DCE DL DCE DL PK DTE DL PK DCE DL PK DTE DL PK  I NR=5 NS=0 LCN=1 RR PR=3 RR NR=1 I NR=1 NS=5 LCN=1 DATA PR=2 PS=3 I NR=6 NS=1 LCN=1 RR PR=4 I NR=1 NS=6 LCN=1 DATA PR=2 PS=4 I NR=7 NS=2 LCN=1 RR PR=5  DCE DL PK TP DTE DL PK DCE DL DTE DL PK TP DCE DL DCE DL DCE DL PK  I NR=1 NS=6 LCN=1 DATA PR=5 PS«1 DATA I NR=7 NS=2 LCN=1 RR PR=2 RR NR=2 I NR=7 NS=3 LCN=1 DATA PR=2 PS=5 DATA RR NR=3 RR NR=4 I NR=4 NS=7 LCN=1 RR PR=6  DCE DL I NR=4 NS=0 PK LCN=1 CLEAR_INDICATTON DCE CLEAR INDICATION (P7) DTE DL I NR=1 NS=4 PK LCN=1 CLEAR.CONFIRMATION READY (Pl)  * * * * * * * *  The DCE sent a CLEAR INDICATION to complete the c a l l at LCN #1. The DTE changed its state to DCE CLEAR INDICATION (P7), and replied with a CLEAR CONFIRMATION packet. The state of the DTE is changed to READY (Pl) after sending the  CHAPTER 4. TESTING OF THE OSI-PM  * packet. DCE DL RR NR=5 NR=1 NS=5 DTE DL I PK LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) DCE DL RNR DCE DL I NR=6 NS=1 PK LCN=1 INCOMING.CALL DCE INCOMING CALL (P3) DTE DL I NR=2 NS=6 PK LCN=1 CALL.ACCEPTED FLOW CONTROL READY (Dl) DCE DL RR NR=7 DCE DL I NR=7 NS=2 PK LCN=1 DATA PR=0 PS=0 TP CONNECTION REQUEST WFTRESP DTE DL I NR=3 NS=7 PK LCN=1 RR PR=1 DTE DL I NR=3 NS=0 PK LCN=1 DATA PR=1 PS=0  DCE DL PK TP DTE DL PK DCE DL DTE DL PK TP DTE DL PK  I NR=1 NS=4 LCN=1 DATA PR=1 PS=1 DATA I NR=5 NS=1 LCN=1 RR PR=2 RR NR=2 I NR=5 NS=2 LCN=1 DATA PR=2 PS=1 DATA I NR=5 NS=3 LCN=1 CLEAR_REQUEST DTE CLEAR REQUEST (P6)  * * * *  The DTE and the DCE tried to set up calls at the same time. The DTE used LCN #10 and the DCE used LCN #1.  * The network connection at LCN #1 * was established after the DTE * sent a CALL ACCEPTED packet.  CHAPTER 4. TESTING OF THE OSI-PM  DCE DL RR NR=3 DCE DL RR NR=4 DCE DL I NR=4 NS=5 PK LCN=1 CLEAR.CONFIRMATION READY (Pl) DTE DL RR NR=6 DTE DL I NR=6 NS=4 PK LCN=10 CLEAR.REQUEST DTE CLEAR REQUEST (P6) DCE DL RR NR=5 DCE DL I NR=5 NS=6 PK LCN=10 CLEAR.CONFIRMATION READY (Pl) DTE DL RR NR=7  * The DTE sent a CLEAR REQUEST * packet to clear the c a l l at * LCN \#10 since the DCE did not * reply to this c a l l .  CHAPTER 4. TESTING OF THE OSI-PM  4.3.2  Report  #2  TP DTE PK One of the features provided by the OSI- DTE PK TP PM is that it gives the user flexibility to DCE PK display and capture the decoded PDUs for DCE PK TP all existing layers or any particular subset DTE PK DTE PK of the layer(s). For the following report, the data link entity is not selected by the user. DCE Therefore, only the data from the packet DTE and transport entities are reported.  DCE PK LCN=1 INCOMING.CALL DCE INCOMING CALL (P3) DTE PK LCN=1 CALL.ACCEPTED FLOW CONTROL READY (Dl) DCE PK LCN=1 DATA PR=0 PS=0 TP CONNECTION REQUEST WFTRESP DTE PK LCN=1 RR PR=1 DTE PK LCN=1 DATA PR=1 PS=0 TP CONNECTION CONFIRM OPEN DCE PK LCN=1 RR PR=1 DCE PK LCN=1 DATA PR=1 PS=1 TP DATA DTE PK LCN=1 RR DTE PK LCN=1 DATA TP DATA DCE PK LCN=1 RR  DCE PK LCN=1 DATA  PR=2 PR=2 PS=1 PR=2  PR=1 PS=1  DCE DTE  DCE DCE  DTE DTE  DATA LCN=1 RR PR=2 LCN=1 DATA PR=2 PS DATA LCN=1 RR PR=2 PR=2 PS LCN=1 DATA DATA PR=3 LCN=1 RR LCN=1 CLEAR.REQUEST DTE CLEAR REQUEST (P6) PK LCN=1 CLEAR.CONFIRMATION READY (Pl) PK LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) PK LCN=10 CALL.CONNECTED FLOW CONTROL READY (Dl) PK LCN=10 DATA PR=0 PS=0 TP CONNECTION REQUEST WFCC PK LCN=10 RR PR=1 PR=1 PS=0 PK LCN=10 DATA TP CONNECTION CONFIRM OPEN PK LCN=10 RR PR=1 PK LCN=10 DATA PR-1 PS=1 TP DATA  DCE PK TP DTE PK DTE PK TP DCE PK DCE PK TP  LCN=10 DATA LCN=10 LCN=10 DATA LCN=10 LCN=10 DATA  DATA  PR=0 PS=2  RR DATA  PR=3 PR=3 PS=0  RR DATA  PR=1 PR=1 PS=3  CHAPTER 4. TESTING OF THE OSI-  DTE PK DCE PK TP DTE PK DTE PK TP DTE PK TP DCE PK DCE PK DCE PK TP DTE PK DTE PK  LCN=10 RR PR=4 LCN=10 DATA PR=1 PS=4 DATA LCN=10 RR PR=5 LCN=10 DATA PR=5 PS=1 DATA LCN=10 DATA PR=5 PS=2 DATA LCN=10 RR PR=2 LCN=10 RR PR=3 LCN=10 DATA PR=3 PS=5 DATA LCN=10 RR PR=6 LCN=10 CLEAR.REqUEST DTE CLEAR REQUEST (P6) DCE PK LCN=10 CLEAR.CONFIRMATION READY (Pl)  4.3.3  Report  #3  Another feature provided by the OSI-PM is the filter function which allows the user to select specific PDUs within each layer for display and capturing. For the following  TP DCE PK TP DTE PK TP DCE PK TP DTE PK TP DTE PK DTE PK DTE PK TP DTE PK TP DTE PK DCE PK TP DTE PK TP DCE PK TP DCE PK  report, the data link entity is not selected DTE PK TP by the user and, in addition, the RR packet of packet layer is filtered out by the filter DCE PK TP function. DTE PK TP DTE PK LCN=10 CALL.REQUEST DTE PK DTE CALL REQUEST (P2) TP DCE PK LCN=10 CALL_CQNNECTED DCE PK FLOW CONTROL READY (Dl) TP DTE PK LCN=10 DATA PR=0 PS=0  CONNECTION REQUEST WFCC PR=1 PS=0 LCN=10 DATA CONNECTION CONFIRM OPEN LCN=10 DATA PR=1 PS=1 DATA LCN=10 DATA PR=2 PS=1 DATA LCN=10 DATA PR=2 PS=2 DATA PR=2 PS=3 LCN=10 DATA LCN=10 DATA PR=2 PS=4 LCN=10 DATA PR=2 PS=5 DATA PR=2 PS=6 LCN=10 DATA DATA LCN=9 CALL.REQUEST DTE CALL REQUEST (P2) LCN=10 DATA PR=7 PS=2 DATA LCN=10 DATA PR=3 PS=7 DATA LCN=10 DATA PR=0 PS=3 DATA LCN=9 CALL.CONNECTED FLOW CONTROL READY (Dl) LCN=9 DATA PR=0 PS=0 CONNECTION REQUEST WFCC LCN=10 DATA PR=0 PS=4 DATA PR=5 PS=0 LCN=10 DATA DATA LCN=10 DATA PR=5 PS=1 DATA LCN=9 DATA PR=1 PS=0 CONNECTION CONFIRM OPEN  43  CHAPTER 4. TESTING OF THE OSI-PM  DCE PK TP DTE PK TP DTE PK  DTE PK LCN=10 DATA  DCE  4.3.4  DCE DTE DTE  LCN=10 DATA PR=2 PS=5 DATA LCN=9 DATA PR=1 PS=1 DATA LCN=10 CLEAR.REQUEST DTE CLEAR REQUEST (P6) PK LCN=10 CLEAR.CONFIRMATION READY (Pl) PK LCN=9 DATA PR=2 PS=1 TP DATA PK LCN=9 DATA PR=2 PS=2 TP DATA PK LCN=9 DATA PR=2 PS=3  DCE PK TP DTE PK TP DTE PK TP DCE PK TP DTE PK DCE DTE DCE DTE  DCE  LCN=9 DATA PR=2 PS=4 DATA LCN=9 DATA PR=5 PS=2 DATA LCN=9 DATA PR=5 PS=3 DATA LCN=9 DATA PR=4 PS=5 DATA LCN=9 CLEAR.REQUEST DTE CLEAR REQUEST (P6) PK LCN=9 CLEAR.CONFIRMATION READY (Pl) PK LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) PK LCN=10 CALL.CONNECTED FLOW CONTROL READY (Dl) PK LCN=10 DATA PR=0 PS=0 TP CONNECTION REQUEST WFCC PK LCN=10 DATA PR=1 PS=0 TP CONNECTION CONFIRM OPEN  PR-1 PS=1  Report # 4  The following report contains data only for call setup and clear for the packet and transport entities.  DTE PK LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) DTE PK LCN=9 CALL.REQUEST DTE CALL REQUEST (P2) DCE PK LCN=9 CALL.CONNECTED FLOW CONTROL READY (Dl) DTE TP CONNECTION REQUEST WFCC DCE TP CONNECTION CONFIRM OPEN DCE PK LCN=10CALL.CONNECTED FLOW CONTROL READY (Dl) DTE TP CONNECTION REQUEST WFCC DCE TP CONNECTION CONFIRM OPEN DTE PK LCN=9 CLEAR.REQUEST DTE CLEAR REQUEST (P6) DCE PK LCN=9 CLEAR.CONFIRMATION READY (Pl) DTE PK LCN=10 CLEAR.REQUEST DTE CLEAR REQUEST (P6) DTE PK LCN=9 CALL.REQUEST DTE CALL REQUEST (P2) DCE PK LCN=9 CALL.CONNECTED /  CHAPTER 4. TESTING OF THE OSI-PM  DTE TP DCE TP DCE PK DTE TP DCE TP DTE PK DCE PK DTE PK DCE PK DTE PK DTE PK  DCE PK DTE TP DCE TP  FLOW CONTROL READY (Dl) CONNECTION REQUEST WFCC CONNECTION CONFIRM OPEN LCN=10 CALL.CONNECTED FLOW CONTROL READY (Dl) CONNECTION REQUEST WFCC CONNECTION CONFIRM OPEN LCN=9 CLEAR.REQUEST DTE CLEAR REQUEST (P6) LCN=9 CLEAR.CONFIRMATION READY (Pl) LCN=10 CLEAR.REQUEST DTE CLEAR REQUEST (P6) LCN=10 CLEAR.CONFIRMATION READY (Pl) LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) LCN=9 CALL.REQUEST DTE CALL REQUEST (P2) OPEN LCN=10 CALL.CONNECTED FLOW CONTROL READY (Dl) CONNECTION REQUEST WFCC CONNECTION CONFIRM OPEN  CHAPTER 4. TESTING OF THE OSI-PM  4.4  45  Error Report  An error report is generated when a protocol violation occurred in a particular entity. It reports the name of the entity, the cause of the error, and the time and date the error occurred. The ean line was tested for a few days using the OSTPM. However, no error was detected by the system. In fact, the ean software has been running for a few years and it is a reliable system. Therefore, we generated some artificial errors in the data extracted from the ean line in order to test the OSTPM. The errors were generated in the Data Storage Module (DSM). After receiving data from the Data Extraction Module (DEM), the DSM randomly changed some bits of the data before sending them to the Monitor Module (MM). The following sections show the errors that were detected and reported by the system.  4.4.1  Error Report #1  DCE DL PK DCE DL PK DTE DL PK  I NR=2 NS=7 LCN=8 RR PR=5 I NR=2 NS=0 LCN=8 RR PR=6 I NR=1 NS=2 LCN=10 CALL.REQUEST DTE CALL REQUEST (P2) DCE DL RR NR=3 DCE DL I NR=3 NS=1 PK LCN=8 DATA PR=6 PS=2 TP DATA  DCE DL I  NR=1 NS=7  /* /* /* /*  CALL REQUEST sent, the state of DTE is changed to DTE CALL REQUEST (P2).  CHAPTER 4. TESTING OF THE OSI-PM  46  PK TP DTE DL PK DTE DL PK DCE DTE DTE  DCE DCE  DCE  LCN=8 DATA PR=1 PS=5 DATA I NR=0 NS=1 LCN=8 RR PR=6 I NR=0 NS=2 LCN=8 CLEAR.REQUEST DTE CLEAR REQUEST (P6) DL RR NR=2 DL RR NR=1 DL I NR=1 NS=3 PK LCN=9 CLEAR.REQUEST DTE CLEAR REQUEST (P6) DL RR NR=4 DL I NR=4 NS=1 PK LCN=9 CLEAR.CONFIRMATION READY (Pl) DL RR NR=6  Packet layer error for DTE, unexpected packet sent Packet DATA is sent in state DTE CALL REQUEST (P2), LCN = 10. . . Error occurred on Thursday July 5, 90, time 10:52:44 The above behavior constituted an error since an unexpected packet DATA was sent in state D T E CALL REQUEST ( P 2 ) on logical channel number 10. The system records a trace of the history before the error which may be analyzed to determine the cause of the error. In this case, CALL REQUEST was sent by the DTE in the beginning of the trace, but there was no CALL CONNECT found. A DATA packet should not have been sent before the connection was established.  4.4.2  Error Report #2  DTE DL PK DCE DL DTE DL PK  I NR=2 NS=5 LCN=8 RR PR=3 RR NR=6 I NR=2 NS=6 LCN=8 DATA PR=3 PS=5  CHAPTER 4. TESTING OF THE OSI-PM  47  TP DCE DL DCE DL PK DCE DL PK DCE DCE DCE  DCE  DTE DCE DTE  DCE DTE  DTE  DATA RR NR=7 I NR=7 NS=2 LCN=10 RR PR=2 I NR=7 NS=3 LCN=8 CLEAR.REqUEST DTE CLEAR REQUEST (P6) DL RR NR=0 DL RR NR=1 DL I NR=1 NS=4 PK LCN=8 CLEAR_CONFIRMATION READY (Pl) DL I NR=1 NS=5 PK LCN=10 DATA PR=2 PS=1 TP DATA DL I NR=6 NS=1 PK LCN=10 RR PR=2 DL RR NR=2 DL I NR=6 NS=2 PK LCN=10 DATA PR=2 PS=2 TP DATA DL RR NR=3 DL I NR=6 NS=3 PK LCN=10 DATA PR=2 PS=3 TP DISCONNECTION REQUEST CLOSED DL I NR=0 NS=3  Packet layer error for DTE, unexpected packet sent... Packet DATA is sent in state READY (Pl), LCN = 128... Error occurred on Thursday July 5, 90, time 11:2:40  The system detected the error that an unexpected packet DATA was sent in state READY (Pl) at logical channel number 128. This error might be the result of a transmission error or might be caused by noise on the line which changed the logical channel number to 128.  CHAPTER 4. TESTING OF THE OSI-PM  4.4.3  Error Report #3  DCE DL I NR=7 NS=4 PK LCN=9 CALL.CONNECTED FLOW CONTROL READY (Dl) DTE DL I NR=5 NS=7 PK LCN=9 DATA PR=0 PS=0 TP CONNECTION REQUEST WFCC DCE DL RR NR=0 DCE DL I NR=0 NS=5 PK LCN=9 RR PR=1 DCE DL I NR=0 NS=6 PK LCN=9 DATA PR=1 PS=0 TP CONNECTION CONFIRM OPEN DTE DL I NR=7 NS=0 PK LCN=9 RR PR=1  DTE DL PK TP DCE DL DCE DL PK TP  I NR=4 NS=6 LCN=9 DATA PR=2 PS=2 DATA RR NR=7 I NR=7 NS=4 LCN=1 DATA PR=2 PS=0 DATA  Transport layer error for DTE, invalid TPDU sent DATA ACKNOWLEDGMENT is sent in state CLOSED, class 0. Error occurred on Thursday July 5, 90, time 16:8:15  CHAPTER 4. TESTING OF THE OSI-PM  49  The above represented an error behavior detected by the transport entity of the OSIPM since an invalid TPDU - DATA ACKNOWLEDGMENT was sent by the DTE in class 0. The DATA ACKNOWLEDGMENT is not defined in class 0.  Chapter 5 Conclusion and Future Work We have described the design and a prototype implementation of the Open Systems Interconnection Passive Monitor (OSI-PM). The system is based on the principles of the OSI - Reference Model (OSI-RM) and it provides a framework for the development of multi-layer passive monitoring and testing. The OSI-PM adopts the same seven-layer architecture of the OSI-RM representing the seven protocol layers. The features provided by the OSI-PM include: • detects protocol violation as they occur in addition to the monitoring functions. • provides the capability of selectively displaying, capturing, and analyzing the protocol events. • provides flexibility to display and capture the decoded PDUs for all existing layers or any particular subset. • the filter function allows the user to select specific PDUs within each layer. • layers are independent of each other so that changes in one layer do not require change in the other layers.  50  CHAPTER  5. CONCLUSION  AND FUTURE  WORK  51  Detailed discussions of the architecture and implementation of the OSI-PM have been presented. The OSI-PM contains three modules: Data Extraction Module (DEM), Data Storage Module (DSM) and Monitor Module (MM). The Monitor Module in turn contains two submodules : Data Processing Submodule (DPS) and Protocol Stack Submodule (PSS). The three main modules are implemented on three different machines so that they can run concurrently in a pipeline fashion to increase packet processing speed. The modules of the current OSI-PM are implemented on top of the UNIX operating system in three different Sun workstations, and currently the system is capable of monitoring and testing the data link layer, the network layer and the transport layer of the OSI-RM. We have used the OSI-PM to monitor the traffic to and from the ean gateway. Some reports generated by the system including sample traces and error reports have also been presented. Processing speed is one of the most important factors to be considered in developing a passive monitor and tester. Future work of the OSI-PM involves mostly techniques to improve the processing speed of the system further.  1. The Data Extraction Module was found to be the bottleneck since the ZSS driver performs a lot of i/o and interrupt operations and thus requires much C P U processing. We may use a faster ZSS driver or a faster Sun workstation, such as the Sparc-station, in order to increase the processing speed of the module, so that the system is able to handle much higher data rate. 2. The other way to increase the processing speed is to implement the seven entities into seven different machines and connect them via Ethernet sockets or other network so that all the seven entities can run concurrently in a pipeline fashion.  CHAPTER  5. CONCLUSION  AND FUTURE  WORK  52  3. If the speed of the system is increased, more information carried by the PDUs can be reported. 4. The current system uses a menu driven user interface. A more user friendly interface may be developed for the system, such as a window based user interface. 5. Develop the other protocol entities of the OSI-RM.  Bibliography  [I]  A . Woodcock, Towards the Application of OSI Standards, Computer Networks and ISDN Systems. Vol. 14, (1987) 291 - 295.  [2]  A . S. Tanenbaum, Computer Networks, Prentic-Hall, Inc., A Division of Simon and Schuster Englewood Cliffs, New Jersey 07632, 1988.  [3]  W . Stallings, Data and Computer Communications, Macmillian Publishing Company, Inc., 1985.  [4]  I D A C O M Electronics Ltd, MPT386.2 1987.  [5]  I D A C O M Electronics Ltd, X.25 Monitor,  [6]  I D A C O M Electronics Ltd, Architecture and Design of a Portable Protocol Tester, 1989.  [7]  G . V . Bochmann, R. Dssoule, J . R. Zhao, Trace Analysis for conformance and Arbitration Testing, I E E E Transactions on Software Engineering, Vol. 15, No. 11, Nov 1989.  [8]  C C I T T Recommendation X.25, fnterface Between DTE and DCE Terminals Operating in Packet Mode, 1988.  [9]  C C I T T Recommendation X.224, Transport Protocol Specification for Open Systems fnterconnection for CCfTT Applications, 1984.  [10]  R. I. Chan, OSf PT Environment, Version 1.32, U B C - I D A C O M Project Documentation, 21 September 1988.  [II]  V. Lee, LAPB Design Manual, Version 3.00, U B C - I D A C O M Project Documentation, 20 September 1988.  53  User Manuals - Forth Programming, Nov  1987.  BIBLIOGRAPHY  54  [12] B . P. Lee, Issues On Design And Implementation Of Protocol Test Systems, M.Sc. thesis, Department of Computer Science, University of British Columbia, 1989. [13] R. J . Linn, Conformance Testing for OSf Protocols, Computer Networks and ISDN System, Vol. 18, (1989/90), p203-219.  Appendix A User Manual The current O S I - P M contains a menu driven user interface. The menu can be invoked by typing a Control-c at run time. The system stops processing and displays the following menu: M E N U 1. Display Error Record F i l e . 2. F i l t e r 3. Select Layer 4. Disable or Enable Layer 5. Change size of capture RAM 6. Save capture RAM to a f i l e 7. Read f i l e 8. Change synchronization wait time 9. quit Enter command or 'q' to go back to monitor: Descriptions of each of the items of the menu are given in the following sections.  A . l Display Error Record File The system maintains an error record file for recording all protocol violations of the communication line which is being tested. This command is used to display the file on the display screen.  55  APPENDIX  A. USER  MANUAL  56  A.2 Filter This command allows the user to select specific PDUs within each layer for display and capture. When this command is selected, the system prompts in which layer the user wants to do the filter function using the following menu: Which Layer? 2: Data Link 3: Network 4: Transport Enter number : If, for example, the network layer is selected, an additional menu for the network layer will be shown on the screen as follows: 1: + INCOMING.CALL 2: + CALL.REQUEST 3: + CALL.CONNECTED 4: + CALL.ACCEPTED 5: + CLEAR.REQUEST 6: + CLEAR.INDICATION 7: + CLEAR.CONFIRMATION 8: - DATA 9: - RECEIVER.READY 10: - RECEIVER.NOT.READY 11: - REJECT 12: + INTERRUPT.REQUEST 13: + INTERRUPT.INDICATION 14: + INTERRUPT.CONFIRMATION 15: + RESET.REQUEST 16: + RESET.INDICATION 17: + RESET.CONFIRMATION 18: + RESTART.REQUEST 19: + RESTART.INDICATION  APPENDIX  A. USER  20: + 21: + Enter or  MANUAL  57  RESTART.CONFIRMATION DIAGNOSTIC PACKET the packet number that you want to add or delete, 'q' to quit :  This menu shows all the packet names of the network layer. The sign '+' in front of a packet name means the packet is selected for display and capture, and the sign '-' means the packet is not selected. In the above example, the DATA packet and all the control flow packets are not selected.  A.3 Select Layer This function is used to add or delete layer(s) for display or capture. This gives the user flexibility to look at the decoded PDUs for all layers or any particular subset. The following menu is displayed when this function is selected. 2: - Data Link 3: + Network 4: + Transport Enter the layer number that you want to add or delete, or ' q' to quit : For the above example, data link layer is not selected. Therefore, only the information from the network and the transport layers are displayed and captured.  A.4 Disable or Enable Layer This function allows the user to shut down or turn on the FSM of any particular layer(s). The following example shows that the session, presentation and application layers are disable. 2: + Data Link  APPENDIX  A.  USER  MANUAL  58  3: + Network 4: + Transport 5: - Session 6: - Presentation 7: - A p p l i c a t i o n Enter the l a y e r number that you want to d i s a b l e or enable, or 'q' to quit :  A.5 Change size of capture R A M This function allows the user to change the size of the capture R A M . The size of the capture R A M is the amount of information to be saved into the error record file in case of error.  A.6 Save capture R A M to a file The  user may use this command to dump the information which is saved in the  capture R A M into a file for off-line or on-line processing. This command will prompt the user for the name of the file.  A.7 Read File This command allows the user to play back the information from a file.  A.8 Change synchronization wait time This command allows the user to change the waiting time for the synchronization procedure (refer to section 2.3.1).  A p p e n d i x Software  B and  H a r d w a r e  Configuration  B.l  Software  Configuration  As described in section 3.1.1, the OSI-PM uses a Synchronous Serial Driver (ZSS) to communicate with a X.25 communication line. Therefore, the driver must be installed so that the system can get to work. The procedures for installing the ZSS driver to a Sun 3/50 kernel are shown as follows: 1. Copy files zssdlc.c, zs-proto.c, zssJnterface.c, and zssJnterface.h to directory /sys/sundev. Copy file CSSD50ZSS  to directory /sys/sunS/conf.  Copy file uipc.domain.c to directory /sys/os. 2. Add the following two entries to the file /sys/conj'.common/'files.cmn sundev/zs_sdlc.c  optional ZSS  sundev/zss_interface.c  optional ZSS  59  APPENDIX  B. SOFTWARE  AND HARDWARE  CONFIGURATION  60  and delete all entries starting with netccitt. 3. Change to directory /sys/sun3/conf and run config CSSD50ZSS.  The directory  ../CS.SD50ZSS will be made if it doesn't exist. 4. Change to directory ../CSJ3D50ZSS and type make to make the new system. 5. The new kernel is stored in file vmunix. The user may copy it to the root directory ( cp vmunix / vmunix), stop the current system (/etc/halt), and boot the new system (b vmunix). Note that the user may refer to the UNIX manual for config for more details of configuring a kernel.  B.2  Hardware Configuration  After the driver is installed to the kernel, it is necessary to connect the Sun-3/50 workstation to the two terminals, the D T E and the DCE. The Sun-3/50 workstation is connected to the D T E and the D C E using a Y cable. In addition to the Y cable, the workstation requires a special cable to connect the Y cable to the two serial ports (see figure B.l). As described in section 3.1.1, the D T E is connected to the serial port B and the DCE is connected to the serial port A at the back of the workstation. Since the DCE uses the receive pin (pin #3) to send data, we may connect pin #3 of the Y cable to the receive pin (pin #3) of the serial port A. The DTE uses the send pin (pin #2) to send data and we may connect pin #2 of the Y cable to the receive pin of the serial port B. Besides the receive pin, pin #7 (ground) and pin #17 (receiver clock) are also connected from the Y cable to the serial ports as shown infigureB . l .  APPENDIX  B. SOFTWARE  AND HARDWARE  CONFIGURATION  To DTE  To DCE  25  \ pin numb  25  >2  5  ^  To special cable  To Y cable 17 7  1  1  32  Y cable special cable used to connect the Y cable to the Sun-3 workstation  pin number / \  /  \  1?  17 To Serial port A  To Serial port B  Figure B.l: Configuration of the Cables  APPENDIX  B. SOFTWARE  AND HARDWARE  CONFIGURATION  62  To connect the Sun-3 workstation to the D T E and the DCE, we first connect the D T E and the DCE using any two heads of the Y cable, and connect the third head of the Y cable to the special cable. Finally, we connect the special cable to the serial ports of the Sun-3 workstation.  A p p e n d i x G u i d e  C  for a d d i n g a n e w  entity  One of the capabilities provided by the OSI-PM is that entities (protocol layers) can easily be added and modified. A typical entity of the current OSI-PM contains the following supported routines : XXjmonitor(), and XX.filterQ.  XX-decodef), XXJnitQ,  XXjrestt(),  XX.displayQ  X X is the short form of the entity name, such as DL, PK and TP. To add  a new entity to the system, all the above routines of that entity should be implemented. The detailed implementation of these routines except the XXjmonitorQ  have been given  in section 3.4.2. As described in section 2.3.2, each entity contains a decoder and one (or more) finite state machine(s). The decoder and the FSM(s) of each entity are implemented in XX_decode() (see section 3.4.2.3), and they follow the corresponding protocol specifications. As described in section 3.4.2.1 and section 3.4.2.2, the initialization routine  XXJnitQ  of each entity calls the setEntryPoint routine to register the entity to the OSI-PM so that the OSI-PM knows the existence of that entity. setEntryPoint adds a new entity table record to the entity table. The following sections discuss the implementation of XXjmonitor and the procedure  63  APPENDIX  C. GUIDE FOR ADDING A NEW  ENTITY  64  for adding a new entity to the system.  C . l XX_monitor(host, len, cid, data) Some important global variables used in the program are described below. (Note, the word L A Y E R refers to the name of the layer such as DATAJLINK, NETWORK and TRANSPORT) • monRunning : set to FALSE if a protocol violation is detected. • selectedfLAYERJ: set to TRUE if the layer named LAYER is selected by the user for display and capture. • existfLAYERJ : set to T R U E if the layer named LAYER is implemented and the user wants to monitor and test it. XXjmonitor()  is the entry point of entity XX. Parameters passed to this routine  include the name of the host which sent the data, the length of the data, the network connection id and the data. This routine does the following: 1. Calls XX-decode() to decode the data and test the decoded PDU. 2. Calls XX_display() to display the decoded PDU if no protocol violation is detected, i.e. monRunning is set to TRUE. 3. If the P D U type of the decoded PDU is DATA and existfLAYERJ is set to TRUE (LAYER is the layer which is immediately above XX), it passes data to the entity of layer LAYER by calling entitiesTable[LAYER].entryPt() (see section 3.4.1.1 and 3.4.1.3 for more details).  APPENDIX  C. GUIDE FOR ADDING A NEW  ENTITY  65  C.2 procedures for adding a new entity The procedures for adding a new entity are as follows: 1. Implement all the supported routines described above for the new entity. 2. Add the initialization routine XXJnitf) to the main routine of the program named monitor.c. XXJnit() contains code to register the entity (see section 3.4.2.2). 3. Compile the new entity with the system and test the new entity.  

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-0051977/manifest

Comment

Related Items