Signalling with the x-ATM Protocol Toolkit See-Mong Tan
Roy H. Campbell
Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Spring eld Urbana, IL 61801 fstan,
[email protected] May 26, 1995 Abstract
x-ATM is a portable toolkit of Asynchronous Transfer Mode (ATM) protocols implemented in a general purpose communications kernel (the x-kernel). The toolkit provides an environment for experimentation with ATM adaptation layers, interoperable ATM signalling, IP over ATM, and real time transport protocols. The x-kernel permits easy composability and promotes protocol modularity, thus x-ATM protocol modules may be arbitrarily layered on top of anchor protocols that represent di erent hardware devices. This supports x-ATM's protocol suite portability across many di erent platforms. The Unix[21] version of the toolkit currently has hardware support for Fore Systems SBA-100 host adapters, ASX-100 ATM switch and Fore ATM API, as well as the iPoint[16] experimental ATM switch, with support for other hardware platforms planned. The toolkit may be used to implement ATM signalling entities used in ATM switch controllers and hosts with ATM adapters. In our experience, x-ATM has proven to be a exible tool in our implementation of switch controllers and interoperable signalling protocols for these platforms.
1 Introduction
In this paper, we describe a portable Asynchronous Transfer Mode (ATM) protocol toolkit. The x-ATM toolkit is a cooperating set of protocol modules developed within a general purpose communications kernel (x-kernel[11]). In particular, we show how the toolkit may be con gured with ATM signalling protocols and thus used as an ATM switch controller. In our experience, x-ATM has proven to be a
exible tool in our implementation of portable switch controllers and interoperable signalling protocols for several ATM switches. The x-ATM toolkit provides implementations of: ATM adaptation layers { AAL0 | simple segmentation and reassembly only { AAL3/4 | connection-oriented and connectionless trac { AAL5 | data trac over ATM ATM signalling { SPANS | Fore Systems' Simple Protocol for ATM Network Signalling[7], { GULP { XUNET's Generic Universal Line Protocol[25] for signalling messages on the XUNET[8] network testbed. { SIG | an abstract linear signalling protocol Work is in progress on the Q.2931[2] signalling standard. This
work is supported by NSF Engineering Research Center Grant ECD89-43166.
1
IP over ATM
{ Multiprotocol encapsulation over AAL5[9] { ATM ARP[13]
RTP[22, 14] | although not speci cally targeted for ATM, RTP complements the other protocols
by providing a mechanism for the transport of real time data. The x-kernel will run as a user process within the Unix[21] operating system, or embedded as the network protocol subsystem of operating systems such as Mach[20] or the Choices [6, 5] object-oriented operating system[15]. Within the Unix version, the protocol suite includes support for several commercial and experimental ATM switches and host ATM adapter boards. This is provided for by encapsulating the devices in anchor protocols that provide an x-kernel interface to higher level protocols. The currently available anchor protocols include those for: Fore Systems' ASX-100 ATM switch Fore Systems' SBA-100 host boards Fore Systems' ATM API iPoint[16, 19] experimental ATM switch Work is in progress to support the XUNET experimental wide area ATM switch, and the 200 series of switches and host adapter boards from Fore Systems. In section 2, we present an overview of the structure of the x-kernel. In section 3, we describe the x-ATM software structure and sections 3.1, 3.2, 3.3 and 3.4 describe in more detail the various modules in the protocol toolkit. We consider ATM signalling and its implementation in x-ATM in section 4. Related work is presented in section 5 and we conclude in section 6.
2
x-kernel
We brie y describe the x-kernel in this section. The x-kernel is an embeddable network protocol framework developed at the University of Arizona. The x-kernel framework de nes the interfaces between di erent protocol layers. This approach insulates each protocol from the peculiarities of the hardware or software environment it which it is embedded. In addition, it includes a set of libraries that facilitate protocol development, including a tree-structured message library for creating and manipulating messages, a synchronization library providing semaphores and an event library providing threads and timers. Protocols are represented as instances of protocol objects. A protocol graph represents the layering of protocol objects. Di erent protocol graphs may be con gured at compile time. Figure 1 illustrates a protocol graph for TCP and UDP over IP, with IP over Ethernet. TCP
UDP
IP
eth
Figure 1: Example x-kernel protocol graph The xOpen operation performed on a protocol object returns a session object, which is a specialized instance of a protocol. A connected series of session objects is created at each protocol layer during an xOpen . Messages are sent by performing a xPush operation on a session object. Each protocol specializes xPush for its session objects in order to append message headers or calculate checksums, before performing a xPush operation on the next lower level session in its protocol graph, passing the possibly modi ed message downward. The lowest level protocols in the graph, known as anchor protocols , actually transmit the message on the hardware devices they encapsulate. The x-kernel follows a \thread-per-message" style of message processing. Each message, on receipt by an anchor protocol, is allocated a thread that shepherds it up the protocol stack. A protocol receives a
2
message when a lower level session performs a xDemux operation on it. Each protocol specializes its own xDemux method to strip message headers or trailers, and determine which session object the message is meant for (ie., the protocol demultiplexes the message to one of its sessions). The message is now delivered to the destination session by the protocol invoking a xPop operation on the session. For remote procedure call (RPC) types of protocols, xCallPop may be invoked instead, for which a reply is required from the destination. The session object may perform more processing on the message before sending it further upward with a xDemux to the higher level protocol in its protocol graph. The xClose and xCloseDone methods serve to terminate, and to signal the termination of sessions, respectively. Other operations exist for the implementation of passive opens, and for protocol graph manipulation. The x-kernel has been ported to the following platforms: SunOS, as a user-level process, Mach, within the kernel on Sparc and DEC Alpha architectures, Choices and VirtualChoices object-oriented operating system, within the kernel on Sparc and on Unix platforms.1
3
x-ATM
Software Structure
Figure 2 illustrates the software structure of x-ATM in the form of a x-kernel protocol graph. The entire suite of procotols is shown in gure 2. In most cases, only a subset of the suite is con gured for use at one time. RTP
TCP
UDP
IP
SIG
IP to ATM
Q.2931
SPANS
GULP
ATM ARP
AAL5
AAL3/4
AAL0
ATM API
iPOINT
AALX
ATM
ASX− 100
SBA− 100
XUNET
switch hardware
Implemented In progress Present in x−kernel
Figure 2: ATM Protocol Suite The anchor protocols (the bottommost layer in gure 2) encapsulate the ATM hardware devices for the ASX-100 switch, SBA-100 host adapter boards, Fore ATM API, and iPoint experimental ATM
1 VirtualChoices is a port of Choices to the virtual machine presented by the Unix operating system.
3
switch. Higher level protocols such as the adaptation layers or IP operate without regard to the lower level devices, thus a ording easy portability of higher level protocols across di erent hardware platforms. An x-kernel protocol graph is con gured statically at compile time through a con guration le. The x-kernel \compose" tool reads the con guration le and produces code that joins together each speci ed protocol to form the protocol graph. Figure 3 illustrates the con guration of a subset of the x-ATM protocols that may be used as an ATM switch controller for the ASX-100 switch. name=asx; name=atm protocols=asx; name=aal4 protocols=atm; name=spans protocols=aal4; name=sig protocols=spans,asx;
Figure 3: Con guration le for ASX switch control with SPANS signalling. SIG
SPANS
AAL4
ATM
ASX
Figure 4: Protocol graph for the ASX-SPANS con guration. The ASX-100 protocol acts as the anchor protocol, encapsulating the control hardware of the switch. Layered on top of it is the ATM protocol object, ATM adaptation layer 4, the SPANS signalling protocol, and SIG, the abstract signalling protocol (discussed in section 4). SIG also has the ASX-100 protocol directly below it, so that it may invoke operations on the ASX protocol to set the switch translation tables as circuits are set up or torn down. A host side signalling entity may also be constructed in a similiar fashion with the toolkit. The \asx" entry in the con guration le would be replaced with \sba100". For example, a host with a SBA-100 ATM interface is con gured with the con guration le speci ed in gure 5. This example illustrates both name=sba100; name=atm protocols=asx; name=aal4 protocols=atm; name=spans protocols=aal4; name=sig protocols=spans,sba100;
Figure 5: Con guration le for SPANS on a host with a SBA-100 ATM adapter. the ease of con guration and portability of the x-ATM protocol suite across switches and hosts.
3.1 The ATM Protocol Object
The ATM protocol object is the core interface between higher level protocols, such as the ATM adaptation layers, and the anchor protocols representing the hardware devices. The ATM protocol de nes addressing standards based on ATM Network Service Access Points (NSAPs) and Service Access Points (SAPs). These are analogous in the IP world to IP addresses and port numbers, respectively. All higher level protocols use the addressing convention de ned by the ATM protocol. The ATM protocol object functions as a hardware independent ATM interface, encapsulating one or more ATM anchor protocols. This assures that platforms with multiple ATM devices are supported. When a higher level protocol attempts to open a connection to a remote NSAP and SAP, the ATM protocol object will try each lower level anchor protocol in turn until a successful open is achieved.
4
Messages xPush ed to ATM protocol sessions from higher level sessions for transmission are passed by it to lower level ATM anchor protocols with an ATM cell header attribute for that session axed. The data is otherwise passed downwards without change. Segmentation into cells is not done since anchor protocols may specialize their particular methods of sending packets. For example, while the SBA-100 driver sends one cell at a time by writing the data to a memory mapped device, the Fore ATM API driver simply writes all the data out on a le descriptor created by the atm open API call. The ATM protocol object expects messages passing upward from the lower level ATM anchor protocols to have an ATM cell header attribute axed to them. The protocol object uses the information regarding the virtual path and virtual circuit identi er to demultiplex the message to the appropriate destination ATM session. ATM protocol sessions pass this information upward unchanged. Higher level protocols, such as the adaptation layer protocols, may use the cell header attribute for reassembly of ATM frames.
3.2 Adaptation
The adaptation layer protocols usually reside directly above the ATM protocol. Four adaptation layer protocols have been implemented | AAL0, AAL3/4, AAL5 and AALX.2 While each of the adaptation layer protocols implement reassembly, segmentation is left up to the anchor protocols. The design is deliberately assymmetric. The reassembly process needs to be specialized for each particular adaptation layer protocol; for example, checksum calculations di er between AALX and AAL5 and can be incrementally calculated as cells are added into the reassembly bu ers. On the other hand, segmentation varies between anchor protocols | di erent devices require di erent segmentation policies. Anchor protocols specialize their particular methods of sending packets. For example, while the SBA-100 driver sends one cell at a time by writing the data to a memory mapped device, the Fore ATM API driver simply writes all the data out on a le descriptor created by the atm open API call (see section 3.4). Transmitted cell sizes expected by drivers like the SBA-100 and ASX-100 also di er, the former requires a 56-byte cell while the latter requires a 60-byte cell (1 extra word is used for internal routing within the ASX-100 switch fabric). Thus all segmentation functionality is located at the ATM anchor protocols. The adaptation layer protocol family expect messages from the ATM protocol object to have an ATM cell header attribute axed. Reassembly in AAL0 and AAL5 depend on the payload type eld of the ATM cell header: a type of 0 indicates a data cell while a type of 1 indicates an end of frame. AAL3/4 reassembly depend both on the payload type and the SDU and PDU headers.
3.3 IP over ATM
The IP over ATM protocol is layered both above the AAL5 protocol and the ATM ARP protocol. ATM ARP converts IP addresses to ATM addresses. This branch of the x-ATM protocol tree permits experimentation with TCP/UDP/IP over ATM. An RTP implementation[14] within the x-kernel will allow us to experiment with issues related to real-time trac such as video and audio streams. An xOpen performed on the IP over ATM protocol results in it invoking a control operation on the ATMARP protocol. ATMARP responds with the matching ATM address. The IP over ATM protocol uses that ATM address to open an ATM connection over the AAL5 protocol. The x-kernel distribution includes many other protocol types that may be composed on top of the ATM support that the toolkit provides. This includes RPC protocols such as Sun RPC[18] and encryption and key server algorithms such as Data Encryption Standard (DES)[24] and KM, the key manager protocol[12].
3.4 Anchor Protocols
x-ATM's anchor protocols encapsulate several commerical and experimental ATM hardware devices.
Support is provided for Fore Systems ASX-100 switch and SBA-100 host ATM adapter board, as well as for the Fore ATM API. In the case of the Fore ATM API, ATM connections are created with the atm open ATM API call. This call returns a Unix le descriptor, with which cells may be sent via the atm send call and received through the atm receive API call. The iPoint experimental ATM switch is supported through an iPoint driver. This driver is unusual and further discussed in section 4.2. In addition to providing the sending and receiving of ATM cells, switch anchor protocols also have a common control interface to allow higher level signalling protocols to read and write the switch's cell translation table.
2 AALX is used on the XUNET network and is similiar to AAL5 but uses a di erent trailer format and checksum.
5
We plan on extending the range of supported hardware devices to include the XUNET switch and the new line of SBA-200 host adapter boards by Fore Systems.
4 Signalling
We have implemented a switch controller for the ASX-100 switch and the iPoint experimental ATM switch, as well as host side signalling, with x-ATM. In all of these cases, the same signalling code is used except for di erent anchor protocols. In our experience, the x-ATM toolkit and x-kernel framework provide a exible and portable framework for the implementation of ATM signalling. We are planning to extend the suite to handle signalling for the XUNET switch, as well as resource reservation algorithms such as RCAP[3]. The design of the signalling suite simpli es interoperability between di erent signalling protocols. The signalling state machine implemented in the SIG protocol is independent of any particular signalling protocol. It may thus be used as the basic signalling engine for ATM while lower level protocols handle the speci cs of their respective message formats.
4.1 Linear Signalling
Suppose that host A wishes to communicate to host B and further that there are n intermediate switches S1 , S2 , :::, Sn , with A connected to S1 and B connected to Sn . Host A begins by sending a Setup message to S1 . Each switch Si propagates the Setup message to Si+1 for 1
