- An introduction to ATM Signaling
Asynchronous Transfer Mode, or ATM for short, is a new switching technology which offers an integrated approach to data/information communication. ATM offers a connection-oriented communication channel which can be transparently used by various applications, may it be a simple file transfer or a video conferencing tool. This transparency is possible in part by having a small fixed packet size of 53 bytes(48 bytes payload, 5 bytes header), referred to as "cell" by the ATM community. Thus a packet has to be broken down into cells(called segmentation) at the sending end, and these cells have to be merged(called reassembly) at the receiving end. Normally, this segmentation and reassembly(SAR) activity is done in the hardware itself, so most drivers won't have to bother about SAR. What the driver has to bother about is, how to know the path to the destination address, and how to set up a connection with the remote end, so that the data packets may be sent on that connection. This is where signaling comes into the picture. A protocol is needed because many things are to be taken care of by the intermediate switches before a path may be set up. For example, ATM prides itself in providing a Quality of Service(QoS) guarantee. But to provide such a guarantee, you need to have a non-trivial policy for call admission control at the switches, you can't arbitrarily accept all the call requests because then you can't give the QoS guarantee. So a call setup request needs to be processed by each node. Another important consideration is routing. Connection setup has to take care of these. So we need a protocol for Signaling. Towards this end, ATM Forum has defined several signaling protocols and the process is still continuing.
Following is a brief summary of one of these, the signaling protocol at the User Network Interface(UNI).
User Network Interface Signaling
ATM Forum's signaling working group generated UNI 3.0 as the first formal protocol specification(though UNI 2.0 also exists!) for User to Network Interface Signaling. This was followed by UNI 3.1 and then recently(July 1996) with UNI 4.0. Basic concept has remained the same; main differences are in new options included, and new features offered. The UNI signaling, as the name suggests, specifies the protocol to be used between an end-system and a network switch. An end-system sends a request packet to the switch, which is appropriately processed and then forwarded over the network to reach the other host, identified by the ATM address provided in the setup request. Note that the protocol does not specify how to find the correct path, or route to the remote host(which switch to forward this request to, so that it reaches the correct end-system); this(and other such inter switch communication) is addressed in the NNI protocols, one of which is PNNI. So, in that way, UNI is a simpler protocol, still it contains many significant issues. What follows now is a small description of the protocol.
The end-system and switch communicate via a set of messages some of which are: SETUP, CALL PROCEEDING, CONNECT, CONNECT ACK, RELEASE, RELEASE COMPLETE, RESTART. Each message consists of variable length octets, called Information Elements(IE). Each IE is associated with one or more attributes of the current call. All the messages are transferred assuming that the underlying layer is reliable, so a message can't be lost. This is achieved by implementing a protocol for reliable data transfer, specified by ITU-T document Q.2110(referred to as Service Specific Connection Oriented Protocol, SSCOP), and a layer which maps its services to those required by UNI, specified by ITU-T document Q.2130( referred to as Service Specific Convergence Function, SSCF).For a discussion on SSCOP and SSCF, click here.
Each call setup message is identified by a Call Reference Value(CRV) (which identifies a call uniquely at the end which allocated this number), and a DIRection bit(which identifies who allocated this CRV, user or network). There is a length field also, specifying the length of the message, and a Protocol Discriminator field, identifying the protocol being referred('00001001' for UNI ).Whenever a user wants to set up a connection with another host, it generates a SETUP message and sends it to the network. This message contains, among other things, the called party address, QoS class desired and Traffic type expected. Other IEs include: High/Low Layer Information(identifying the user on the remote system), Adaptation Layer parameter, Broadband Bearer Capability, Endpoint Reference(used in case of Point-to-Multipoint Calls). When the network receives the SETUP message, it checks whether it can support the specified attributes(QoS, Traffic, AAL etc), and if it can, forwards the message. The switch may optionally send a CALL PROCEEDING message to the originating user, which effectively says to the user side that your request has been forwarded, so wait patiently for some time!
The other end receives the SETUP message from the network, which contains, among other IEs, the IEs the originating user sent + a Connection Identifier IE containing the VPI and VCI allocated by the network. This will be the data channel if the host accepts the call. The decision of accepting or rejecting the call depends on three things: whether the host can support the QoS, AAL etc, whether the host can support the VPI/VCI allocated by the network and whether there is any user that conforms to the High/Low Layer Information IEs. If the remote end accepts the call, it responds with a CONNECT message. The network responds with a CONNECT ACK .This CONNECT message is forwarded by the network on the back path all the way to the originating host. The originating host gets its Connection Identifier IE in this CONNECT message(or in a previous CALL PROCEEDING message, if it was sent by the network). A call becomes active for a host(i.e. data can be sent over the channel) as soon as it receives a CONNECT or a CONNECT_ACK(it can't receive both for a call!). Note that this means the remote end gets active first since it receives the CONNECT_ACK from its neighboring switch, while the originating end receives the CONNECT message only after the message has traversed the whole network. So a remote end may start sending data before the originating end is ready for it! But this is not a problem since the data has to traverse the same path as the CONNECT message, so the originating host will receive data only after it receives CONNECT message(problem would have occured if Signaling Path was different from Data Path! ). At any stage, any entity can send a RELEASE to indicate that it wants to release the connection(or doesn't want to set up the connection at all!). A RELEASE message contains the CAUSE value, which identifies the reason for sending the RELEASE message. The RELEASE message is responded to by RELEASE_COMPLETE message. Both these messages contain the CRV to identify the connection to be released. Apart from these normal messages, there are other messages that are part of the UNI protocol specification. A RESTART message is sent to to indicate to the other end that it may release the resources allocated to the specified connection. A RESTART message is responded to by a RESTART ACK message. Typically, a RESTART message is sent by a switch to the host at the start as the first message which asks the host to release all its resources. A STATUS ENQUIRY message may be sent by any side whenever it detects a (hopefully recoverable!) protocol error that is not severe(actual case where a STATUS ENQUIRY message may be sent is specified by the specification). In this case, the other end responds with a STATUS message indicating its protocol state, failing which a RELEASE may be sent.
This is a very brief and somewhat incomplete description of the UNI protocol. Interest reader is encouraged to go through the ATM Forum's specification for UNI 3.1(postscript as well as pdf format).
Back To the ATM Home Page