Missing:
Active Networks M. Zitterbart, R. Wittmann, B. Metzler, T. Harbaum Institute of Operating Systems and Computer Networks Technical University of Braunschweig Bültenweg 74/75 D-38106 Braunschweig, Germany
1. Introduction The Internet is on its way from a toy mostly used by researchers to a tool used for everyday purposes in the living room of private homes and in offices. Things have changed dramatically during the last few years, being to some extend driven by the appearance of the web and its applications. Ecommerce is one of the “magic” distributed applications appearing on the Internet. Others are IP telephony, Internet TV, tele-collaboration and the like. The variety of distributed applications currently increases rapidly. However, they require suited communication support, i.e., performance and quality of service as well as flexibility. In contrast to the applications, the Internet itself has not changed that rapidly. Today it is still based on the first generation protocols IP, UDP and TCP that have been designed almost 20 years ago with very different applications in mind. Moreover, the Internet has up to now been considered as a passive network in the sense that it simply forwards data based on IP address information. Furthermore, these protocols are solely based on the assumption that either exactly two partners communicate with each other or data are broadcasted to everybody. Considering many emerging multimedia applications it, however, should be noticed that they refer to group communication. Typical examples can be seen in tele-collaboration or distance learning. Thus, protocols supporting group communication are required. With IP-Multicast, the basic technology is provided concerning addressing and routing of data to a group of participants. Higher layer protocol, e.g., at the transport protocol, are currently under development. This also holds for quality of service concepts. With respect to the transport layer protocols for group communication it is commonly accepted that a single protocol cannot fit the variety of service requirements. Thus, the concept of “one size fits all” does not hold any longer. Being confronted with the increasing variety of application requirements the Internet has started to explore a new way of networking, called active networking. Improving services for distributed applications can be viewed as the main goal of active networking. This improvement refers on the one hand to enhanced services, e.g., for audio and video transmission and on the other hand rapid service creation. The latter requires an increased flexibility in service provisioning. Overall, active networks can lead to a faster introduction of new services and protocols. Active networks currently form a challenging field of research, not only concerning immediate communication issues but also addressing security, system architecture and the like.
This paper is organized as follows. Section 2 gives an introduction into the concepts and basic architectures of active networking. Furthermore, some prominent examples are briefly outlined. With AMnet, an approach for using active networking technology in order to support heterogeneous group services is presented in some detail in section 3. A summary and outlook in section 4 concludes the paper.
2. Concepts and Architectures for Active Networking The main idea behind active networks can be seen in the fact that the network no longer passively forwards data. Instead, it actively operates on the data in order to provide a better service to applications. Therefore, the network nodes process user data. In the current Internet, network nodes, i.e., IP routers or IP switches, forward data according to the corresponding routing information. They do not change the user data as it is flowing through the network. Figure 1 shows a simplified scenario with an active node being located in the network. The IP data unit carries both, data and a program. Within the active node, the program is executed on the data. Thus, the data leaving the active node differ from the data received by the active node (cf., Figure 1).
End system 1
Active Node
IP Data´ Program
IP Data Program
End system 2
Figure 1 Basic Principle of Active Networks In the following, first some applications are highlighted that profit from active networks. Then, the two basic concepts are briefly introduced followed by a discussion on the impact on network node design. A brief presentation of some actual projects concludes this section. In [Tenn97] an early introduction into active network research can be found.
2.1 Applications Benefiting from Active Networks The goal of active networking is to improve the quality of service experienced by the user of such a network compared to passive networks as todays Internet. In the following some examples of applications are given that can profit from active networking. •
Web proxies collect and store web pages in order to reduce access time to frequently used pages. Typically a hierarchy of web proxies is statically established in the network. With active networking, caches could be placed dynamically on active network nodes at strategic point in the network.
•
On line auctions usually use servers that collect the bids. Due to communication delays in global networks, low bids can arrive that are no longer meaningful and
thus need to be discarded. Active nodes could filter these bids earlier in the network and, thus, reduce network load as well as the load on the server. •
Network management can also be supported by active nodes. They are mostly based on a centralized architecture with the network manager in the center. Active nodes could interpret management data in the network. This reduces the load on the network manager and enables a faster reaction to network faults.
•
Another prominent example for the usage of active networks is reliable multicast. One of the main problems of reliable multicast is scalability to large and geographically distributed groups. Providing local error recovery is envisioned as suitable strategy to overcome the scalability problem. Active nodes could dynamically host appropriate error recovery procedures at local strategic points in the network.
2.2 Capsules versus Programmable Nodes Generally, two different approaches to provide more flexibility within the network can be distinguished: • •
Capsules Programmable Network Nodes
Capsules are data units that carry with them the program to be processed in active nodes. Thus, active nodes are programmed on-the-fly. In the extreme, the programs to be executed differ from data unit to data unit. Capsules can, for example, carry a compression algorithm that is executed in those active nodes that cannot provide the same high output bandwidth as on the incoming link. This way, the data volume can be reduced on demand and the data can continue travelling towards the destination. Other examples where capsules can be applied are routing algorithms and, especially, QoS-based routing. Generally, this approach provides a high flexibility and a high potential for timely on-demand reactions. On the other hand, the overhead needs to be considered by carrying complete programs in addition to the user data. Programmable network nodes also use dynamically loadable programs. However, the programs are downloaded off-line, i.e., they are programmed out-of-band. As a result, programming is considered for a data stream or at least for multiple subsequent data units and not for an individual data unit flowing through the network. In this respect, programmable network nodes are less flexible than capsule-based approaches. The reduced overhead during user data transfer, however, can be considered as important advantage. Although capsules and programmable network nodes are different approaches, they are combined in many research projects. Capsules are advantageous for smaller problems, whereas larger problems are preferably implemented by programming network nodes.
2.3 Impact on Network Nodes With active networking, network internal nodes operate on user data. This is very different from current network nodes that only forward data based on the destination address and the information available in the routing table.
Since the programs are dynamically loaded during runtime, security is of major concern with active networking. It needs to be ensured that no misuse is taking place. Therefore, an authentication of the user downloading the program is needed. Furthermore, the resources that such a program can access need to be controlled. For example, run time checking and sandboxes can be used. With respect to research projects, some of them mainly concentrate on the security issue and address it by developing special programming languages. The security issue is somewhat relaxed if programmable nodes are applied with program repositories. Security checks can be performed when programs are placed into the repository, which is less time critical than on-the-fly checking being associated with each individual data unit. Since active nodes execute application code on trespassing data, the performance issue arises automatically. However, it can be observed that IP routers have greatly improved with respect to performance over the last couple of years. Additional efforts are, however, needed to provide suited platforms for active networking. This is addressed in some of the current active networking projects. In this context, it again needs to be stressed that active networks aim at improving application services. Additional burden for network nodes need to be taken into account.
2.4 Some Prominent Examples The objective of this subsection is to briefly outlined selected examples of approaches with respect to active networking. The selected examples are ANTS being carried out at MIT and SwitchWare of UPenn. The goals of ANTS are the following: simultaneous use of a variety of network services (not limited to IP) and the dynamic deployment of new protocols. ANTS is based on the capsules approach using special code distribution mechanisms. ANTS uses Java as its programming language and the Java Virtual Machine for the execution environment, which makes it applicable for a variety of applications. Also security features of ANTS rely on Java mechanisms. For the transport of capsules ANTS establishes a path during the initial delivery. The nodes on the path caches the code for subsequent packets. The capsule itself only carries a reference to the code to be applied to the payload. This way overhead for the transportation of code is reduced. The SwitchWare project at UPenn is based on programmable switches as well as capsules. For capsules SwitchWare uses a domain-specific functional programming language, PLAN (Programming Language for Active Networks). This language is complemented by noderesident services. These services can be part of the base functionality of the node or dynamically loaded active extensions. One major focus of SwitchWare is in the provision of security for programs. Therefore, PLAN only provides minimal functionality, e.g., the evaluation of PLAN programms on other routers or the call to active extensions. Whereas active extensions are protected by cryptographic signatures and statical typechecking. Moreover, a secure active router was designed in this project. Furthermore, various research projects examine how basic multicast control mechanisms could benefit from the application of both capsules [Weth98] and programmable switches approaches [Alex98]. In particular, sophisticated acknowledgment [Cald98], [Lehm98] and congestion control [Fabe98] mechanisms for multicast communication are proposed. However, with these approaches support for heterogeneous group communication is not
considered. The approach AMnet (Active Multicasting network) being presented in the following section especially addresses heterogeneity within group communication. It transparently provides support for heterogeneity neither involving the sender nor the receiver. The network itself with its active nodes is responsible for providing the required heterogeneity.
3. AMnet: Active Multicasting Network AMnet particularly addresses group services and aims at providing scalable heterogeneous group communication where participants can individually select service levels. This selection is transparent to other group members. Therefore, AMnet follows an active networking approach. In order to provide individually tailored services, so-called service modules are dynamically downloaded on network internal AMnodes. They, then, operate on the data flowing through an AMnode. Examples of service modules that are currently being explored in the context AMnet are QoS filtering and error control. Service modules for QoS filtering operate on video data (e.g., MPEG-1) and reduce the data rate of the video stream. This is particularly interesting in case of wireless attached systems. Error control, is addressed with respect to systems that are attached through a wireless link or regarding local group error recovery in the case of reliable multicast services. . The heterogeneous multicast service provided by AMnet should satisfy the following constraints: •
Independency: The heterogeneity support should not be restricted to a dedicated media format.
•
Transparency: The sender should not necessarily be involved in heterogeneity support (but, it should not be disallowed from doing so if it is the most efficient way under some circumstances).
•
Communication transparency: The introduction of additional functionality within the network should be transparent to the end-to-end communication. If required by service demands, the information flow between sender and receiver should keep real-time characteristics.
•
Flexibility: The approach should allow for dynamic changes in both the communication infrastructure and the applications demands on communication quality.
•
Scalability: Different communication scenarios with a varying number of participants should be supported.
3.1 Basic AMnode Architecture An AMnode consists of different functional blocks. They are responsible for the management of active node functionality, implement the AMnet control protocols and offer a flexible execution environment for active AMnet services (see Figure 2). Each functional block will be shortly introduced in the following. The execution environment and the AMnet-specific
integration of hardware based service execution is discussed in greater detail in subsection 3.4. parameterizing
QoSFilter
Service modules & Execution Environment
AMnetManager QoSMonitor
Error control
QoSInformation AMnetSignaling User data
signaling
Hardware Manager
DeMux
Figure 2 Components of an AMnode The service management functionality is common to all AMnodes. It is represented by the AMnet Signaling entity which implements the service control protocols. It is responsible for the announcement of local service capabilities of the node and for handling of service requests. AMnet Signaling contacts the local AMnet Manager which implements admission control and resource reservation. Node management is the task of the local AMnet Manager. The AMnet Manager has to load and/or configure service modules to provide a requested service. It receives the required information from AMnet Signaling. The configuration of a service is complemented with appropriate local resource management. The AMnet Manager further controls the demultiplexer (DeMux) which is responsible for the correct classification of incoming data. Dependent on its content data units are assigned to appropriate AMnet flows or forwarded to the signaling component. Service modules are loadable on demand and, thus, allow for dynamic adaptation on changed application requirements. For the transparent provision of service heterogeneity two kinds of service modules are provided: modules that perform media translation (such as media filters) and protocol adaptation modules (e.g., error control). Protocol adaptation modules are responsible for the translation of protocol semantics and syntax. For example, error control within heterogeneous services can suffer from the problem of different sequence spaces due to intermediate media transformation: The original acknowledgment issued by the receiver of an altered data unit would be misinterpreted by the sender and cause a semantic violation with respect to the end-to-end data flow.
Ideally, an AMnode is equipped with dedicated hardware to which processing consuming service modules can be offloaded. The hardware components execute service modules according to hardware/software co-design principles. This way, complex services, such as media translation, can be provided more efficiently. The hardware-based service modules are transparently integrated into the common execution environment. The Hardware Manager is responsible for the transparent operation of dedicated hardware. After service establishment, a QoS Monitor observes ongoing local operations and collects actual information for the AMnet Manager. This functionality is intended to provide the AMnet Manager with knowledge on the current performance and resource consumption of the node. Furthermore, service violations due to local resource shortage are reported to the AMnet Manager. The information can be used for service and admission control.
3.2 Service Model Service heterogeneity within a session needs to be bound to a manageable degree of diversity. Therefore, receivers with similar service demands are logically grouped into distinct multicast receiver groups. They join the corresponding group on demand through IGMP [RFC2236]. Figure 3 shows an example data distribution tree, where AMnodes provide different levels of service quality to their local multicast receiver groups.
SENDER AMnode TTL
QoS A
TTL
AMnode QoS A
TTL
AMnode QoS B
AMnode QoS C
TTL
TTL
Service Announcement Group
Figure 3 Organization of Service Level Groups Each multicast receiver group within a communication session represents all receivers whose service demands can be resolved with a single multicast service. They form a so-called service level group. Each service level group represents a different view onto the same original data corresponding to adaptation within AMnodes. Receiver groups are organized hierarchically. AMnodes are member of both, the parent service group and the child service group (cf., Figure 3). The data stream received from the parent may be an already adapted stream or the original stream. The scope of an AMnet service group is limited by the actual TTL value assigned to data units issued by the corresponding active node (see Figure 3). The
TTL value of every group must not exceed the scope of the service announcement group (see below). Furthermore, the establishment of service level groups permits the provision of different service qualities within one region without the services interfering each other. This, for example, is not possible with the resource reservation protocol RSVP, even though this protocol was designed to support heterogeneous multicast. With RSVP heterogeneous multicast can only be realized with respect to different parts of the tree, but not within the same part of the tree. However, two data streams with different media formats or individual error control must sometimes coexist on a communication link and have to be distinguishable by the appropriate receivers. Therefore, the service level groups can be distinguished by their multicast-addresses. The service quality experienced at the receiver is a function of the service level for the group and the current network conditions between group source and each individual receiver. The service within a group can only differ in performance-oriented parameters such as delay or loss probability. Other parameters which define the content-based nature of the service are homogeneous (e.g., media format, acknowledgment strategy) within a service level group. However, the distinction of service can be triggered by both: performance oriented parameters and content. Consider two receivers with very different loss probabilities. In that case different acknowledgment strategies might be necessary which requires different service level groups. The hierarchical ordering of services does not automatically imply hierarchical degradation of all service parameters. Some parameters can be provided unchanged, other parameters even improved. As an example, the insertion of a new service can improve media playback quality due to less jitter at the cost of higher, but uncritical delay. This could be useful for video distribution, for example.
3.3 Service Control In contrast to the capsule approach, AMnet is not based on executable code to be transmitted in user data units. Instead, with AMnet signaling procedures are provided to request and control service modules. Control of the heterogeneous group services is maintained completely out-of-band. This ensures that new service modules can be easily supported by the AMnet signaling procedures. The signaling itself, however, uses capsules for service allocation purposes and the like. In this sense, AMnet combines both, programmable nodes and capsules. Moreover, separation of signaling and data transfer de-couples AMnet from the used transfer protocols. In a first prototype implementation RSVP was used as signaling protocol [Witt98]. With this prototype QoS filters were requested by receivers via RSVP. To this end appropriate parameters are added to RSVP reservation messages. But RSVP does not offer the flexibility to support optimal allocation of service modules, because RSVP tends to locate the service as close to the sender as possible. While this is desirable for media translation, protocol adaptation can not be realized this way. Therefore, currently a proper signaling model for AMnet is being designed. It consist of the following components: • Session announcement,
• • •
service announcement, service module repository, and service access.
A session announcement is advertised by a sender on a separate multicast group - the socalled session control group. In this group every AMnet session is announced similar to the well-known Session Announcement Protocol (SAP) [Hand96] of the MBone. The session announcement contains a description of the session, including bandwidth and delay requirements, and content specific information, e.g., data format and compression scheme. This description is used by the session receivers to determine which service modules have to be requested to receive a data stream at a desired service level. Moreover, the description contains the multicast address of the original data stream and the multicast address of a socalled service announcement group. Whereas the session control group provides information of all available Amnet sessions, the service announcement group forms a data base of the available AMnet services for a given session. This group is used for signaling of heterogeneous service capabilities and demands, i.e., all available service level groups are announced in this group. Therefore, all session participants are member of the service announcement group. If a new service is established by an AMnode, the node advertises the appropriate service description within this group. This way a participant is able to learn about available services. The service module repository is a distributed data base which contains service modules and their description. The purpose of the repository is to make service modules available to an active AMnet node in case that a service module is not already cached at that node. Service modules can be stored in the service repository by AMnet users and network management procedures. The mechanism for service access is very similar to the current practice in the MBone. If a participant wants to use an AMnet service, e.g., media translation or enhanced error control, the participant checks by joining the session´s service announcement group whether the desired service is already available. If the service exists, the participant simply joins the associated group of the nearest AMnode that provides that service. This AMnode can be determined by measuring the hop count, for example. If the service does not exist, the participant may request that service in the announcement group which causes an AMnode to provide and announce that service. This is a very simple scheme for service location. Especially the topology of the net is not considered. More elaborated mechanisms for service localization are currently under investigation.
3.4 Execution Environment and Hardware Integration 3.4.1 Execution Environment An environment has been developed which enables the execution of AMnode functionality. It is shaped for two objectives: to support functional flexibility and to offer an efficient data path through the node in order to cope with the requirements of an AMnode. The design supports the transparent integration of both, software based and hardware based service modules.
The Linux kernel structure was slightly modified to securely export network access to the application space. Secure network export is granted by flexible kernel filtering modules which demultiplex incoming data to the appropriate destination in user space. With demultiplexing functionality remaining in the trusted kernel environment each communication protocol entity and service module in user space has only restricted access to network data. The demultiplexing support is based on an extension of the well-known Berkeley Packet Filter (BPF) [Cann93]. The BPF is extended for more efficient demultiplexing on a large number of active endpoints and to handle fragmented packets. For 25 endpoints, the BPF/C (BSD Packet Filter/Classifier) is more than three times faster. Efficiency improvement is achieved with BPF/C due to the dynamic merging of similar filtering instructions from different associated connection endpoints at endpoint activation time. Filtering instructions are similar, if identical data unit formats are parsed. Remaining endpoint-specific filtering instructions within one protocol family are typically bounded to the comparison of address values (e.g., port numbers). They are mapped onto the management of a flexibly sized key table, where endpoint constants are referring to the associated endpoint. The number of endpoint specific keys is not architecturally limited, but with most protocols a few keys for address evaluation will be sufficient. Such, within one protocol family only one instance of the BPF/C with associated key table is necessary - the BPF/C acts as a packet classifier. Using the BPF, each activated data stream would result in an individual filtering instance, where on data receipt in worst case all filtering instances would have to be visited sequentially, before the endpoint is determined. The demultiplexing of fragmented packets is achieved with a similar key management technique. But unlike above, keys are created dynamically during fragmentation detection. Here, the key value is fragment-specific and assigned according to data unit information (e.g., the IP-ID for fragmented IP-traffic). To handle lost fragments key lifetime is restricted with appropriate timer management. To restrict the number of necessary kernel/application boundary crossings within the receive path a kernel-resident so-called packet preprocessor has been introduced. It introduces the possibility to flexibly download application-specific code into the kernel. Its functionality is currently restricted to simple packet parsing, splitting or concatenation operations. It allows for the expression of flexible packet gathering operations to collect all fragments of a higher level frame before presenting it to the AMnode service modules. Using this functionality, only one system call per received application frame is necessary. Such, it supports for the execution of all modules necessary for one AMnet service without intermediate path terminations due to still incomplete higher level frames. Further, flow-specific error control models such as the dropping of incomplete frames are efficiently supported at kernel level. The programming language of the packet preprocessor is derived from the BPF and extended. Additional checks on application-originated preprocessor programs are forced to prevent the insertion of malicious code into the kernel. This includes the avoidance of not terminating loops, the restriction of specified memory references (memory alignment, referenced memory area) and the denial of variable jumps. Due to the realization of the BPP as an interpreter those checks are straightforward to implement.
3.4.2 Flexible Hardware Support The integration of hardware support for active networking is an important aspect of AMnet. Service modules can be downloaded either on a flexible programmable hardware platform or can be executed in software by the general purpose processor. The important issue is that not only the software is programmable on-the-fly but the hardware as well. As prototype hardware based on an FPGA-board is used with 8 FPGAs being interconnected through a programmable switch (cf. Figure 4).
Figure 4 Architecture of the prototype hardware The prototype hardware is named FHiPPs, which stands for flexible high performance platform. It is attached to a PCI-based Linux system. An off-the-shelf i960 board with local memory is used for direct attachment. The other modules of FHiPPs are attached through the i960 bus. The modules comprise a DSP board, the FPGA board and an ATM interface for immediate high performance network access. The i960 processor is among other issues used for management purposes of FHiPPs resources. The FPGAs as well as the switch interconnecting them can be programmed dynamically during runtime. An integration of FHiPPs into a Linux system is available as prototype. Several issues have to be addressed due to its flexible programmability. Direct access to hardware as needed for FHiPPs requires system privileges. Therefore, new code segments must be integrated into the system kernel in order to setup and support a new hardware functionality. In the context of AMnet, so-called happlets (hardware applets) have been introduced for this purpose that contain all necessary code fragments and hardware description codes needed to install or modify the required hardware functionality. This part of the happlet is called the hardware code segment. The other part of the happlet contains the host code segment. It holds all information needed to transfer the hardware code onto the hardware, to re-initialize it and to install I/O routines for the new hardware functionality. Access to the hardware may be implemented directly by the happlet or via some device driver. The core of the flexible hardware integration is the Hardware Manager. It is a generic pseudo device driver that is included into the operating system kernel. It uses a simple software interface for data transfer between software-based functions and the hardware. It also supports flexible insertion and removal of new happlets. Additionally the hardware manager monitors
the usage of the different hardware units and interacts with the QoS Monitor and the AMnet Manager for proper system-wide resource management. The integration into the service module concept of AMnet is done by a so-called virtual service module. A virtual service module interfaces between the service modules and the hardware manager. This way, transparent hardware support can be provided. For interfacing with other service modules it uses the same generic module interface as all other service modules. It interfaces to the hardware manager via the pseudo device interface. Therefore, no hardware specific parts need to be implemented into the virtual service module. To support different hardware functions, the virtual service module requests a specific hardware function from the pseudo device via the ioctl system call and forwards all data from the incoming service modules to the hardware manager and all data from the hardware manager to the following service modules. The virtual service module itself does not access or modify the data at all.
4. Summary and Outlook Currently, research on active networking is carried out in the context of the Internet with the goal of improving application services. Performance and quality of service are addressed on one hand. On the other hand, rapid service creation referring to a higher flexibility in network services is of major interest. With capsules and programmable nodes two different concepts to achieve higher flexibility have been briefly introduced. The approach AMnet that was discussed in some detail combines both approaches. Capsules, for example, are applied for service location purposes. Programmable nodes are used with respect to service modules that operate on user data flowing through the network. The basic service concept of AMnet have been presented as well as some insight into the implementation of a flexible and efficient execution environment. Furthermore, the integration of flexible programmable hardware was briefly outlined. Currently, the development of a prototype is under way. Moreover, AMnet signaling is evaluated with simulation experiments considering issues such as service location delay and communication overhead.
5. References [Alex98]
D. Alexander, W. Arbaugh, M. Hicks, P. Kakkar, A. Keromytis, J. Moore, C. Gunter, S. Nettles, J. Smith; The SwitchWare Active Network Architecture; IEEE Network Magazine, Vol. 12, No. 3, May 1998 [Cald98] M. Calderon, M. Sedano, A. Azcorra, C. Cristian; Active Network Support for Multicast Applications; IEEE Network Magazine, Vol. 12, No. 3, May 1998 [Cann93] Steven McCanne, Van Jacobson, The {BSD} Packet Filter: A New Architecture for User-level Packet Capture, Proceedings of the Winter 1993 USENIX Conference, 1993 [Fabe98] T. Faber; ACC: Using Active Networking to Enhance Feedback Congestion Control Mechanisms; IEEE Network Magazine; Vol. 12, No. 3, May 1998 [Hand96] M. Handley; SAP: Session Announcement Protocol; IETF Internet Draft, November 1996; http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-00.txt [Lehm98] L. Lehman, S. Garland, D. Tennenhouse; Active Reliable Multicat; Proceedings IEEE Infocom, San Francisco, California, USA, March 1998
[RFC2236] B. Fenner; Internet Group Management Protocol, Version 2; RFC 2236, November 1997 [Tenn97] D. Tennenhouse, J. Smith, D. Sincoskie, D. Wetherall, G.Minden; A Survey of Active Network Research; IEEE Communication Magazine, Vol. 35, No. 1, January 1997 [Weth98] D. Wetherall, U. Legedza, J. Guttag; Introducing New Internet Servcices: Why and How; IEEE Network Magazine, Col. 12, No. 3, May 1998 [Witt98] R. Wittmann, M. Zitterbart; AMnet: Active Multicasting Network; Proceeding IEEE International Conference on Communications, ICC, Atlanta, GA, USA, June 1998
