A Simulation Model for the Operation and Maintenance Functionality in ATM Switches
† Alexa Doboli*, Jonas Hallberg , Petru Eles*
† Dept. of Computer and Information Science Linköping University S-581 83 Linköping, SWEDEN Tel: +46 13 281427 Fax: +46 13 282666 Email:
[email protected]
*Computer Science and Engineering Dept. Technical University of Timisoara Timisoara, ROMANIA Tel: + 40 54 112330 Fax: +40 56 192049 Email:
[email protected] [email protected]
Abstract
The paper presents a VHDL simulation model for the F4/F5 block of the ATM protocol, covering the block functionality as specified by standard references. The model consists of several processes, each implementing a relatively independent part of the block functionality. The model handles multiple virtual path and virtual channel connections passing through the block. The management of ATM cells depends on the current “status” of the virtual path or virtual channels, and thus local tables are used for recording the global state of the block. For testing purposes we implemented a test bench providing the working environment of the F4/F5 block module and allowing automatic verification of the block functionality. By developing this VHDL model we produced a readable and at the same time executable specification of the F4/F5 functionality, according to the complex standard references. Thus we showed that VHDL can serve as a specification language for complex systems, regardless if they are intended to be implemented in hardware, software or both.
-1-
1. Introduction The development of the Asynchronous Transfer Mode (ATM) protocol [Pr91] was inspired by the idea of setting a standard for a worldwide telecommunication network, able to transfer not only audio, but also video and other data that require high bandwidth. The chosen technology happened to be suitable for building high-speed local area networks as well. ATM is also the primary candidate technology for bringing multimedia computation to the client-server paradigm. Increasing data rates make it more and more difficult to route on a per packet switch and ATM is one possible solution to this problem. Finally what will make ATM to be successful in the market is a dramatic drop in the prices. One of the basic ideas with ATM is that all signalling will be sent on the same physical carriers as the user data. To handle this there is a need for special units, which introduce and extract this information, in the nodes of the network. The F4/F5 block covers the Operation and Maintenance (OAM) functionality of the ATM switches as specified in [Be93]. Both university groups and industry are currently working on the development of hardware and software components to support parts of the ATM protocol. An important step in this design process is the development of adequate simulation models. In this paper a simulation model for the F4/F5 block is presented. The paper is divided into 6 sections. Section 2 is focused on the basic principles of ATM. Section 3 deals with the main functionality of the F4/F5 block and section 4 presents the main principles taken into consideration when developing the model. In section 5 we concentrate on some important implementation decisions, in testing and evaluation of the model. Finally in section 6 some conclusions are drawn.
2. Basic principles of ATM The basic characteristics of the ATM protocol can be summarized as in [Pr91]: • ATM is based on fixed length cells (53 bytes), which include a header (5 bytes) and information fields (48 bytes). The header contains explicit routing informations and as a result cells belonging to different channels can be transmitted along a link in an arbitrary order. In fact the cell header containing routing information is the main point of distinction between ATM and STM (Synchronous Transfer Mode). • ATM is connection-oriented. An ATM connection has to be setup before user information is transferred and remains unchanged for the complete duration of the transmission. When the transfer phase is finished the allocated resources are released. • The information field of the ATM cell is transported transparently through the network, in the sense that no processing is performed on it inside the network, e.g. error control. An ATM switch can be schematically depicted as in figure 1. A number of n incoming links (I1, I2,... In) transport cells to the ATM switch, where depending on the header each cell is switched to an outgoing link (O1, O2,... Oq). The incoming header and the incoming link number are used to access a translation table for the identification of the outgoing link and the generation of a new header value. The header functionality is reduced and this guarantees a high processing speed of input cells. The information fields are also small, and hence the internal buffers are reduced and the queueing -2-
delay is limited to small values.
x
y Ii
Oo Outgoing Headers
Incoming Headers Header/link Translation Table Translation table Input link Ii
Header
Output link
Header
Oo
y
x
Figure 1: The ATM switching principle
Before any user information can be sent through the network, connections have to be set up between the users. Two different types of connections are used: Virtual Path Connections (VPC) and Virtual Channel Connections (VCC). VPCs are identified by using a Virtual Path Identifier (VPI), while a Virtual Channel Identifier (VCI) is used to distinguish between different VCCs. VCCs are the basic mean for establishing a connection between two points. If several VCCs are established between the same physical points then they can be grouped together into a VPC, as illustrated in figure 2. Each physical link is able to carry several VPCs. The main reason for introducing VPCs is the possibility to increase the number of VCCs routed through the nodes in the network. In a general case an ATM switch should support both virtual path and virtual channel service, i.e. depending on the VPI the switching is performed on only the VPI or on both the VPI and the VCI. If virtual path service is performed on the current VPI, then the VCIs are forwarded transparently through the switch.
-3-
VCC VPC Physical Link
VCC VPC
Figure 2: The relationship between VCC, VPC and physical link.
A VCC consists of one or more VC links. A VC link may consist of a VP connection, which consists of one or more VP links (figure 3). Links, VC or VP, can be grouped into connection segments.
VCC
VC link
VC link
VC link
VP link
VP link
VP link
VPC Figure 3: The relationship between VC and VP links.
The ATM cell (figure 4) consists of a header of 5 bytes and a payload of 48 bytes. The header contains the following information: • The Generic Flow Control, GFC, field allows multiple terminals, users, to be connected to -4-
the same physical link. • The Virtual Path Identifier (VPI) field is used to determine which virtual path the cell belongs to. • The Virtual Connection Identifier (VCI) field is used to determine which virtual channel the cell belongs to. In each virtual path there are virtual channels reserved for transmission of OAM cells and Management system signalling. • The Payload Type Identifier (PTI) field is used to identify OAM cells that use the same channels as the user cells. • The Cell Loss Priority (CLP) is used when it is necessary to discard cells. A cell with the CLP set will be discarded prior to those cells where the CLP is not set. • The Header Error Control (HEC) field is used to implement a BCH (Bose-Chadhu-Hocquenghem) code, which protects the header.
Header (5 bytes)
Payload (48 bytes)
Byte 1:
GFC (4 bits)
VPI (4 bits)
Byte 2:
VPI (4 bits)
VCI (4 bits) VCI (8 bits)
Byte 3: Byte 4:
VCI (4 bits)
PTI (3 bits) HEC (8 bits)
Byte 5:
Figure 4: The structure of the ATM cell.
As stated in [LaLjRo93] the ATM switch functionality covers: • VPI/VCI translation • Adding of routing informations to the cells • Discarding of cells with an invalid VPI/VCI • Coping with variations in the asynchronous cell flows • Connection Handling -5-
CLP (1 bit)
• Configuration Management • Fault Management • Performance Management • Charging Management • Security Management • System Functions
3. The F4/F5 block The name of the F4/F5 block refers to the levels of OAM functionality that the block covers. The F4 level handles the OAM functionality concerning VPs and the F5 level handles the OAM functionality concerning VCs. The levels F1 to F3 handle OAM functionality at the physical layer of the protocol. The F4/F5 block, as specified in [Be93], has the following main functionality: • Fault management: when the appearance of a fault is reported to the F4/F5, special OAM cells will be generated and sent on all affected connections; if the fault persist, the management system should be notified. • Performance monitoring: normal functioning of the network is monitored by continuous or periodic checking of the transmission of cells. • Fault localization: when a fault occurs it might be necessary to localize it further. For this purpose special loop back OAM cells are used. • Activation/deactivation: a special protocol for activation and deactivation of OAM functions that require active participation of several F4/F5 blocks, e.g. performance monitoring, has to be implemented. An F4/F5 block is present on each physical link connected to the ATM switch (figure 5). Since all connections are bidirectional, the F4/F5 block has two inputs and two outputs. To perform its functions, the F4/F5 block deals with specially marked ATM cells. These cells are referred to as OAM (Operations and Maintenance) cells and are distinguished from user cells by dedicated values for the VCI (the F4 level) respectively the PTI (the F5 level). Three types of OAM cells have been defined by the ATM standard: i. Activation/Deactivation cells are used for activating and deactivating the OAM cell generation and processing functions associated with certain VPC/VCC management capabilities. Activation/Deactivation cells are sent as result of a request from the Management System. ii. Performance Management (PM) cells are transmitted regularly between end-points of selected virtual connections or connection segments and are used to monitor the performance of a connection or a connection segment. A PM cell contains information about user cells travelling on that VP/VC connection. PM cells are used for computing two values: a. The difference between the number of received user information cells and the number of transmitted user information cells. b. The number of mismatches between the locally calculated block error detection codes and the corresponding error code saved in the cell. -6-
Input1
Input2
Output2
F4/F5 Output1
Output1
F4/F5 Input2
F4/F5
Input1
Output2
Translation Table
F4/F5
ATM switch
Figure 5: The location of F4/F5 block in the ATM switch.
This values are mainly used for: a. Verification of the Quality of Service, so as to monitor VP/VC compliance with service objectives. b. Diagnosis/analysis of VP/VC problems. iii.Fault Management cells are transmitted to indicate fault conditions, e.g. discontinuity of the virtual path or channel.These cells are also used to perform tests on virtual paths or connection segments, e.g. those being part of a trouble isolation procedure. The node detecting a defect sends OAM cells in order to allert downstream nodes that a defect has been detected upstream. As a response to a request from the Management System, special OAM cells are sent to verify the existence of connectivity for a particular connection.
-7-
4. Development of the F4/F5 simulation model When deciding on the model for the F4/F5 block (figure 6) the following arguments have been considered: • The F4/F5 block generates output cells as a result of input (ATM cells, signals from the Management System or the Physical Layer) or as a consequence of being in a certain state, e.g. the AIS state, in which it has to generate cells at fixed time intervals. The generation of Performance Monitoring and Activation/Deactivation cells together with the generation of response signals to the Management System can be considered as a result of incoming information. Also the alteration of the state of the F4/F5 (e.g. from normal to AIS state) is a consequence of the input. Fault Management cells on the other hand are generated periodically when the node is in a specific state. Thus it seems natural to provide two distinct processes in the model: one handling the generation of output cells and signals depending on input and a second taking care of the generation of cells depending on the current state. In figure 6 the process InputHandler is the one dealing with input, while the process FMCellGenerator will generate output cells depending on the current state of the F4/F5 block. • Buffering on each output stream is controlled by a distinct process, which additionally takes care of the cell priorities. As stated in the specifications [Be93] cells have three different priorities: a. The highest priority is given to Fault Management and Activation/Deactivation cells. b. The medium priority belongs to the user cells. c. The lowest priority is given to the Performance Monitoring cells. These cells are usually delayed as long as there are any other cells to be sent. To keep this delay below a certain limit, stated by the ATM standard, they may occasionally have to be forced into the cell stream. • Since several VPCs and VCCs are passing through a F4/F5 block and the management of a cell depends on the current status of the VPC or VCC to which it belongs each F4/F5 block has to keep evidence of the state associated with the channels and paths routed through the block. This is solved by using tables local to process Input Handler respectively FMCellGenerator (figure 6). • The external interface of the F4/F5 block supports channels for input and output cells, signals from the physical layer, but also signals from and to the Management System. In our model this interface is represented by the following ports: Input1 (figure 6) is supposed to carry the cells arriving to the switch from the outside world, while Input2 should be connected to a switch port of the current switch; Output1 is supposed to be connected to the outside world while Output2 should be connected to a switch port of the current switch. The Signal from Physical Layer port receives alarm signals on appearance and disappearance of faults on a specific VP. The Signal to Management System port is used by the F4/F5 node to report the result of services requested by the Management System through the Signal from Management System port.
-8-
The Signal for Reporting port is used to report the result of performance monitoring requested by the Management System. Through the Signal from Management System port the Management System sends information about newly routed connections, performance monitoring and loop back tests to the F4/F5 block. The main functionality of the F4/F5 node is covered by process Input Handler. When receiving an error signal from the Physical Layer, the error state is set to the corresponding path. In this state, process FMCellGenerator creates specific cells (AIS and RDI cells), until the error from the Physical Level is removed. Removing the error is indicated by the OK signal received from the Physical Layer. In this case the error state is exited and the node tries to recover the state existing before the error occurred. If a signal from the timer process is received, Input Handler will check for each virtual path/channel if a time dependent action has to be performed (e.g. exit an error state). If a signal from the Management System is received, depending on the signal type (loop back, activation, deactivation request), specific output cells are generated for satisfying the request. If an input cell is received, depending on the nature of the cell, specific actions are executed. User cells are simply passed through the node. A received Fault Management cell (AIS or RDI cell), indicates an error on a path/channel. If an end node gets an AIS cell, it enters an error state and RDI cells are sent backwards. Loop back cells are looped back at connection and segment end nodes and as a result of receiving such a cell by the generating node, a special cell is sent to the Management System to indicate that loop back has been successful. If the F4/F5 node receives an activation/deactivation request cell, it verifies if the request is supported by the node. If possible the corresponding state is entered by the node for the specific virtual path/channel and Performance Monitoring cells are sent to the output. If not supported, a special cell is sent to the Management System indicating that the request has been denied. If performance monitoring is executed on a virtual path/channel, the corresponding input cells are identified in order to compute the requested statistics. Performance Monitoring cells are used by monitoring nodes to report statistical information to the Management System and are needed for maintaining a proper functionality of the network. In the next paragraph a VHDL based pseudocode is presented, which details the main functionality of the F4/F5 node.
-9-
Input Handler: PROCESS WAIT ON Signal from Physical Layer, Signal from timer, Signal from Management System, Input cell; IF (Input Handler receives Signal from Physical Layer) THEN IF (Signal from Physical Layer is OK) THEN * remove the node from the error state and recover the state existing before the error appeared; ELSE * the node enters the error state and a signal is sent to FMCellGenerator for generating AIS cells; END IF END IF; IF ( Input_Handler receives a signal from timer ) THEN FOR all path/channels LOOP IF ( a time dependent action should be executed )THEN * the node exits the current state, enters the previous one and a signal is sent to the Management System indicating that the current state has been changed; END IF; END LOOP; END IF; IF ( Input Handler receives a signal from the Management System ) THEN IF ( Loop back Request ) THEN * the node enters the loop back state and a signal is sent to FMCellGenerator for generating loop back cells; ELSIF ( Activation/Deactivation Request ) THEN IF ( Activation/Deactivation on path/channel is possible ) THEN * node enters the activation/deactivation state and a Activation/Deactivation Request cell is sent to output; ELSE * a signal is sent to the Management System indicating the denying of the request; END IF; END IF; END IF; IF (Input Handler receives an input cell) THEN CASE input cell type IS WHEN AIS cell => IF (node is a connection end node) THEN IF (node is not in error state) THEN * the node enters the error state and a signal is sent to FMCellGenerator for generating RDI cells; END IF; ELSE * send the input cell to output; END IF; WHEN RDI cell => IF (node is a connection end node) AND (node is not in error state) THEN * the node enters the error state; END IF; IF (NOT connection end node) THEN * send the input cell to output; END IF; WHEN Loop back cell => IF (node is a connection end node) OR (node is a segment end node) AND (segment loop back cell ) THEN IF (the cell was not loop back) THEN * the cell is looped back and sent to output;
- 10 -
ELSE * the node exits the loop back state and a signal is sent to the Management System indicating that loop back was successful; END IF; ELSE * the input cell is sent to output; END IF; WHEN Activation Request cell => IF (node is a segment end node) OR (node is a connection end node) THEN IF (activation is possible) THEN * an Activation Request Confirmed cell is sent to output; ELSE * an Activation Request Denied cell is sent to output; END IF; ELSE * the input cell is sent to output; END IF; WHEN Activation/ Deactivation Request Denied cell => IF ( node is a segment end node ) OR ( node is a connection end node) THEN * a signal is sent to the Management System indicating that activation/ deactivation was not possible; ELSE * the input cell is sent to output; END IF; WHEN Activation Request Confirmed cell => IF (node is a segment end node) OR (node is a connection end node) THEN * start Performance Monitoring on virtual path/ channel by sending a Performance Monitoring cell to output; ELSE * the input cell is sent to output; END IF; WHEN Deactivate Request cell => IF (node is a segment end node) OR (node is a connection end node) THEN IF (deactivation is possible) THEN * the node exits the Performance Monitoring state, enters the previous one and a Deactivation Request Confirmed cell is sent to output; ELSE * a Deactivation Request Denied cell is sent to output; END IF; ELSE * the input cell is sent to output; END IF; WHEN Deactivation Request Confirmed cell => IF (node is a segment end node) OR (node is a connection end node) THEN * the node exits the Performance Monitoring state, enters the previous one and a signal is sent to the Management System indicating stopping of Performance Monitoring; ELSE IF (monitoring node) THEN * a signal is sent to the Management System indicating ending the monitoring on the virtual path/channel; ELSE * the input cell is sent to output; END IF; END IF;
- 11 -
WHEN Performance Monitoring cell => IF (node is a segment end node) OR (node is a connection end node) THEN IF (Forward Monitoring cell) THEN IF (node not in Performance Monitoring state) THEN * the node enters the Performance Monitoring state; END IF; * create a Backward Monitoring response cell; ELSE -- Backward Reporting cells are destroyed END IF; ELSE IF ((Backward Monitoring cell) OR (Monitoring Reporting cell)) AND (monitoring node) THEN * save statistical informations in the data base; END IF; * the input cell is sent to output; END IF; WHEN User cell => IF (node is in Performance Monitoring state) THEN * count the number of cells and compute the correspondent error code; IF (1024 user cells were received) THEN * generate a Performance Monitoring cell and send it to output; * the input cell is sent to output; END IF; ELSIF (node is terminating Performance Monitoring cells) THEN * count the number of cells and compute the correspondent error code; ELSIF (node is in error state) THEN * the node exits the error state, enters the previous one and a message is send to FMCellGenerator for stopping Fault Management cell generation; END IF; END CASE; END PROCESS;
FMCellGenerator: PROCESS WAIT ON Signal from timer, InputHandler; IF (FMCellGenerator receives a signal from timer) THEN FOR node being in a state executing a time dependent action LOOP IF (the allocated time interval has been exhausted) THEN * generate an output cell depending on the current state of the node; END IF; END LOOP; END IF; IF (FMCellGenerator receives a signal from InputHandler) THEN * the information sent between InputHandler and FMCellGenerator is used to enter a new state; END IF; END PROCESS;
Process timer generates signals to InputHandler and FMCellGenerator at regular time intervals. The processes handling output cells are managing the two output buffers. The processes
- 12 -
Input1
Input2 Timer
Signal from Physical Layer
Signal to Management System
InputHandler: Detection and analysis of OAM cells.
FMCellGenerator: Generation of new FM OAM cells.
Internal table
Internal table
Signal from Management System
Signal for Reporting ATM cell flow
Process handling output cells
Process handling output cells
Signal Output1
Output2
Figure 6: The structure of the F4/ F5 model receive cells from both InputHandler and FMCellGenerator and place them in a FIFO order. Depending on their priority, cells are selected from the buffers and sent to output.
5. Implementation and testing of the model The model is implemented in VHDL and has been simulated on SUN SPARC ELC workstations using the MINT 2.5 VHDL simulator [Sy93]. The source code implementing the functionality of the model is approximately 1600 lines, while the test bench (figure 7) is about 1400 lines of code.
- 13 -
Result 1
Clock expected output cell
Receiver 1
Sender 1
input cell
output cell
expected output cell
expected output cell
F4/F5 Node
output cell
input cell
Sender 2
expected output cell
Receiver 2
Result 2
Type of cell to be generated
Type of cells to be generated Controller
Figure 7: The structure of the test bench.
The main principle of the test bench [Sv94] is to generate different types of cells at the input of the F4/F5 block and to compare the output cells produced by the F4/F5 block with the correct cells expected accordingly to the ATM functionality. The controller starts the generation of a given type of cell, by sending special signals to the two senders. Depending on the signal received from the controller, the senders generate OAM or user cells, which are sent to the respective input of the F4/F5 node, but also the correct expected output - 14 -
cells, which are sent to the receivers. Depending on the received input cell the F4/F5 node generates output cells, which are also sent to the receivers. The receivers get cells both from F4/F5 node and from the senders, compare these cells, and depending on the result, output signals are generated. This approach produces a practically automatic testing of the model functionality. Thus it allows the generation of a large number of test cases and the verification of a large amount of resulted data.
6. Conclusions In this paper some main aspects concerning the functionality of the F4/F5 block belonging to an ATM switch are presented and a simulation model of the block is described. For testing purposes the model has been embedded in a test bench providing the working environment of the F4/F5 block and allowing automatic verification of its functionality. By developing this VHDL model we produced a readable and at the same time executable specification of the F4/F5 functionality, according to the very complex standard reference [Be93]. Thus we showed that VHDL can serve as a specification language for complex systems, regardless if they are intended to be implemented in software, hardware or both. The model we have developed is not only used as a documentation and reference but also (with some possible changes) as an input specification to our system level design tools for high-level synthesis and hardware/software codesign. Our experiments with automatic synthesis of the F4/F5 block are in progress now.
References [Be93] Bellcore, Generic Requirements for Operations of Broadband Switching Systems, TANWT-001248 issue 2, October 1993 [LaLjRo93] Larsson M., Ljungberg M., Rooth J., The ATM Switch Concept and the ATM Pipe Switch, Ericsson Review, No.1, 1993 [Pr91] de Prycker M., Asynchronous Transfer Mode, Ellis Horwood, 1991 [RoChGa94] Rooholamini R., Cherkassy V., Garver M., Finding the Right ATM Switch for the Market, Computer, April 1994 [StVe93]Staxen P., Vestin C., The Telecom Evolution in the Broadband Era, Ericsson Review, No.1, 1993 [Sv94] Svantesson B., A Test Bench for the F4/F5 block of the ATM Protocol, Master Thesis, Royal Technical University Stockholm, 1994 [Sy93] Synthesia, The SYNT/MINT VHDL Design System, Doc. No: SYNTHESIA 93 011 A, 1993
- 15 -
