Currently, ATM is used in the high-capacity parts of public telecommunications networks and large corporate networks. ATM switches therefore incorporate additional features to enhance reliability of the equipment and of the service provided by the network. These features, the comparatively low volumes, and other aspects of the markets into which they are sold, combine to maintain high prices.
ATM interface cards for PCs cost more than Ethernet cards, and ATM switches cost more than Ethernet switches, simply because Ethernet has achieved "commodity" status in the marketplace. This is partly because it is a technology suitable for data services such as remote file access, which is what most PCs required in the mid-1990s when fast Ethernet and ATM were contending to be the successor to 10 Mbit/s networks. Arguably it is also due to some ineptitude on the part of the ATM Forum in their marketing strategy for ATM technology at the time.
However, there is no technical reason why cell-based networks should be more expensive than other technologies.
Until they withdrew them early in 2002, the Marconi LE25 and LE155 switches could be used to build local area ATM networks at a reasonable price, though not as cheaply as fast Ethernet.
The Nine Tiles RouteLive switch has been developed to fill this gap in the market as well as to provide additional facilities for demanding professional audio applications including live-to-air streaming for broadcasters; and our Brunhilde ATM-over-Ethernet technology will drive the cost of cell-based networking down further.
ATM networks are connection-oriented, so that it is necessary to set up a connection before beginning to transfer data. IP, on the other hand, is a connectionless protocol, and datagrams can be sent without any preliminary setting-up.
When writing a "quick and dirty" application that does not require any particular level of service from the network, IP's more informal approach can be an advantage. However, for professional audio applications a number of parameters regarding the traffic flow must be negotiated with the network (constant bit rate service, capacity to be reserved along the route) and with the destination equipment (audio format, sample rate, number of channels), and call set-up is the right mechanism for doing that.
A piece of equipment with an ATM interface may be able to accept calls carrying many different types of data (PCM audio, compressed audio, telephony, video, etc), and each incoming call is routed internally on the basis of a variety of information that can be provided during call set-up. It may well be able to accept several calls at the same time, all carrying the same kind of data, for instance several audio channels from different sources.
With IP-based protocols, live streams are carried in RTP over UDP over IP and many aspects of the format are defined by a "profile". RFC1889 states: "Typically an application will operate under only one profile so there is no explicit indication of which profile is in use." Although the IP header has a field which shows that the next layer is UDP, the UDP header has no way to indicate that RTP is being used. The only way to distinguish different data flows is by a 16-bit "socket" number, and equipment would have to provide n different socket numbers, where n is the number of streams it can store at a time. There would also need to be a way in which the senders of the information could indicate what format is being transmitted, and find which socket number to use.
In order to "register" with an ATM switch, information must be exchanged using the Interim Local Management Interface. Once a piece of equipment is registered, it can set up outgoing calls, accept incoming calls, and clear down calls using the ATM "signalling" protocol.
ILMI uses messages in the same format as SNMP, which is used for managing switches, routers, etc, in IP networks. Signalling is a very straightforward protocol which is easy to implement from the description provided in the ATM UNI specification and some ITU-T Recommendations to which the UNI specification refers. Signalling and ILMI protocol stacks are commercially available, but are expensive and require 6 man months to port to the client's equipment. What the vendors of these stacks don't tell you is that the part of the protocol that needs to be implemented in end equipment can be written from scratch in 4 man months.
Signalling messages provide useful information that is not available in an IP environment. For instance, the call set-up message can unambiguously specify that the data will be PCM audio with a particular format, sample rate, etc, and the AES47 Standard specifies how that is encoded. The equivalent IP-based protocols require the destination to discover this information by some means that is not standardised.
An ATM switch has to make a routing decision for every 48 bytes of data, whereas an Ethernet switch or IP router only needs to make a decision for every 500-1500 bytes.
However, the process of making the routing decision for the cell-based network is extremely straightforward. The most complex case requires two reads of conventional RAM: one using the 8-bit or 12-bit VPI as the address, and a second with the 16-bit VCI as an offset into a table whose address is the result of the first read. For many switches, and for most end equipment, the VPI is not used and the VCI is less than 16 bits (typically 10 bits, requiring a single table with 1024 entries; the size is negotiated via ILMI).
An Ethernet switch, by contrast, has to route on the basis of the 48-bit MAC address, for which it has to search in an associative memory, cache, or hash table.
IP routers have even more complex decisions to make, particularly if protocols such as RSVP are used to give a measure of "quality of service" (though the service provided by RSVP is still inferior to that provided by ATM): to discover whether a packet is one for which a capacity reservation has been made, the router needs to "drill down" into the packet to find the headers for several of the protocol layers.
Multicast packets and cells are sent to more than one destination. Broadcast packets are sent to all destinations.
ATM has no need of broadcasts, because all the functions which use broadcasts on Ethernet/IP networks are handled by the signalling and ILMI protocols. For multicasts, routing decisions are made at call set-up in the usual way, and switches which need to copy the cells to more than one output have the necessary information put in their routing tables.
IP provides both multicasts and broadcasts. There is an additional protocol (RFC1112) that must be implemented to allow end systems to join and leave multicast groups.
Ethernet was originally a shared-media network in which every packet was broadcast to the whole network. Therefore, it has no provision for switches to discover on which ports to output a multicast packet, and they have to treat multicasts in the same way as broadcasts.
Consider, for example, the case where a network carries twelve 3 Mbit/s multicasts, each of which is received by two of the 24 units plugged into a switch. In the Ethernet case this traffic will occupy 36 Mbit/s on each link because every unit will receive all the multicasts, whereas with ATM each unit will only receive the multicast in which it is interested and the traffic will only occupy 3 Mbit/s.
If a packet which is part of an audio stream arrives at an output of a 10-Base-T switch just as a maximum-length Ethernet packet has begun to be output, it must wait until the end of that packet, which is 1.229 msec. When ATM was first defined in 1989, one of the arguments in favour of cell-based networks was that large packets would be chopped up into cells and the wait is reduced to one cell time, or 43 µsec at 10 Mbit/s, thus reducing the contribution to the worst-case transit delay made by each switch.
With faster networks, these figures are reduced. Using, 100-Base-TX at the edge and gigabit Ethernet in the core, the figures reduce to 123 µsec in the edge switches and 12.3 µsec in the rest. However, delays of 123 µsec can still be important for audio applications, though insignificant for other traffic.
More importantly, for live audio applications we also have to consider the packetisation delay (explained here). There is no benefit in reducing the packet size below one sample per channel, but above that size the packetisation delay increases in proportion to the packet size. Even if channels are always transmitted in MADI-size bundles of 56, at 32 bits per sample, the optimum packet size is only 224 bytes.
Where the majority of traffic is audio, therefore, the network must be designed to work efficiently with small packet sizes.
The overheads in cell-based networks can be classified as: cell headers; "ATM adaptation layer" protocol overheads; and unused payload bytes where the data does not divide neatly into 48-byte instalments.
Cell headers provide all the information necessary to route a cell and decode it at its destination. On both 25 and 155 Mbit/s ATM links, over 87% of the link capacity is cell payloads; in the latter case the remaining 12.8% includes the SDH/SONET overhead as well as the ATM cell headers. On a 100 Mbit/s Brunhilde segment, the overheads are less than 8.5% so 91.5% of the link capacity is cell payloads.
When using the "proper" Internet protocol stack for continuous media, RTP over UDP over IP over fast Ethernet, there is an overhead of 90 bytes per packet. To achieve the same ratio of payload to link speed as standard ATM, a payload size of nearly 864 bytes would be needed, with a corresponding (and unacceptable) increase in the packetisation delay. To achieve the Brunhilde ratio, a payload size of over 1000 bytes would be needed.
When sending IP packets over ATM networks, AAL5 is used, which takes up 8 bytes per packet for the packet length, CRC, and other information. IP packets are liable to be any size, so the amount of "padding" required to bring the total to a multiple of 48 bytes can be anywhere from zero to 47 bytes. Thus on an ATM connection between IP routers there is a total overhead of between 8 and 55 bytes per packet plus 10.4% for the cell headers. Therefore, for that particular application other formats could allow more of the SDH payload to be used, although in practice some of the current proposals have overheads of their own, such as HDLC-style byte-stuffing (which could add anything up to 100%).
For a data network that carries IP packets, supporting applications for which IP provides an adequate service, removing the ATM layer could increase efficiency. For an application such as professional audio, where standard IP does not provide an acceptable level of service, it is better to remove the other layers. For instance, where a call carries a single stream of audio data (rather than, for instance, where it is a link between routers, perhaps carrying all the data traffic between two sites) all the information in the IP and UDP headers is redundant, having been conveyed during call set-up.
The format specified in AES47 keeps protocol overhead to a minimum (including providing a format in which there is none at all), and there are no unused payload bytes.
Although there are a number of applications that send continuous media over the IP, the service provided does not meet the requirements of professional audio.
The delay of between 1 and 2 minutes in most broadcasts over the Internet is caused by the store-and-forward nature of IP routers. Delays of this magnitude will be unacceptable for many professional audio applications, as will the occasional loss of communication that occurs on these connections.
Voice telephony over IP works on private networks, provided it occupies no more than 4% of total network traffic. Most audio applications will require a much larger proportion of the network over which they run.
Other applications over packet networks that have no other traffic on the network claim that they can use 30% to 60% of the network capacity. The capacity that must remain unused therefore constitutes an additional overhead of 66% to 233%, considerably more than the overheads considered in the preceding section.
--oOo--
Copyright ©2001,2002 Nine Tiles Networks Ltd