Providing heterogeneous multicast services with AMnet

46 JOURNAL OF COMMUNICATIONS AND NETWORKS, VOL.3, NO.1, MARCH 2001

Providing Heterogeneous MulticastServices with AMnet

Till Harbaum, Anke Speer, Ralph Wittmann, and Martina Zitterbart

Abstract: AMnet is a framework for flexible and rapid ser-vice creation and provides primarily heterogeneous user-tailoredgroup communication services. AMnet is based on Active andProgrammable Networking technologies and uses active nodes(AMnodes) located within the network to execute so-called servicemodules for the provision of individual group communication ser-vices. It is, however, not limited to group communication sinceit provides a rather generic framework. The AMnode design isshaped for the efficient execution of flexible loadable service mod-ules, including dedicated hardware support.

Index Terms: Active networking, heterogeneous group communi-cation, rapid service creation, programmable hardware.

I. INTRODUCTION

Many evolving applications on the Internet are based ongroup communication, for example distributed computing, tele-collaboration, distance learning and information dissemination.This raises the need of efficient and scalable group services forproper communication support. Progress in providing these ser-vices is very slow because the network infrastructure is inflex-ible and the introduction of new services and protocols to en-hance the functionality of the network typically requires longglobal standardization processes. Generally, this leads to the de-mand of rapid service creation which allows the flexible andrapid introduction of new services in global networks. More-over, rapid service creation can open the network to a largercommunity of application-oriented service providers and, thus,stimulate the development of new networked services and ap-plications. This way, individually tailored group services, asrequired by many of the evolving applications on the Internet,could be introduced, tested and, therefore, provided quickly.Moreover, innovations with respect to networked applicationscould profit considerably.

Another challenge to take into account with AMnet emergeswith group communication: The service requirements of groupmembers may vary dependent on the individually available per-formance of the network access, the type of end system beingused, the willingness to an extra payment for a high servicequality and the like. This leads to heterogeneous service require-mentswithin a group and calls for adequate communication sup-

Manuscript received November 1, 2000.T. Harbaum and A. Speer are with the Institue of Telematics, University of

Karlsruhe, Germany, e-mail: [email protected]. Wittmann is with Ericsson Eurolab, Germany. The presented work is out-

side his work at Ericsson Eurolab.M. Zitterbart is full professor in computer science at the University of Karl-

sruhe, Germany.

1229-2370/01/$10.00 c� 2001 KICS

Fig. 1. Basic AMnet scenario.

port. In most current approaches that address group communi-cation the service provided to individual group members is af-fected by the group member with the lowest service capabilities.Such an approach, however, is not acceptable for multimediaand collaborative applications in heterogeneous networking en-vironments. Take, for example, a group member having a PDAas end system and, thus, drastically reducing the video capa-bilities within a group. This is clearly not desirable in manycases, as for example tele-conferencing and distance learning.Therefore, adequate approaches are needed to support hetero-geneous group communication with individual service require-ments properly.

The framework AMnet presented throughout this paper ad-dresses rapid service creation in the context of heterogeneousgroup services. Via AMnet, user-tailored data streams canbe made available to individual group members. Followingthe concepts of Active and Programmable Networking tech-nologies, AMnet uses active nodes—so-called AMnodes (seeFig. 1)—located within the network to execute service modulesfor the provision of individual group services. A typical sce-nario for the application of AMnet is shown in Fig. 1. Groupmembers participating in a tele-collaboration have different re-quirements considering the desired QoS (Quality of Service) be-ing received. Through adaptation of the data streams within theAMnodes, different service levels can be provided, as requestedby the receivers.

However, AMnet is not limited to group communication ser-

HARBAUM et al.: PROVIDING HETEROGENEOUS MULTICAST SERVICES WITH AMNET 47

vices. Moreover, the services supported by AMnet can be man-ifold, including application-oriented issues, such as video filter-ing, the provision of dedicated support for communication ser-vices, such as reliable multicast [1], and on the other hand appli-cations in the context of point-to-point communication. In orderto demonstrate the feasibility of AMnet various service moduleshave been developed, including video filtering and individualcontent-based error control [2]. Modules for the provision ofreliable multicast mechanisms are currently implemented andtested.

Overall, AMnet provides a generic framework for rapid ser-vice creation that is open to new emerging application: Mech-anisms for their provision only have to be implemented as ser-vice modules and can be easily introduced into AMnet, after-wards. The service modules needed in the AMnodes for pro-viding the requested service are loaded on-demand which leadsto a receiver-oriented approach and, therefore, raises the needof an out-of-band signaling protocol. In order to avoid globalstandardization of such a signaling protocol, Active Networkingtechnologies are used again as explained in Section II-C.

The paper is organized as follows. Section II provides anoverview of the AMnet service model describing how serviceheterogeneity is provided and which mechanisms are used forservice location and announcement. Moreover, the basic designdecisions of the AMnet signaling protocol are presented. In Sec-tion III the design of an AMnode and a platform for flexiblehardware support of the AMnodes are introduced. An overviewof related work as well as a short summary and an outlook onfuture work concludes the paper.

II. AMNET SERVICE MODEL

Providing enhanced services to networked group applicationscan be seen as the major goal of AMnet. In order to achieve this,service modules can be placed and utilized in the network on de-mand. This raises some questions: where should those servicesbe located, how should they be established and maintained, howshould a receiver be associated to a dedicated service and howshould different services be managed within a session? A ses-sion, in this context, refers to a communication scenario wherea designated sender issues a data stream which can be receivedby several group members without or with adaptation, i.e., dif-ferent service levels can be provided. Basically, Fig. 1 depictsan AMnet session for a tele-collaboration application where theparticipants differ in their Quality of Service requirements (QoSA, B, and C).

Core components of the AMnet approach are

� IP-multicast-based service level groups that provide a ded-icated service level within an AMnet session, and

� an active signaling protocol—AMnet signaling—that isused for location and placement of service modules.

A. Providing Heterogeneous Service Levels

Service heterogeneity within a session needs to be bound to amanageable degree of diversity. Therefore, receivers with simi-lar service demands are logically grouped into distinct multicastreceiver groups, so-called service level groups. Service level

Fig. 2. Multicast tree with service level groups.

groups are distinguishable by their multicast address. Receiversjoin the corresponding service level group on demand throughthe mechanisms of the Internet Group Management Protocol(IGMP) [3]. A service level group within a communication ses-sion represents all receivers whose service demands can be re-solved with a single multicast service. Each service level grouprepresents a different view onto the same original data corre-sponding to the adaptation within AMnodes. For example, inFig. 1 three different service level groups are available, provid-ing services with QoS A, B, and C, respectively.

The service offered by AMnet can be described by a tree ofservice level groups as depicted in Fig. 2. The service of a groupis supported by an AMnode through the utilization of appropri-ate service modules. The actual service may be derived fromthe original data stream (see AMnode 2 in Fig. 2) or from theservice of another service level group (see AMnode 3 in Fig. 2).The scope of an AMnet service group is limited by the actualTime-To-Live (TTL) value assigned to packets issued by thecorresponding AMnode. Note that the provision of service levelgroups is possible without introducing any new protocol. It issolely based on IP multicasting technologies and the availabilityof some AMnodes in the network.

The establishment of service level groups permits the provi-sion of different service qualities within one region without theservices interfering each other. Two data streams with differentmedia formats or individual error control may sometimes co-exist on a communication link and have to be distinguishable bythe corresponding receivers. This is accomplished through theunique multicast address being assigned to each service levelgroup.

The hierarchical arrangement of service level groups allowsfor an efficient establishment of different levels of service qual-ity within a session. The service quality experienced at the re-ceiver is a function of the service level provided by the AMnodeand current network conditions between the AMnode and eachindividual receiver. One distinct service quality might be eas-


Fig. 3. Overview of the AMnet service control.

ily derived from another already available level. If, for instance,a different (weaker) presentation quality of a video stream isrequested, an appropriate service module can be placed on anAMnode to further modify the already adapted data stream. Theservice within a group can only differ in performance-oriented,packet-based service parameters, such as delay or loss probabil-ity. Other parameters which define the content-based nature ofthe service are homogeneous (e.g., media format, acknowledge-ment strategy, error control) within a service level group. Thedistinction of services can be triggered by both: performance-oriented parameters and content. Consider, for example, twodifferent receivers with very different loss probabilities. In thatcase, different acknowledgement strategies and error controlmechanisms might be necessary which require different servicelevel groups. The hierarchical arrangement of services does notautomatically imply hierarchical degradation of all service pa-rameters. Some parameters can be provided unchanged, otherparameters even improve. As an example, the insertion of a newservice can improve media playback quality due to less jitter atthe cost of higher, but uncritical delay. This could be useful incase of video distribution, for example.

B. Service Location and Announcement

AMnet provides signaling procedures to locate and announceservices as well as to establish and maintain user-tailored ser-vices on AMnodes. Announcement procedures are highly basedon IP multicasting technologies. For receiver-oriented locationand placement issues, however, the introduction of new appro-priate signaling procedures is needed. In order to avoid globalstandardization of a signaling protocol, Active Networking tech-nologies are applied. This means, signaling data units carry pro-grams that are executed on the AMnodes in order to explore thelocation of that AMnode or to analyze the performance of theAMnode for the proper and efficient placement of a new service.As a result, control of AMnet services is maintained completelyout-of-band with respect to user data transfer.

The following components are part of the service control.Fig. 3 shows their correlation:

� session announcement,� service announcement,� service module repository, and

v = 1.0n = 0312199913416903411615d = Pathfinderi = broadcast of NASA mission Pathfindero = [email protected] = 134.169.34.116a = 225.1.2.3/4567t = 03.12.1999 10.00 15.00

Fig. 4. Example of a session announcement.

� service access (join of service level groups).

Session Announcement: A session announcement is adver-tised by a sender on a separate multicast group—the so-calledsession control group (see Fig. 3 (1)). In this group every AM-net session is announced similar to the well-known Session An-nouncement Protocol (SAP) [4] of the MBone. SAP itself wasnot utilized to avoid the use of its standardized port and since theoverhead of introducing the needed new data fields and function-alities was considered as too high.

A session announcement consists of attribute-value-pairs,built of a letter—representing the attribute—and the appropri-ate value. This is similar to the Session Description Protocol[5]. Attributes of a session announcement are

� protocol version (v),� session number (n),� session description (d),� further session descriptions (i),� owner of the announcement (o),� address of the sender (s),� address of corresponding service announcement group

(a), and� time stamp (t).

Fig. 4 gives an example for a session announcement. It isan announcement of protocol version 1.0. Attribute n (ses-sion number) contains a session id which uniquely identifiesthe session belonging to the announcement. This number isincreased, if announcement parameters change, to enable re-ceivers to spot obsolete announcements. The announcementbelongs to the propagation of the NASA mission Pathfinderwhich is described by the attributes d (session description) andi (further session descriptions). The announcement stems [email protected] given by the attribute o (owner ofthe announcement). The address of the session sender and theIP-multicast address of the corresponding service announce-ment group are identified by the attributes s and a. t specifiesthe time, the session is active. Based on the session description(including bandwidth and delay requirements) receivers decidewhether to join a session and which service modules have to berequested to receive the session at the desired service level (seeFig. 3 (3)).

Service Announcement: Whereas the session control groupprovides information of all available AMnet sessions, the ser-vice announcement group forms a database of the currentlyavailable AMnet services for a given session. This group is usedfor the advertisement of heterogeneous service capabilities anddemands, i.e., all available service level groups are announcedin this group (see Fig. 3 (2)). Also the session itself—the orig-


v = 1.0n = 0312199913416903411615m = 031219991341690351172a = 0312199913416903501012d = MPEG-1 QoS Filters = 188.1.172.46g = 224.13.24.8/2904f = IP/UDP/MPEG-1r = 1.5 Mbpsp = 134.169.34.116 134.169.34.1 188.1.4.29 188.1.172.46

Fig. 5. Example of a service announcement.

inal service—is announced here. All session participants needto be member of the service announcement group to be able tolearn about available services (see Fig. 3 (4)). If a new service isestablished by an AMnode, the node advertises the appropriateservice description within this group.

The structure of the service announcements is similar to thesession announcements. However, they contain further informa-tion about the type of the service, the format of the data stream,the address of the destined service level group, as well as thepath the service announcement took from the service originatorto a specific receiver. The path is included in order to be able toreconstruct the path for signaling purposes (see Section II-C).

Fig. 5 shows an example of a service announcement of a videofilter. The service description is given by the attribute d. In addi-tion, the protocol version (v), as well as ids to uniquely identifythe service announcement (n), the corresponding session an-nouncement (m) and the corresponding service announcement(a), if the service works with an already adapted data stream,are specified. Attribute s identifies the address of the origi-nator of this announcement and g the multicast address of thecorresponding service level group. The format of the adapteddata stream is given by attribute f (in this example an MPEG-1 stream embedded in UDP/IP) with r describing the neededresources (here bandwidth). The path of the service announce-ment is identified by the values of attribute p.

Service Module Repository: The service module repositoryis a distributed database which contains service modules andtheir description. The purpose of the repository is to make ser-vice modules available to an AMnode in case that a servicemodule is not already cached at that node (see Fig. 3 (5a) and(5b)). Service modules can be stored in the service repositoryby AMnet users and network management procedures follow-ing enhanced security mechanisms.

The analysis of the possible requirements for the service mod-ule repository showed that they can widely be fulfilled by anLDAP server. Therefore, LDAP [6] was selected for the designand implementation of the repository. Other reasons for utiliz-ing LDAP are its easy use and its extensibility as well as theavailability of Java implementations (e.g., from Netscape). In[7] a suggestion for recording Java objects into an LDAP direc-tory information tree is given. Table 1 gives the attributes whichdescribe the service modules. With this description the modulescan be stored and recorded directly in the LDAP server.

With mechanisms for the controlled access to and the storageof service modules in the repository security can be enhanced.It is for example possible to forbid untrusted third-party usersto store modules as well as it is possible to type-check the code

Table 1. Description attributes for service modules.

Attribute MeaningmoduleName name of the serviceserviceType e.g., QoS filter or error controldescription description of the serviceos operating system needed by the serviceosVersion version number restriction for the operating systemformat data format in which the service is stored within the

directory information treemoduleType mode of the service (e.g., Java, shared library)moduleData service dataobjectClass if the service is a Java module, objectClass has to give

the name of the executing classclassName if the service is not just Java code, className has to

give the name of the class which starts that service

of the modules to be stored. Moreover, downloading of specialtypes of service modules can be restricted for certain AMnodes(e.g., modules which interfere the default kernel processing).

Service Access: The mechanism for service access followsthe same principles as the current practice in the MBone. If aparticipant wants to use an AMnet service, e.g., video filter orenhanced error control, the participant checks by joining the ses-sion’s service announcement group whether the desired serviceis already available. If the service exists, the participant sim-ply joins the associated group of an appropriate AMnode thatprovides that service (see Fig. 3 (5) and (6)). If multiple suchAMnodes are available, a well-suited node needs to be identi-fied. If the service does not already exist, the participant may askan appropriate AMnode to download the service from the ser-vice module repository and to announce its establishment (seeFig. 3 (5a)–(5c)). The following subsection will outline the cor-responding procedures in more detail.

C. Signaling AMnet Services

An important aspect of AMnet signaling is the selection of anappropriate AMnode for service provision. This selection de-pends on the type of the requested service and on the metricspropagated by the receiver of the session towards the AMnode.For example, one receiver may select a video filter service whichhas to be placed as close to the session sender as possible,whereas another receiver may choose a protocol adaptation ser-vice which has to be placed near by the receiver itself. For thepurpose of selecting an appropriate AMnode, each session re-ceiver comprises a performance meter. According to the met-rics and according to the description of the desired service theperformance meter rates the information given by the serviceannouncements the receiver gets from the joined service an-nouncement group. From these information the performancemeter can determine whether an appropriate service is alreadyin operation.

For the selection procedure, two cases need to be distin-guished:

� the desired service is already provided at the time a re-ceiver joins the session, or

� no appropriate service is available.

In the first case the selection takes place within the set ofAMnodes that already provide the desired service, in the sec-


ond case it is selected within the set of AMnodes that fulfillthe propagated metrics and, therefore, potentially can providethe requested service. In both cases active packets—evaluationpackets—are used for the selection. Because the suitability of anAMnode corresponds directly to the type of the requested ser-vice and the receivers’ propagated metrics, every service mod-ule has a dedicated evaluation procedure stored together withthe service module in the service module repository. This eval-uation procedure is to be encapsulated in the evaluation packets.In addition, these packets contain the following data:

� the path the session announcement took from the ses-sion sender to the receiver; this information is includedin the service announcement and is needed because ev-ery AMnode has to know its parent AMnode to correctlyforward the evaluation packet (see below). Caching thisinformation in the AMnode is considered to scale not verywell.

� the address and the result of the best matching AMnodeso far resp. the address and the result of the actually eval-uated AMnode (see below),

� the description of the desired service, and� the evaluation procedure to be executed on each AMnode

which receives such an evaluation packet to determinewhether it satisfies the requirements of being a serviceprovider.

If one or more AMnodes concurrently provide the desired ser-vice, the performance meter of the session receiver issues theevaluation packet to each of these AMnodes in order to evaluatethem according to the propagated metrics. This is done per uni-cast since it is assumed that there is only a very limited numberof corresponding AMnodes available. The AMnodes attach theevaluation results to the evaluation packet and return it to the re-ceiver. After the performance meter has collected all responsesor a timeout occurs, it selects the best matching AMnode amongthe queried ones and makes the receiver join the appropriate ser-vice level group.

In case no AMnode provides the requested service yet or noproviding AMnode fits to the propagated metrics a slightly dif-ferent selection procedure is used. That means in the worst case,both selection procedures take place one after another. This se-lection procedure uses a different mechanism—the basic treesearch—to determine a suited AMnode. Again, the performancemeter of the session receiver issues an evaluation packet. Thisis forwarded to the closest AMnode (AMnode 2, Fig. 6). Thisnode can be identified by the path-entry included in the evalu-ation packet and known from the service announcement. Ac-cording to the description of the desired service contained in thereceived evaluation packet and according to the available noderesources, the AMnode management decides whether the nodeis capable of providing the service. In the positive case, it ex-ecutes the evaluation program and incorporates the result intothe evaluation packet. This, however, is only performed if theactual AMnode fits better than the AMnode previously notedin the packet—if there is any. Therefore, the evaluation packetcontains at most one address: the address of the best match-ing AMnode so far. If the service can not be provided, becauseof limited resources or similar reasons, or if a better matching

Fig. 6. Scheme of the basic tree search.

AMnode is already cached in the evaluation packet, the packetremains unchanged.

With the basic tree search the actual evaluated AMnode doesnot directly respond back to the session receiver. In contrast,it forwards the evaluation packet to its parent AMnode on itsway to the sender (AMnode 1, Fig. 6) of the data stream to beadapted. At this node the admission test and evaluation takesplace again. This is repeated until the evaluation packet arrivesat the last AMnode subsequent to the sender (AMnode 1, Fig. 6).This AMnode is responsible for the interpretation of the evalu-ation result carried by the evaluation packet. It unicasts a ser-vice request for the desired service—known from the descrip-tion in the evaluation packet—to the best matching AMnode(e.g., AMnode 2, Fig. 6).

After the selected AMnode received the request to providethe service, it downloads the appropriate service from the ser-vice module repository and announces the establishment in theservice announcement group. Since the session receiver whichstarted the whole procedure is a member of the service an-nouncement group it learns about the availability of the de-sired service and subsequently can join the corresponding ser-vice level group.

Session and service announcements are sent periodically.Therefore, it is possible to notice newly available AMnodes—they will be included in the path-description of the serviceannouncement—and it is as well possible to include them dy-namically into the evaluation.

Since the basic tree search mechanism is limited to AMnodesbeing located on the multicast tree, an extended tree searchmechanism is under development. AMnodes beyond the pathmight as well be able to provide the service and fulfill the met-rics even in a better way than the AMnodes on the path. The ex-tended tree search can possibly use the concepts of IP-multicastand forward the evaluation packets to the neighbor AMnodes ofthe AMnodes on the multicast tree. Therefore, the AMnodeshave to be reachable over a known multicast address. Then,for example, a ring search evaluation can be processed on theAMnodes beyond the multicast tree limited through a TTL. Thevalue of the TTL has to be decreased with increasing distancefrom the receiver.


Fig. 7. Structure of an AMnode.

III. DESIGN OF AN AMNODE

The adaptation of data streams takes place in AMnodes (seeFig. 1). Therefore, AMnodes must be capable of executing ser-vice modules that are downloaded on demand. Furthermore,AMnet signaling takes place in AMnodes. The design of anAMnode is similar to active nodes being developed within re-lated projects. One of the major differences is that AMnodescan provide optional hardware support for the execution of ser-vice modules. Furthermore, an efficient demultiplexing path isprovided, as described in [2].

A. Node Architecture

An AMnode consists of different functional blocks (seeFig. 7). They are responsible for the management of active nodefunctionality, for the AMnet control protocols and for the provi-sion of a flexible execution environment. Each functional blockwill be briefly introduced in the following.

AMnode Service Management: The service managementfunctionality is common to all AMnodes. It is represented bythe AMnet signaling entity and is responsible for the announce-ment of local service capabilities of the node as well as for thehandling of service requests. AMnet signaling contacts the lo-cal AMnet manager which implements admission control andresource reservation.AMnode Node Management: Node management is the task

of the local AMnet manager. The AMnet manager has to loadand/or configure service modules to provide a requested service.Therefore, it receives needed information from AMnet signal-ing. The configuration of a service is complemented with ap-propriate local resource management. The AMnet manager fur-ther controls the packet filter which is responsible for the cor-rect classification and demultiplexing of incoming data. Depen-dent on its content packets are assigned to an appropriate servicemodule or a chain of service modules or they are forwarded tothe node management.Execution Environment: Within the execution environment

pre-loaded or on-demand-loaded service modules are executed.It is designed for a flexible establishment of receiver-tailoredAMnet services. Loading and activation of service modules iscontrolled by the AMnet manager of an AMnode.

For performance reasons, AMnet currently supports three im-plementations of service modules:

� Java: These modules are coded in Java and, due to Java’sportability features, are runnable on every AMnode. It isassumed that each service module is at least available as aJava code.

� Native: Modules of this type are coded in a compiled lan-guage, most probably C, and compiled for a specific ar-chitecture, operating system, etc. Obviously, with thesemodules a better performance can be achieved comparedto Java modules. However, they salvage a security risk,since only limited measures to protect the node from ma-licious service modules exist.

� Happlets: A happlet is a service module coded in a spec-ification language for hardware. It is executed on a dedi-cated programmable hardware component, which may op-tionally be part of an AMnode. Happlets are expected toaccomplish even complex operations very fast, thus, lead-ing to an improved overall performance of the AMnodewhich improves the experienced end-to-end service qual-ity. Typical service modules that may be implementedas happlets can be found in the context of video filtering(e.g., Huffman coding/decoding). It should be noted thatnot every AMnode is required to provide additional pro-grammable hardware—it is just an option.

Since different service modules might be required by differ-ent members of a group, the approach of capsules—even withcaching—is not favorable for the provision of heterogeneousgroup services.

The execution environment is discussed in more detail in [2].The design of the prototype node allows for the flexible opera-tion of AMnode functionality. Its architecture is not restrictedto the execution of certain service modules nor to the processingof a dedicated data stream. With the flexible packet filter in thekernel the user-level processing of network data is not limited toa special communication protocol suite.

B. FHiPPs: Flexible Hardware Support for AMnodes

One of the challenges met by the AMnet design is the seam-less integration of flexible programmable hardware and the cor-responding hardware-dependent service modules. As hardwareplatform, FHiPPs (Flexible High Performance Platform) [8] wasdesigned. The platform itself is not discussed further in this pa-per. Focus will be on the integration of FHiPPs into an AMnode.As outlined above, service modules are located within the exe-cution environment. Thus, those services being outsourced onthe hardware platform need to be accessible through the execu-tion environment as well. The transparent interaction betweensoftware based modules and happlets as well as the transparentaccess of happlets is provided by virtual service modules. Theyare responsible for transferring the data to and from the hard-ware manager. Fig. 8 depicts the integration of virtual servicemodules into the execution environment.

Happlets implement the service modules being executed onthe programmable hardware, i.e., they are accessed through acorresponding virtual service module. Happlets consist of twoparts: a hardware code segment contains code fragments andhardware description code to install or modify the required hard-ware functionality. A host code segment holds all information


FHiPPs FHiPPs

managerAMnet

monitorQoS virtual

servicemodule

virtualservicemodule

filter requests,filter i/o

managerhardware

happlet 1 happlet 2

appl. area

OS kernel

host

hardwareunits

Fig. 8. Integration of service modules.

needed to transfer the hardware code onto the hardware, to re-initialize it and to install appropriate I/O routines. More detailscan be found in [2].

The core of the hardware integration is the hardware man-ager which is a generic pseudo device driver that is includedwithin the operating system kernel of an AMnode. The hard-ware manager is responsible for managing the data transfer be-tween software-based functions and the hardware. A carefullydesigned data path allows for single data copy operations be-tween user program and hardware. Additionally, the hardwaremanager controls flexible insertion and removal of happlets.

Video filtering has been discussed at various places [9] and isa prominent example for the usage of active and programmablenetworks. Moreover, it qualifies as good example for the place-ment of dedicated hardware support since it is processing in-tensive. Within the AMnet project, a so-called library of filterfunctions for block-based video compression in Java was devel-oped. The library decomposes the steps necessary to scale vari-ous video streams. Block-based encoding schemes like H.261[10], H.263 [11] and MPEG-1 [12] involve the coding stepsquantization and Huffman coding. These operations along withparsing and composing of the stream syntax have been real-ized in separate service modules. With this library different fil-ter functions can be realized by combining appropriate servicemodules (frame dropping, re-quantization filter, monochromefilter, transformation filter) [13] . The architecture of the libraryis depicted in Fig. 9. The arrows denote modules used to real-ize transcoding from H.261 to MPEG-1 with subsequent colorreduction.

With this decomposition, it is possible to defer costly oper-ations to specialized hardware to improve performance. Oftenit is not possible or efficient to move all the required process-ing to programmable hardware, since the service modules canbe too complex, as in the case of media filters. One example ofrealizing a filter function in hardware is a Huffman decoder forMPEG. Here, first measurements have been undertaken with aprototype implementation of such a decoder. It runs on one ofthe eight user programmable FPGAs on the FHiPPs. The cur-rent prototype hardware allows for clock rates up to 10 MHzfor a design like the Huffman decoder. The data paths from and

to the FPGAs are two synchronous 8 bit busses clocked at thesame FPGA clock rate. Hence, the data transfer to and from theHuffman FPGA takes place with 10 Mbps full duplex.

The different stages of Huffman processing were imple-mented in a pipelined design allowing the Huffman decoder tobe operated at 10 MHz. The measurements have shown thatthe actual processing rate is limited by the I/O busses. Due tothe nature of the data compression capabilities of the Huffmanalgorithm the decompression speed is limited by the outgoingbus. Therefore, a decompression rate of about 10 Mbps decom-pressed data per second was achieved. Moreover, the easy in-tegration of programmable hardware in AMnodes is underlinedby the practical experience.

IV. RELATED WORK

AMnet is based on the idea of extending the functionalityof intermediate systems on demand by dynamically loadableservice modules. These modules (programmed with C, Javaor a hardware description language) are stored in a specificrepository—a distributed database—and can be downloaded ondemand by AMnodes. AMnet, in contrast to other projects,is not capsule-based with service provision, but separates datatransport from the code, that needs to be executed on the data.This makes a receiver-oriented mechanism for installing newservices inside the network possible. Smart Packets [14] is atypical capsule approach where the data packets carry the codeto be executed on them. A new compact programming languagewas developed for producing code that is compact enough to fitinto an Ethernet packet. In ANTS [15], an optimization of thetraditional capsule approach is introduced. The code to be usedwith specific data packets is referenced by code-pointers trans-ported in the data packets. The appropriate code is then loadedthe first time it is needed from the previous hop along a pack-ets path. The disadvantage with capsule-based approaches isthat capsules would have to be provided by the sender, i.e., thereceiver-orientation for providing heterogeneous group commu-nication can not be achieved. Darwin [16] uses so-called del-egates similar to our service modules to implement customizedtraffic control policies or protocols on routers. However, the del-egates are installed on a per-application or per-service basis. InDAN [17], the capsules program code is replaced by a referenceto an active plugin stored on a code server. The active pluginscontain code blocks to implement application-specific networkfunctions. In case, a data packet arriving at a node contains areference, the code is downloaded and installed. In contrast toAMnet, the active plugins are loaded into the kernel of NetBSD[18]. In AMnet, a flexible execution environment in user spacewas preferred for the execution of the service modules for se-curity reasons: Possible errors in the service modules then justaffect the execution environment and do not corrupt the kernel.But for efficiency reasons, some parts of service specific packetprocessing can be delegated to kernel level processing, too, orcan even be off-loaded onto dedicated hardware.

Our AMnet approach requires an active signaling protocol tolocate and announce as well as to establish and maintain thecorresponding services. This protocol is specific to AMnet. Thelocation of AMnodes resp. the location of active services on in-


Fig. 9. Filter function library.

termediate nodes is not addressed by several approaches: ANTS[15], for example, does not deal with the issue of locating ac-tive nodes, focusing instead on the router architecture. Activeservices [19] do not require any active routers, but only activeserver clusters that are connected to the network. The approachdoes not specify where these server clusters must be placed. TheSpawning networks [20] approach proposes a distributed instan-tiation of active routers with a metabus that acts as a communi-cation backbone between the routers. However, it does not ad-dress the issue of where the routers should be located. In PRO-TEAN [21] a distinction is made between network programma-bility that alters the way resources are arbitrated among compet-ing users and user programmability that alters the way the allo-cated resources are used in order to provide customized servicesfor a user. User-specified services reside only in edge routers,but many services need to adapt to characteristics of the corenetwork. Thus, services must be provided with an equivalentlink state of the core so that services invoked on the edge routercan approximate the functionality of the service which wouldhave been instantiated in the core router if all the routers wereuser-programmable. The distinction between user and networkprogrammability is not used in AMnet for simplicity reasons,we tried to develop a signaling protocol as general as possible.RSVP was considered as signaling protocol [13], but it did notoffer the flexibility to support optimal location of service mod-ules, because RSVP tends to locate the service as close to thesender as possible. While this is desirable for media translation,protocol adaptation can not be realized this way.

In contrast to other projects, AMnet does not use brokermechanisms for the dissemination of service information. In-stead, a specific multicast group is used where all available AM-net services are announced similar to the Session Announce-ment Protocol (SAP) of the Internet. Because the receivers aremember of this group, they are aware of all available services.In Darwin [16], for example, a service broker is used by applica-tions and service providers to identify available services. In 2K[22], a so-called dealer is used for the interaction between ap-plication users and service providers. The dealer corresponds tothe directory agent in the Service Location Protocol (SLP) [23].The use of a central service broker or service dealer requiresexplicit mechanisms for the dissemination of available servicesand for building some kind of service hierarchies or trading do-

mains to avoid the broker from building a bottleneck. This isavoided with the use of multicast mechanisms in AMnet.

Another important aspect of AMnet is the hardware supportthrough FHiPPs. Reconfigurable hardware like the FHiPPs isa common tool for rapid prototyping. Some of these systemslike the FHiPPs or the P4 [24] are specifically designed to sup-port networking. These systems usually contain one or moreprogrammable logic devices and often include a separate CPUfor complex control tasks. In contrast to the P4 engine whichconsists of FPGAs only and is tightly integrated between twoATM interfaces, the FHiPPs was designed as a general purposeplatform and consists of FPGAs as well as a standard CPU anda DSP. Its integration into the host system provides a direct in-terface to the local ATM interfaces and a high speed path intothe hosts main memory or other I/O devices mapped into thehosts memory space (e.g., network interfaces as well as addi-tional subsystems like other FHiPPs units or similar devices).

V. CONCLUSION AND OUTLOOK

AMnet provides an open and generic framework for the pro-vision of user-tailored communication services with a specificfocus on heterogeneous group services. It is based on Activeand Programmable Networking technologies. A major goal ofAMnet is to provide individual services on demand, i.e., to sup-port rapid service creation. As such, the timely provision ofa service is highly important and refers to seconds rather thandays, months and years as it is typical in current networkingenvironments. In this context, AMnet aims at speeding up inno-vation cycles considering network services and networked ap-plications. This is very much in-line with the argumentationpresented in [25].

AMnet represents a framework in which individual servicescan be provided. The basic component of the framework are ser-vice level groups, an active signaling protocol as well as the de-sign of programmable network nodes, so-called AMnodes. Allmajor components have been presented within this paper with afocus on the service model and the signaling approach. Varioussimulations considering the signaling have been undertaken inorder to investigate its performance [26]. They basically under-line the feasibility of rapid service creation with AMnet.


Since the approach of AMnet is based on the provision ofenhanced services within network internal nodes, performanceof such nodes is of interest. For the fact that AMnet does notrequire every network node to provide such services, specialsupport considering efficiency can be limited to selected nodes.These nodes may provide dedicated support for programmablehardware that can be used for the execution of processing inten-sive service modules, such as Huffman coding/decoding in thecase of video filters. A transparent support for the integrationof such a hardware platform is part of AMnet and is achievedthrough the seamless integration of virtual service modules.

A prototype implementation of an AMnode is available andwill be soon deployed in a German national testbed called Flex-iNet [27]. Four German universities participate in FlexiNet(Berlin, Braunschweig/Karlsruhe, Munich and Stuttgart). Theproject is supported by the German ministry on research andeducation. AMnodes will be deployed at all involved Univer-sities and will be interconnected through the German researchnetwork.

ACKNOWLEDGEMENTS

The authors would like to thank the German research founda-tion (DFG) and the German ministry on research and education(BMB+F) for their financial support. Moreover, the results ofperformance measurements and the implementation of our pro-totype are due to many students working in the AMnet project.R. Wittmann worked with the AMnet project during his employ-ment as Ph.D. student at Technical University of Braunschweig.The presented research results are outside his work at EricssonEurolab, Germany.

REFERENCES[1] R. Wittmann and M. Zitterbart, Multicast–protocols and Applications,

Morgan-Kaufman Publisher, 2000.[2] T. Harbaum et al., “AMnet: Heterogeneous multicast services based on

active networking,” in Proc. IEEE OPENARCH’99, New York, USA, Mar.1999, pp. 98–107.

[3] B. Fenner, “Internet group management protocol, version 2,” IETF, RFC2236, Nov. 1997.

[4] M. Handley, “SAP: Session announcement protocol,” IETF, Internet Draft,Nov. 1996.

[5] M. Handley and V. Jacobson, “SDP: Session description protocol,” IETF,RFC 2327, Apr. 1998.

[6] W. Yeong, T. Howes, and S. Kille, “Leightweight directory access proto-col,” IETF, RFC 1777, Mar. 1995.

[7] V. Ryan, S. Seligman, and R. Lee, “Schema for representing java objectsin an LDAP directory,” IETF, RFC 2713, Oct. 1999.

[8] T. Harbaum et al., “Design of a flexible hardware coprocessor unit,” inProc. EUROMICRO’99, Milano, Italy, Sept. 1999.

[9] N. Yeadon et al., “Continuous media filters for heterogeneous Internet-working,” in Proc. Conf. Multimedia Computing and Networking, SanJose, California, Jan. 1996.

[10] ITU-T, Recommendation H.261, Video Codec for Audiovisual Services atp � 64 kbits, 1993.

[11] ITU-T, Recommendation H.263, Video Coding for Low Bit Rate Commu-nication, 1996.

[12] ISO/IEC JTC 1, “Information technology-coding of moving pictures andassociated audio for digital media up to about 1.5 Mbits/s,” InternationalStandard ISO/IEC IS 11172, 1993.

[13] R. Wittmann and M. Zitterbart, “AMnet: Active multicasting network,” inProc. IEEE ICC’98, Atlanta, GA, USA, June 1998, pp. 896–900.

[14] B. Schwartz et al., “ Smart packets for active networks,” Mar. 1999.[15] J. V. Guttag, D. J. Wetherall, and D. L. Tennenhouse, “ANTS: A toolkit

for building and dynamically deploying network protocols,” in Proc. IEEEOPENARCH’98, Apr. 1998, pp. 117–129.

[16] J. Gao et al., “A programmable router architecture supporting controlplane extensibility,” IEEE Commun. Mag., pp. 152–159, Mar. 2000.

[17] D. Decasper and B. Plattner, “DAN: Distributed code caching for activenetworks,” in Proc. IEEE INFOCOM’98, Apr. 1998.

[18] D. Decasper et al., “Router plugins: A modular and extensible softwareframework for modern high performance integrated services routers,” inProc. ACM SIGCOMM’98, Sept. 1998.

[19] E. Amir, S. McCanne, and R. Katz, “An active service framework andits application to real-time multimedia transcoding,” in Proc. ACM SIG-COMM’98, 1998.

[20] A. T. Campbell et al., “Spawning networks,” IEEE Network, July/Aug.1999.

[21] R. Sivakumar, S. Han, and V. Bharghavan, “A scalable architecture foractive networks,” in Proc. IEEE OPENARCH’00, Tel Aviv, Israel, Mar.2000.

[22] D. Xu, K. Nahrstedt, and D.Wichadakul, “MeGaDiP: A wide–area mediagateway discovery protocol,” in Proc. IEEE IPCCC’00, Feb. 2000.

[23] E. Guttman et al., “Service location protocol,version 2,” IETF, RFC 2608,June 1999.

[24] I. Hadzic and J. Smith, “On-the-Fly programmable hardware for net-works,” in Proc. IEEE GLOBECOM’98, Nov. 1998.

[25] D. G. Messerschmitt, “The prospects for computing-communications con-vergence,” Invited Paper at VISION 21: Perspectives for the Informationand Communication Technology, Nov. 1999.

[26] A. Speer, A Flexible Signalling Protocol for AMnet, Diploma thesis, TUBraunschweig, German, July 1999.

[27] FlexiNet. Available at http://www.flexinet.de.

Till Harbaum studied computer science at the Tech-nical University of Braunschweig, Germany. He re-ceived his M.Sc. (Dipl.-Inform.) degree in 1997.Since then he works as a Ph.D. student, first at Tech-nical University of Braunschweig and now at the In-stitue of Telematics at the University of Karlsruhe,Germany. His main interest is in hardware support forinterworking systems.

Anke Speer studied computer science at the TechnicalUniversity of Braunschweig, Germany. She receivedher M.Sc. (Dipl.-Inform.) degree in 1999. Since thenshe works as a Ph.D. student first at Technical Univer-sity of Braunschweig and now at the Institue of Telem-atics, University of Karlsruhe, Germany. Her maininterest is in Active and Programmable Networkingtechnologies.

Ralph Wittmann studied computer science at theUniversity of Karlsruhe, Germany. He received theM.Sc. (Dipl.-Inform.) degree in 1995. From 1995to 2000, he worked as a research assistant at the re-search group for High Performance Networking andMultimedia Systems at the Technical University ofBraunschweig. His research interests were mainlyconcerned on active networking and multicast andmultimedia communications in heterogeneous envi-ronments. He is now working with Ericsson Euro-lab, Germany. He is member of IEEE and the German

Gesellschaft fur Informatik.


Martina Zitterbart is full professor in computer sci-ence at the University of Karlsruhe, Germany. Shereceived her doctoral degree from the University ofKarlsruhe in 1990. From 1987 to 1995 she was a Re-search Assistant at the University of Karlsruhe. From1991 to 1992, she was on leave of absence as a Visit-ing Scientist at the IBM T.J. Watson Research Center,Yorktown-Heights, NY. She was Visiting Professor atthe University of Magdeburg and the University ofMannheim and professor at the Technical Universityof Braunschweig. Her primary research interests are

in the areas of multimedia communication systems, internetworking and confer-encing applications. She is member of IEEE (served on the Board of Governersof the communication society 95–98), ACM, and the German Gesellschaft furInformatik.

Documents

Providing heterogeneous multicast services with AMnet