AMnet: Heterogeneous Multicast Services based on Active Networking Bernard Metzler
Till Harbaum, Ralph Wittmann, Martina Zitterbart
Technical University Berlin Technical University Braunschweig
[email protected],
[email protected]
Technical University Braunschweig [harbaumjwittmannjzit]@ibr.cs.tu-bs.de
Abstract—AMnet flexibly provides communication services inside the network. It is based on active networking and on a hardware/software codesign in order to improve efficiency. Group communication is explicitly addressed since it is an important paradigm for existing and emerging networked applications. The goal of the AMnet approach is the provision of scalable quality-based support for heterogeneous group communication. It uses so-called service modules for efficient and flexible service support within intermediate systems. This paper gives an overview of AMnet. The design of an AMnode as an active intermediate system with hardware-supported service capabilities is presented. Furthermore, a simple control and signalling suite for heterogeneous multicast services is proposed. Keywords— Active Multicasting, Heterogeneous Group Communication, Adaptive Error Control
I. I NTRODUCTION Within the current Internet all systems interact via a handful of well-defined general purpose communication protocols. This way global interoperability is provided. However, heterogeneous service demands are often hidden if more than two participants interact, i.e. in the case of group communication. Such an approach restricts and oversimplifies multipeer services such as IP-multicast based multimedia communication. Many current approaches limit the group services to the weakest service named within the group. Making heterogeneous service demands explicit can greatly enhance multipeer communication services with respect to individual group participants. Adapting with heterogeneous services to heterogeneous network and end system conditions such as different delay or bandwidth bounds as well as different application demands within a multicast service is desirable. An application example can be seen in a receiver on a low-bandwidth link that should not be able to degrade the overall service quality of a collaborating group. The same holds for a group member that prefer low cost over high service quality. 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. In order to provide individually tailored services, so-called service modules are dynamically downloaded on network internal AMnodes. To achieve increased performance, hardware/software-codesign is incorporated into the AMnet architecture. Current Heterogeneity Support. Currently, different approaches to provide and signal heterogeneous communication services are proposed. The provision of heterogeneity can be distinguished in end-to-end support and network support. To provide heterogeneity, a possible action of the sender is to generate a hierarchical encoded output stream. Receivers can select different media qualities by joining appropriate multicast groups related to the coding levels (e.g., [1]). In [2] a communication model is described where hierarchical coding into one
output stream allows for lossy decompression at the receiver. Dependent on the loss ratio the original signal can be restored on a corresponding quality level. The model of integrated services within the Internet [3] is a step towards heterogeneous services. With RSVP heterogeneous resource reservation in a multicast communication session can be signalled. However, current flow specifications limit heterogeneity support to network performance parameters. A well-known way to place enhanced functionality within the network is the establishment of transport level [4] or application level gateways [5], [6]. Common to those solutions is the withdrawal of transparent end-to-end network operation. The gateway system which hosts the additional functionality is the peer entity of both sending and receiving system. Active Networking. Active Networking is a novel approach to provide application-specific functionality within the network. Two main approaches to realize active networking can be distinguished: via programmable switches or with so-called capsules [7]. Programmable switches execute pre-loaded application code on packets flowing through it. Capsules carry themselves the code to be executed on intermediate systems. The provision of multicast services with active networking technology appears to be a promising idea. Different research work shows how basic multicast control mechanisms could benefit from the application of both capsules [8] and programmable switches approaches [9]. In particular, sophisticated acknowledgment [10] and congestion control [11] mechanisms for multicast communication are proposed. However, with these approaches support for heterogeneous group communication is not considered. A programmable transport architecture with QoS guarantees is presented in [12]. This approach provides dynamic binding of flexible transport stacks to perform, e.g., media translation. But support for multicast communication is not mentioned. In summary, the potential of group communication with heterogeneous services has not been investigated in detail in the context of active networking. Moreover, specific hardware support has been addressed in [13] only with discussing signalling and resource management issues. AMnet addresses this open research topic and employs active node techniques with HW/SW codesign for the provision of application specific heterogeneous multicast communication services. The paper is organized as follows. Section II introduces AMnet for provision of heterogeneous multipeer communication and presents the basic architecture of an AMnode. In section III the execution environment for service modules and the hardware support for AMnode operations are discussed. Section IV covers the end-to-end management of heterogeneous multicast sessions. Section V closes with a summary and an outlook on ongoing re-
search. II. AM NET: ACTIVE M ULTICASTING N ETWORK AMnet is based on the placement of additional functionality inside the network. Service modules are responsible for the adaptation of data streams to specific service demands. These modules are dynamically loaded by Active Multicasting Nodes (AMnodes) which form the core building blocks of AMnet. AMnodes operate on the communication path between sender and receivers. In this sense they are active. In Figure 1 a multicast tree with AMnodes is shown. AMnodes adapt the data sent by sender S to provide different service levels (denoted by different line styles) to receivers. Each service level is represented by an AMnet flow. A goal of AMnet is to support service heterogeneity transparently to the origin of a data stream, i.e., AMnet follows a receiver oriented approach. Therefore, loadable service moduls with outof-band signalling are used instead of capsules, which has to be provided by the sender. Furthermore, a combined HW/SW solution is envisioned with AMnet. For hardware supported services different types of service modules are required than for software based services. This can not be easily realized with capsules. A
sensitive to its content. The latter requires that certain functionalities are activated dependent on the content of the data stream. In order to provide such content-based services, AMnodes need to manage application-specific knowledge at network level. However, AMnet may require additional efforts since services are dynamically selected and enforced based on actual data content. The heterogeneous multicast service should satisfy the following constraints: Media independency: the heterogeneity support should not be restricted to a dedicated media format. Sender 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). 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. B. Structure of an Active Multicast Node An AMnode consists of functional blocks for management and control as well as a flexible execution environment (see Figure 2) which are discussed in the following sections.
S
AMnode AMnet Flow
AMnet Manager
A A
Fi lt e rA
A R6 A
R1
AMnet Signalling
Error Control
ss
ig nm
QoS Monitor
QoS Info
en t
Service Environment
R5 R2
R3
Signalling
R4
QoS Filter
Service Modules
Module Configuration
Passive Node
Packet Filter
Data
Signalling
Hardware Manager
Fig. 1. Basic AMnet scenario
Data
from interface
Placing application-dedicated functionality within the network raises some questions: where should those services be located, how should they be established and maintained, how should a receiver be associated to a dedicated service and how should different services be managed within one multipoint communication association. In the following sections the AMnet approach for solving these problems is explained. A. Service Concept End-to-end service heterogeneity can be expressed at different levels of abstraction. It is limited by the granularity of offered service parameters and its corresponding protocol functions. From an application oriented point of view, heterogeneity might be extended to content-based service diversity such as content-based congestion policies or even individual acceptable media formats and, thus, corresponding media transformation services. These services might reduce the information contained in the data stream. An example can be seen in colored video that is transformed to black and white video. Utilizing the AMnet approach, within the network two types of services are simultaneously available: on application-specific requests services can be applied either on a complete data stream or
Fig. 2. Structure of an AMnode
AMnode Service Management. The service management functionality is common to all AMnodes. It is represented by the AMnet Signalling entity which implements the service control protocol. It is responsible for the announcement of local service capabilities of the node and for handling of service requests. AMnet Signalling contacts the local AMnet Manager which implements admission control and resource reservation. AMnode Node Management. Node management is the task of the local AMnet Manager in co-operation with a QoS Monitor (e.g., [14]). The AMnet Manager has to load and/or configure service modules to provide a requested service. Therefore, it receives needed information from AMnet Signalling. The configuration of a service is complemented with appropriate local resource management. 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 information 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 (c.f., IV-B) and admission control. The AMnet Manager further controls the Packet Filter. The Packet Filter is responsible for the correct classification of incoming data. Dependent on its content packets are assigned to appropriate AMnet flows or forwarded to the node management. Service Modules. 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. An example of a media translation module is a so-called QoS filter module [15]. It reduces the bandwidth requirements of MPEG1-encoded video streams for the transmission on low-speed links. That module is related to the filter architecture proposed in [16], but designed for the AMnet architecture. Currently, other QoS filters like video and audio filters and transcoders are under development for the AMnet framework. 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 packet would be misinterpreted by the sender and causes a semantic violation of the transport protocol (cf., Figure 3). sequence number data packet
3
6
2
2
5
4
1
3
2
1
adapted flow A
1
original data flow
Service Group A
AMnode data from sender SA
ACK to sender
Protocol Adaptation Module
vice se r from CK roup A g
Service Group B NA
CK
from se gro up B rvice
Fig. 4. Heterogeneous Error Control
If the AMnode is equipped with dedicated hardware CPU consuming or time critical processing of service modules can be offloaded. The hardware components execute service modules according to hardware/software codesign principles. This way, complex services, such as media translation services, can be provided much faster. The hardware-based service modules are transparently integrated into the common execution environment. A. Execution Environment It has been shown by different research work, that the placement of large parts of a communication system in application space supports more flexibility than in-kernel realizations while the performance can be comparable, e.g. [17], [18]. Following this approach for AMnode design flexible, dynamically loadable service modules such as media transformation or error control and most of transport and network layer functionality are located within application space. For every active AMnet flow module execution order can be changed on a per-packet basis. Thus, flexibility support is only limited by the availability of appropriate service modules. The tight interaction of specialized AMnet service modules and common transport and network functionality within one address space allows for the efficient integration.
adapted flow B
service modules
Fig. 3. Different sequence spaces after media transformation AMnet manager
AMnet signalling
Another example is the support of different acknowledgment strategies on different service groups (such as negative and selective positive acknowledgments due to group-specific loss probabilities) which should be transparent to the sender. Therefore, the acknowledgment strategies have to be semantically integrated to provide the sender a consistent view of the multicast communication session (see Figure 4).
configuration management
appl. area OS kernel
Hardware Support
QoS monitor
controlled network access packet preproc.
packet filter/ classifier
III. AM NODE P ROTOTYPE 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 environment for the AMnode was designed for HP 9000 computers running HP-UX. It is currently being ported to Linux. The execution environment is discussed in more detail in the following section.
from network
to network
Fig. 5. General structure of the execution environment
The kernel structure was slightly modified to securely export network access to the application space (see Figure 5). 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 in user space has only restricted access to network data. The demultiplexing support is based on the well-known Berkeley Packet Filter (BPF) [19]. The BPF interpreter is extended for more efficient demultiplexing on a large number of active endpoints and to handle fragmented packets. Due to the merging of similar filtering instructions from different associated connection endpoints (e.g. similar packet formats) our BPF/C (BSD Packet Filter/Classifier) acts as a packet classifier. The BPF/C is further used for some simple operations on outgoing packets to accomplish correct header syntax of application-level generated data. To restrict the number of necessary kernel/application boundary crossings within the receive path introduced a kernel-resident so called packet preprocessor (see Figure 5) has been introduced. The packet preprocessor introduces the possibility to flexible 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 flow specific collect all fragments of a higher level frame before presenting it to the application. Using this functionality, only one system call per received application frame is necessary. Flow-specific error control models such as the dropping of incomplete frames are directly supported. Further, the presentation of all fragments of one frame at once gives the possibility to efficiently employ Integrated Layer Processing (ILP) [20] programming style at application level: at least, all modules necessary for one AMnet service can be executed without intermediate path terminations due to still incomplete higher level frames. The programming language of the packet preprocessor is derived from the BPF and extended for the expression of additional functionality. Security checks on application-originated preprocessor programs are forced to prevent the insertion of malicious code. This includes restricted loop count, restricted memory references (memory alignment, referenced memory area) and the denial of variable jumps which is all straightforward to implement for an interpreter engine. BPF (Appl) BPF (Kernel) BPFC (Appl) BPFC (Kernel) UDP (Appl) UDP (Kernel)
300
Time in micro seconds
B. Enhanced Hardware Support Quality and performance of software based processing is limited by CPU and I/O performance of each AMnode. Furthermore, processing and relaying of data affect the overall throughput of the AMnode. Therefore, the integration of hardware support for active processing is an important goal of the AMnet approach.
400
350
(page mapping on the application/kernel boundary and further copy avoidance within the application space) it was possible to avoid excessive data copy operations within the data path. First measurements have shown an encouraging performance. The most critical parameter for user-space implementations of transport system functionality is the latency of data passing between network interface and user space transport system. Both in-kernel data demultiplexing performance and the overall delay between network interface and application-level data processing where measured (see Figure 6). The lower curves depicts latency between hardware-level packet reception and packet hand-over to the application. The upper curves in Figure 6 shows overall receive performance between network driver and packet reception at application level. For the measurement, 100 packets of 1024 byte per second and receiver where processed on a HP9000/73599 workstation. The number of simultaneous active flows was varied up to 25. Using the standard BPF as introduced in [19], the filter processing time lineary increases with the number of receivers filtering overhead for packet reception (see lower curves). Both, kernel-UDP/IP and the BPF/C scale well with an increasing number of active flows. Compared with conventional fixed kernel packet demultiplexing the provided flexibility of the BPF/C filtering engine introduces approximately 20 s additional delay compared to UDP/IP-performance without UDP checksumming1 . The performance of the demultiplexing process is restricted by the interpretative design of the BPF/C. Further improvements are possible, if the technique of dynamic code generation for the filter composition would be applied (e.g., [21]). Nevertheless, in the current stage of AMnode design main focus is on flexibility and portability. Using the BPF/C, the application-level performance is around an acceptable delay of 150 s for up to 15 receivers. Additional random delay is introduced by receiver process scheduling – see upper curves in Figure 6. A larger number of simultaneous receiving processes results in further increasing delay for all stacks.
250
B.1 FHiPPs - Flexible High Perfomance Platform 200
150
100
50
0 0
5
10 15 Number of active flows
20
25
Fig. 6. Filter and Network/API-Performance for Data Reception
With the application of an appropriate memory management
The flexible high performance platform (see Figure 7) is proposed for usage in an AMnode. It consists of two major subunits: DSP unit FPGA unit The DSP unit is built around the powerful TI320C80 DSP from Texas Instruments. This unit is, for example, used for high performance filtering of audio and video data. It supports for fast compression and decompression of multiple data streams. The FPGA unit is a FPGA and CPU based device. Its 32 MB local memory maps directly into the address space of the host 1 The checksum was switched off to compare the performance at the same level of functionality
system and allows for concurrent data manipulation by the host CPU, the CPU of the hardware unit and service modules placed on the FPGA unit. The FHiPPs is a general purpose unit [22] that offers advanced hardware support for an active multicasting node for operations protocol adaptation and media transforamtion.
Switch Control
FPGA 0
ATM NET
FPGA 4
FPGA 1
FPGA 5
1MB RAM
FPGA 6
FPGA 2
FPGA 7
glue logic
FPGA 3
ATM interface
NEC SAR Controller
MACH4-256 FIFO FPGA board
ATM interface
i960 bus
intel i960 io processor
PLX-PCI9060
32MB DRAM i960 based main unit
PCI
bus
Linux based AMnode
PCI
FIFO
bus
TI DSP TMS32C080
SRAM DSP unit
Fig. 7. The FHiPPs Hardware Platform
The eight FPGAs can separately be (re-)programmed and allow the execution of up to eight concurrently operating service modules. Each of these FPGAs has access to a local high performance memory to support local data buffering per FPGA. In addition each unit can access the 32 MB memory of the i960 unit to receive and transmit data between the host system and the i960 unit. FHiPPs can be integrated for example into a special architecture or simply into a general purpose workstation. With the local i960 CPU complex service modules can be transferred to the FHiPPs unit and be processed by the FPGA unit controlled and maintained by the i960 CPU. With this hardware support considerable service quality enhancements such as higher possible frame rates and lower transfer delay compared to software based approaches are expected. A similar approach is discussed in [23]. FHiPPs provides some additional features such as the local CPU and DSP units and flexible memory design on the FPGA unit.
AMnet Manager for proper resource management. The HW Manager manages memory and processing power on the hardware units for each service module. For AMnodes with additional hardware support, the AMnet Manager requests information about the available hardware units from the Hardware Manager integrated into the OS kernel. The Hardware Manager also holds state information on the load on each hardware unit and the kind of service modules currently available for each hardware unit. This information is forwarded to the AMnet Manager and the QoS Monitor to ensure proper HW resource management. B.3 The Virtual Service Module To allow dedicated hardware support within AMnet, access to the hardware needs to be integrated into the chain of service modules. Figure 8 shows the concept followed by AMnet. The HW handling is integrated into the OS kernel and works transparently to other service modules. The interfacing between the software based service modules and the HW based modules is done by a virtual service module (VSM). This module uses the standard AMnode interfaces for the communication with other service modules as well as an interface to a pseudo device that allows access to the Hardware Manager. The virtual service module is a very simple service module that is identical for all HW based service modules. For every HW based service module, a new instance of the VSM created. The VSM requests hardware services from the Hardware Manager and forwards incoming data from the previous service module to the Hardware Manager and data from the hardware unit thru Hardware Manager to the next service module. The virtual service module does not access or modify the passing data at all. AMnet Manager
service module
QoS Monitor
filter requests, filter i/o
packet filter hw host code code
pseudo device /dev/happlet
Hardware Manager
happlet a
virtual service module
virtual service module
appl. area
packet filter
OS kernel
hw host code code happlet b hw host code code
preprocessing x (host code)
preprocessing y (host code)
device driver 1
device driver 2
happlet c
host hardware 1 hw module x (hw code)
hardware 2 hw module y (hw code)
hardware units
Fig. 8. Hardware Integration
B.2 Hardware Integration Access to both parts of the FHiPPs, the FPGA/CPU based unit and the DSP unit, as well as future hardware systems is controlled by the so-called Hardware Manager (see Figure 8). The Hardware Manager opens and accesses the hardware units via their device drivers and controls the access to the hardware. Therefore, the Hardware Manager interacts with the hardware units to monitor the usage of processing power and memory. This information is collected by the QoS Monitor and forwarded to the
B.4 Hardware Applets If the AMnet Manager needs to activate a new service module, it requests this module for all hardware units currently available from a module repository (see chapter IV-B). The AMnet Manager expects a file containing the description of the hardware based service module. This file is called a happlet (hardware applet). It contains at least two code segments. One segment (host
IV. S ERVICE M ODEL The AMnode and the HW/SW integration form the technical basis for the provision of heterogeneous services with AMnet.
This section describes the service model and the control functions of AMnet in more detail. A. Service Hierarchies 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 [24]. Figure 9 shows an example data distribution tree, where AMnodes provide different levels of service quality to their local multicast receiver groups.
Service Announcement MC group
Original MC-Stream
Adapted MC-Stream TT L= a
C
TT L= x
A
Adapted MC-Stream sender
Adapted MC-Stream
receiver
X
TTL = y
S
c L= TT
D
TTL= b
B
Adapted MC-Stream
S
d TTL=
code) is to be mapped into the kernel space, allowing the kernel to preprocess incoming data and to communicate with the hardware. The second segment (HW code) is used to initialize the hardware to perform the task of the service module. Once the AMnet Manager received all service modules and happlets, it initializes their setup. An happlet is initialized by creating a new instance of the virtual service module which connects to the pseudo device and requests the particular happlet. All VSMs are using the same pseudo device (/dev/happlet), the pseudo device distinguishes the different instances of the VSM by individual file descriptors that they use for accessing the device. Once a VSM has opened the connection to the pseudo device it requests a specific happlet via the ioctl system call. This request is forwarded to the Hardware Manager which receives the happlet from the AMnet Manager. The Hardware Manager loads the host code segment of the happlet into the kernel space and forwards the HW specific segment of the happlet to the device driver. The device driver transfers the HW code onto the HW unit and starts the execution of the code on the unit. From now on all communication to the device driver takes place via the happlet host code. The host code implements preprocessing which includes buffering to ensure, that enough data is available for the service module to complete its work. It handles all input and output from the HW unit and informs the HW Manager about the current state of the HW based service module. During operation, the data to be processed is forwarded to the HW unit and the current instance of the VSM is stopped. Other service modules on the host system may now be handled by the host CPU concurrently to the processed HW based module. Once the HW module finishes processing the data, the sleeping instance of the VSM is reactivated and a pointer to the processed data is forwarded via the VSM to the next service module. This may be another instance of the VSM or a software based service module. A service module can have more than one input or output (e.g. filters transcoding a combined MPEG audio/video stream into seperate audio and video streams). If the VSM needs to access a service module with multiple I/O streams, it opens additional connections to the pseudo device (/dev/happlet) for the extra data streams. With some HW units (e.g. the FHiPPs i960 unit) it is possible to map the HW memory into the user address space. This feature may be used to allow HW and SW service modules to operate on the same data. The current approach does not support this feature, since most service modules won’t work on static data and need to copy the data while processing them, anyway. Furthermore, the I/O performance of memory on the hardware unit which is mapped into the hosts address space is much lower than the performance of the hosts main memory. Therefore, storing the processed data on the hardware unit and forcing all service modules, including the software based, to work on this external memory would decrease the overall performance. The hardware support for AMnet is currently only available on the Linux platform.
AMnode AMnet service group
Fig. 9. Example multicast tree
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 hierarchically ordered. AMnodes are member both, the parent service group and the child service group (cf., Figure 9). 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 packets issued by the corresponding active node (see Figure 9). 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. 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. The service level groups are distinguishable by their multicast-addresses. The hierarchical order of service level groups allows for an efficient establishment of different quality levels within a session. One distinct service quality might be easily derived from another already available quality level if, for instance, only a different
(weaker) error control policy for network overload conditions has to be inserted into the already adapted data stream. 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, packetbased service 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. B. Service Control In contrast to the capsule approach, AMnet is not based on executable code to be transmitted in data packets. Instead, with AMnet signalling 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. Moreover, separation of signalling and data transfer decouples AMnet from the used transfer protocols. In a first prototype implementation RSVP was used as signalling protocol [25]. 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 signalling model for AMnet is being designed. It consist of the following components: Session announcement, service announcement, service module repository, and service access. Session Announcement. A session announcement is advertised by a sender on a separate multicast group - the so called session control group. In this group every AMnet session is announced similiar to the well-known Session Announcement Protocol (SAP) [26] 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 so-called service announcement group.
Service Announcement. 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 signalling 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. Service Module Repository. 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. Service Access and Localization. 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 sessions 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 requests 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. V. C ONCLUSION
AND
O UTLOOK
In this paper the AMnet approach for the provision of heterogeneous group communication was presented. AMnet is based on the active networking paradigm and addresses HW/SW codesign. So-called service modules can be dynamically loaded and activated within the network. These service modules provides for individual services within a heterogeneous multicast group. Innovative steps of AMnet are the design of an active intermediate system which allows for efficient and flexible service adaptation. To this end, a flexible execution environment for the AMnet functionality was realized. Moreover, hardware support for performance critical operations is included. Current work is focused on the signalling of heterogeneous services. Protocols for the announcement and control of heterogeneous services are under development. A further step will be the design of a descriptive language for the signalling of extended service capabilities such as media transformation or individual error control schemes. R EFERENCES [1] Steven McCanne, Van Jacobson, and Martin Vetterli, “Receiver-driven Layered Multicast,” in ACM SIGCOMM’96, San Francisco, USA, Aug. 1996. [2] Andres Albanese, Johannes Bl¨omer, Jeff Edmonds, Michael Luby, and Madhu Sudan, “Priority Encoding
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
Transmission,” IEEE Transactions on Information Theory, vol. 42, no. 6, 1996. R. Braden, D. Clark, and S. Shenker, “Integrated services in the internet architecture: an overview,” RFC 1633, ISI, June 1994. H. Balakrishnan, S. Seshan, E. Amir, and R. Katz, “Improving TCP/IP Performance over Wireless Networks,” in Proc. of 1st ACM Conference on Mobile Computing and Networking, Berkeley, California, Nov. 1995. Elan Amir, Steve McCanne, and Hui Zhang, “An application level video gateway,” in Proc. ACM Multimedia ’95, San Francisco, CA, Nov. 1995, ACM. Y. Chawathe, S. A. Fink, S. McCanne, and E. A. Brewer, “A Proxy Architecture for Reliable Multicast in Heterogeneous Environments,” unpublished. David L. Tennenhouse, Jonathan M. Smith, W. David Sincoskie, David J. Wetherall, and Gary J. Minden., “A Survey of Active Network Research,” IEEE Communications Magazine, vol. 35, no. 1, pp. 80–86, Jan. 1997. David Wetherall, Ulana Legedza, and John Guttag, “Introducing New Internet Services: Why and How,” IEEE Network Magazine, vol. 12, no. 3, pp. 12–19, May 1998. D. Scott Alexander, William A. Arbaugh, Michael W. Hicks, Pankaj Kakkar, Angelos D. Keromytis, Jonathan T. Moore, Carl A. Gunter, Scott M. Nettles, and Jonathan M. Smith., “The SwitchWare Active Network Architecture,” IEEE Network, vol. 12, no. 3, pp. 29–36, 1998. Mar´ia Calder´on, Marifeli Sedano, Arturo Azcorra, and Cristian Alonso, “Active Network Support for Multicast Applications,” IEEE Network Magazine, vol. 12, no. 3, pp. 46–52, May 1998. Theodore Faber, “ACC: Using Active Networking to Enhance Feedback Congestion Control Mechanisms,” IEEE Network, vol. 12, no. 3, pp. 61–65, 1998. Jean-Francois Huard and Aurel A. Lazar, “A Programmable Transport Architecture with QoS Guarantees,” IEEE Communications Magazine, vol. 36, no. 10, pp. 54– 62, Oct. 1998. William S. Marcus, Ilija Hadzic, Anthony J. McAuley, and Jonathan M. Smith, “Protocol Boosters: Applying Programmability to Network Infrastructure,” IEEE Communications Magazine, vol. 36, no. 10, pp. 79–83, Oct. 1998. M. Zitterbart, “User-to-User QoS Management and Monitoring,” in Proceedings IFIP Workshop on Protocols for High Speed Networks, Sophia Antipolis, France, Oct. 1996. R. Wittmann and M. Zitterbart, “Towards support for heterogeneous Multimedia Communications,” in Proc. FTDCS’97, Stephen S. Yau, Ed., Tunis, Tunisia, Oct. 1997, pp. 336–341, IEEE Computer Society. N. Yeadon, F. Garcia, D. Shepherd, and D. Hutchinson, “Continuous media filters for heterogeneous internetworking,” in Proceedings of the Conference in Multimedia Computing and Networking 1996, San Jose, California, January 1996. C. A. Thekkath, T. D. Nguyen, E. Moy, and E. D. Lazowska, “Implementing Network Protocols at User Level,” in Proc. ACM SIGCOM Conference, Ithaca, USA, Sept. 1993. Thorsten von Eicken, Anindya Basu, Vineet Buch, and
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
Werner Vogels, “U-Net: A User-Level Network Interface for Parallel and Distributed Computing,” in Proc. of the 15th ACM Symposium on Operating Systems Principles, Copper Mountain, Colorado, USA, Dec. 1995. Steven McCanne and Van Jacobson, “The BSD Packet Filter: A New Architecture for User-level Packet Capture,” in Proceedings of the Winter 1993 USENIX Conference: January 25–29, 1993, San Diego, California, USA, USENIX Association, Ed., Berkeley, CA, USA, Winter 1993, pp. 259–269, USENIX. David D. Clark and David L. Tennenhouse, “Architectural Considerations for a New Generation of Protocols,” in SIGCOMM Symposium on Communications Architectures and Protocols, Philadelphia, PA, Sept. 1990, ACM, pp. 200– 208. D. Engler and M. Kaashoek, “DPF: Fast, Flexible Message Demultiplexing using Dynamic Code Generation,” in Proceedings of SIGCOMM ’96, 1996. M. Zitterbart, T. Harbaum, D. Meier, and D. Br¨okelmann, “Efficient Routing Table Lookup for IPv6,” in IEEE Workshop HPCS ’97, Chalkidiki, Greece, June 1997. Ilija Hadzic and Jonathan M. Smith, “On-the-fly Programmable Hardware for Networks,” in Proc. IEEE Globecom ’98, Sydney, Australia, Nov. 1998, IEEE. B. Fenner, “Internet group management protocol, version 2,” Request for Comments (Proposed Standard) 2236, Internet Engineering Task Force, Nov. 1997. R. Wittmann and M. Zitterbart, “AMnet: Active Multicasting Network,” in Proc. of Intern. Conf. on Communications (ICC’98), Atlanta, GA, USA, June 1998, IEEE. Mark Handley, “SAP: Session Announcement Protocol,” Internet Draft, Internet Engineering Task Force, Nov. 1996, Work in progress.
