No abstract

One approach to facilitate statistical multiplexing of bursty sources in A TM networks is dispersion of the traffic over independent paths. It has been shown within the literature that by dispersion of traffic over disjoint paths it is possible to increase the Quality of Service (QoS) (see e.g., (Maxemchuck, 1993), (Lee, 1993)). In multipath schemes without additional error control, the resulting QoS depends on the worst-case path. By using a multipath scheme with FEC (Forward Error Correction), it is possible to compensate cell losses. Using error correcting codes like Reed-Solomon-Erasure Codes (RSE Codes, (McAuley, 1990)), these schemes add redundancy and disperse the traffic using several transmission paths (Ding, 1995).Until now, protocols and implementation concepts suitable for a widespread use of multipath schemes are still missing, in particular for the widely used adaptation layer AALS. We present a novel protocol MP-FEC-SSCS for AALS for employing a redundant multipath communication scheme especially suited to the UBR (Unspecified Bit-Rate) service. This presentation is complemented by detailed results for software implementations based on C++ and first results using Java, targeted for an active network implementation.

No abstract

ATM, the asynchronous transfer mode, represents a flexible transmission technology, which offers a set of new services to the user. In order to take advantage of ATM's strength and to be able to integrate access to ATM services into own applications, a powelful ATM application programming interface (API) is needed. At our institute, we have implemented three different variants of such an API for accessing native ATM functions. In this paper, we first present the design and implementation of an ATM API in C for Digital Alpha workstations running Digital UNIX. We then describe a Java ATM API offering the socket programming environment Java programmers are used to, and finally a set of Java functions accessing the Windows NT Winsock 2 inte$ace. We contrast the different philosophies and architectural approaches with each other and give throughput numbers. IntroductionDuring the last years, communication technology has drastically evolved towards fiber optic networks and enhanced transmission technologies, such as SONETISDH. Based on these developments, very high speed networks are becoming reality, especially based on ATM technology for Broadband-ISDN. However, typically the new services offered by ATM are hidden by traditional protocols residing between applications and network services. For example, using IPover-ATM [Lau94] or LAN emulation [ATMF97b] reduces ATM to a traditional link layer protocol and hides the new functionality.One possibility for an application to take advantage of the services offered by ATM is to use a native ATM service interface, which provides applications direct access to the functionality of the ATM adaptation layers (AALs). The ATM Forum has defined a semantic description of such an ATM application programming interface (ATM API) [ATMF96a, ATMF98bl. This specification has been implemented on several architectures like those for the UNIX derivate Linux [Alm96] and for PCs running MS-DOS or the Plan 9 operating system and Fore adapters [KeSa94]. The latter has been ported to FreeBSD [JaKe96]. [ShKe94] also deals with the design and implementation of operating system and signaling support for native-mode applications. [AKS96] gives an example of a transport service offered on top of ATM AAL 5. The Winsock 2 Application Programming Interface, which offers a socket interface to applications running under Microsoft Windows, has been extended to support native ATM services [MIJ96]. Fore Systems, Inc., offers an API which supports the proprietary SPANS signalling protocol, which differs from the UN1 specification of the ATM Forum [ATMF94, ATMF96cI. A comparison of the communication performance of four APIs (Fore Systems' ATM API, BSD socket programming interface, Sun's Remote Procedure Call (RPC), and the Parallel Virtual Machine (PRM) message passing library) can be found in [LHD+95], [ATMF99c] compares ATM APIs for XTI, Winsock and Linux. For accessing ATM's (and other technologies') functions in switches, the Multiservice Switching Forum has suggested a different architecture [MSF98].In sect...

No abstract