The benefits of asynchronous transfer mode (ATM) are many. But like any new technology, the obstacles can also be many when you are implementing the required protocols.
ATM signaling is a high-level protocol specified in the ATM Forum User Network Interface 3.0 and later releases. It allows ATM connections to be dynamically set up and cleared. More simply stated, an ATM network without signaling capabilities is like a phone system without dial-up lines.
The Importance of Signaling
In a typical ATM network, several users (end-points) are connected to a network device (switch) in a star configuration. When two ATM end-points wish to transfer information, a virtual connection (VC) has to be created.
Once a connection is established, each user receives a virtual path index (VPI) and a virtual channel index (VCI) which together make up the connection identifier. These VPIs and VCIs appear in the header of every cell sent to the desired destination.
A connection can be specified as point-to-point (establishing a bidirectional link between two users) or as point-to-multipoint (where one root user sends information to multiple leaf users). Without signaling, VPIs and VCIs must be allocated manually. With signaling, the VC can be created and deleted on the fly using parameters negotiated between the end-stations, such as bandwidth or desired quality of service.
Signaling exists in every element of the ATM network. The capability to create and destroy connections on the fly is essential to ATM applications. For example, LAN emulation, which allows an ATM network to integrate with an existing LAN and run a LAN application unchanged over an ATM backbone, uses signaling to create links between ATM users, servers and other network entities.
ATM Forum signaling is based on several International Telecommunication Union (ITU) documents which, in turn, are based on ITU-T Q.931 ISDN signaling (Figure 1).
The Q.2931 document issued by the ITU Telecommunications Standardization Sector (formerly CCITT) specifies the format and context of signaling messages. Signaling messages are sent using the signaling ATM adaptation layer (SAAL) which assures reliable end-to-end message delivery over the ATM adaptation layer 5 using a predefined signaling channel (VPI=0, VCI=5).
A signaling message is made up of a message header and a variable number of building blocks called information elements (IEs). IEs carry information like the ATM address of the called and calling station, the required quality of service parameters or the cause for termination of the connection.
Depending on the message, some IEs are mandatory and some are optional. Many parameters are required to set up a signaling connection, and even more will be added in forthcoming releases of the signaling protocol specifications.
Since the majority of ATM users will use signaling, the importance of reliable signaling implementation in the network should not be underestimated. To achieve reliable code, a good signaling testing system must be utilized.
Protocol Conformance Tests
Signaling testing should first test the normal behavior of the signaling protocol. In most cases, normal connection setup and teardown will be the part most exercised by real users.
To test the normal operation, the tests should create both point-to-point (one-to-one) and point-to-multipoint (one-to-many) connections with the equipment-under-test. If a switch is being tested, the testbed should emulate several ATM end-stations that can connect through the switch.
If the unit-under-test is a network interface card, the ideal test scenario would simulate a switch and several other network interface cards. The developer will want to select different connection parameters for each connection and test normal connection teardown analogous to politely ending a phone conversation.
Test equipment must simultaneously emulate all layers of the signaling stack. This includes Q.2931, Q.SAAL and the interim local management interface (ILMI).
Q.SAAL, the underlying protocol layer, is responsible for creating a data link among peer signaling stacks. It is active even when no connections are requested. Consequently, the analyzer should provide the connection creation services on top of a Q.SAAL simulator.
ATM stations have addresses similar to phone numbers. These addresses are usually registered in the switch either manually or by means of ILMI, the ATM management protocol also used for address registration. This mechanism must be tested under normal operation. Without it, a switch will not be aware of the users connected at each point.
Exception Handling
Testing of normal signaling behavior does not necessarily mandate test equipment. Developers can connect their product to other ATM equipment to test conformance and interoperability at the same time. However, it is simpler and faster to debug signaling with a test device, and the real benefit of using such a signaling tester becomes apparent when exception handling is being tested (Figure 2).
There are many exception and error handling cases which must be correctly dealt with by any signaling implementation. Some, such as unavailable bandwidth, may occur even between two perfectly compliant signaling machines; others, such as out-of-context messages, are usually the result of a shortcoming on either side.
Error conditions cover the entire protocol stack, from the physical layer (insufficient signal levels) to the upper Q.2931 layer. Some common conditions are:
o Link Termination–During normal operation, cables may be disconnected and stations may become active or inactive. The signaling implementation must correctly terminate and initialize such a physical and logical link.
o Parameter Validation–Parameters in each signaling message must be verified with the allowed range.
o Bad Messages–Many cases of bad messages such as a bad message header, missing or duplicate information elements or an unrecognized message type, should be rejected by the signaling code.
o Out-of-Context Messages–Sometimes, a perfectly formatted message may appear outside the normal conversation context. For example, a CONNECT message should come only after a SETUP or an ADD PARTY message, and cannot come in other circumstances.
o Time Out–The signaling standard defines several timers. For example, response messages must only come within the time limits specified by these timers. A perfectly formatted message in the proper context but outside the allotted time window is also invalid.
o Dropped Messages–These are good simulations of lower-level failures. Since the Q.SAAL layer should recover from message-drop by retransmission, it is useful to test either a single message loss or a repetitive message loss.
Intelligent analyzers with signaling simulation are capable of injecting errors into the protocol and reporting protocol errors (bad messages, out-of-context messages or time outs) to the developer. This is a very helpful feature because the developer can connect partially debugged code into the analyzer and use these error-reporting capabilities to quickly isolate code problems.
Performance and Load Testing
Once proper operation has been established, performance comes into play. Signaling performance and operation under load is a software efficiency measure. Some software bugs can be found only when creating many calls simultaneously. If, for example, many SETUP messages are pending without a reply, a software stack overflow may occur.
Among parameters that are usually tested are the number of simultaneous connections that can be created, the connection setup and teardown times, and the capability of the software to handle calls coming in on multiple ports simultaneously.
Signaling Testing Strategy
Not all aspects of the signaling protocol should be tested at once. Here are the suggested incremental testing steps:
Test a single point-to-point connection with no protocol errors.
Test several point-to-point connections with no protocol errors.
Add address registration.
Test one and then several point-to-multipoint connections.
Perform load testing using a random mix of point-to-point and point-to-multipoint connections.
Test point-to-point connections with protocol error injection.
Test point-to-multipoint connections with protocol errors.
Perform a complete simulation, including the type of calls, random load generation and error injection, over an extended period of time (Figure 3).
Summary
ATM signaling is the first major ATM-specific protocol. Testing an ATM signaling implementation can be long and tedious unless proper test equipment and test methodologies are employed. These tools can increase the reliability of signaling implementation and reduce the time-to-market for new ATM products.
About the Author
Yuval S. Boger, M.Sc., is the Product Manager for ATM protocol analyzers at RADCOM Equipment. He has more than 10 years of experience developing test equipment and managing technical development. RADCOM Equipment Inc., 900 Corporate Dr., Mahwah, NJ 07430, (201) 529-2020.
communications test
instrumentation
Copyright 1995 Nelson Publishing Inc.
August 1995
|
|