ATM UNI 3.1 Signalling Protocol

NOTE: security settings may prevent the applet from running properly, especially if you are behind a firewall


Note: the applet can take a while to load, especially over a low speed modem connection. Wouldn't it be nice to have a high-speed ATM connection straight to your computer? :-)

The above applet animates/demonstrates the behaviour of a nearly complete personal UNI 3.1 signalling package (written entirely in Java) that I've been working on in my spare time. "UNI 3.1 Signalling" refers to the signalling portion of the ATM Forum's "ATM User-Network Interface Specification, Version 3.1"; the specification is publically available at the following site: ftp.atmforum.com/pub/UNI/ver3.1. The UNI protocol (as its name implies :-) ) is concerned with only the User-to-Network interface; Network-to-Network interfaces are the subject of yet another protocol.

For those more familiar with ISDN, the signalling protocol is roughly analogous to Q.931, and depends upon a lower layer called SAAL (composed of SSCF and SSCOP) for reliable transport of the signalling messages, much as Q.931 depends on Q.921.

For those unfamiliar with signalling, the protocol defines a vocabulary of messages and agreed-upon procedures which allow an endpoint to request that the network dynamically set-up [and tear-down] communication connections with specified characteristics (e.g., bandwidth and "quality-of-service" desired) to specified destinations.

The Applet above is broken into three main sections:


The names for the endpoints will be familiar to any fans of the British comedy show, "Are You Being Served?" :-)

Press the buttons to help step Captain Peacock through two scenarios:

[These two scenarios were simply picked for their illustrative value]

As the calls progress through establishment and tear-down, the screen to the right of the control area will illustrate the UNI 3.1 messages being sent and received from the endpoints and the "ATM Network Cloud" (which represents an arbitrary number of switches).

In addition to the message animation, the bottom section shows four screens which emulate a protocol analyzer attached to each line, displaying both the raw hex values and parsed/interpreted meanings of the messages as they flow across the labeled lines. The text areas retain the information for a particular session (point-to-point or point-to-multipoint) until a new one is started. Perusing their contents will help one understand the protocol in more detail. Reading the spec is also a good idea :-)





Click here for a link to my latest venture.

Back to Dave's home Fun Stuff Useful/Serious Stuff




Copyright 1996 d.j.hudek all rights reserved