ATRANSPORT-INDEPENDENTCOMPONENTFORA GROUPANDSESSIONMANAGEMENTSERVICEIN GROUPCOMMUNICATIONSPLATFORMS ComputerEngineeringandNetworksLaboratory(TIK) ErikWilde,MuraliNanduri,BernhardPlattner SwissFederalInstituteofTechnology(ETHZurich) E-mail:wilde@tik.ee.ethz.ch CH{8092Zurich tionrecently.thispaperfocusesonamodelandthearchitectureofasystemwhich Groupcommunicationsisanareaofresearchwhichhasreceivedalotofatten- ABSTRACT supportsgroupcommunicationsbyprovidinggroupandsessionmanagementfunctionality.thissystemisanextensionofdirectoryserviceswhichareusedwithunicast communications.newfunctionalityisneededforthedynamicsofgroupcommunications(membersofaconnectionmaychangeoverthelifetimeoftheconnection)and whichrepresenttherelevantobjects.usersandgroupsrepresentrealworldusersand increasedcomplexityofrelations.amodelisdescribedwhichdenessixobjecttypes theirrelations.sessionsandowsdescribeongoinggroupcommunications.flowtemplatesandcerticatesprovidemechanismsformanagementandsecurityissues.the dierentgroupcommunicationplatforms.ashortsketchoftheimplementationis architecturepresentedinthispaperistransport-independent,ieitcanbeusedwithin giveninthelastsection. Overthepastyears,surveysbyvariousauthors[1,2,3]haveshowntheincreasingneed formultipointcommunicationsandtherequirementsforplatformssupportingthistype 1.INTRODUCTION ofcommunications.additionally,therequirementformultimediadatatransportisalso formanagementissues.thispaperpresentsanapproachtothemanagementplane dierentplanes,onedealingwiththeactualdatatransferandanotherbeingresponsible whichsupportsmultipointmultimediadatatransportservicesistheseparationinto appliedtomultipointcommunications.onecommonapproachfordesigningaplatform acomponentwhichisreusablefordierenttransportplatforms.thisapproachhas fromthetransportinfrastructurebeingusedandshouldthereforebeaddressedinside thefollowingadvantages. whichisbasedontheassumptionthatmanyproblemstobesolvedareindependent
Reducedimplementationcosts.Becauseofthetransport-independencyofsuch acomponent,itcouldbeusedindierenttransportplatformswithouthaving Transport-independentnaming.Thenametoaddressmappingisoneofthetasks toimplementthefunctionalityforeachplatform.thisleadstoareductionof implementationcostsfornewplatformsusingthiscomponent. collaborativeapplicationhasitsownnamespacesothattheuseofmorethan component,thenitispossibletousethesamenamesforaddressingfordierent ofthemanagementplane.ifnamingisimplementedbyatransport-independent transportplatforms.thiswouldeliminatethesituationoftoday,whereeach Sessiondirectoryfunctionality.Asessiondirectorysimilartothewell-known onecollaborativeapplicationcanbecomeaverycomplicatedprocessintermsof mbonesessiondirectorywouldbepossible,anditwouldbeamoregeneraldirectory.itwouldnotonlylistthesessionsandtherespectiveapplications,butalso thetransportinfrastructurebeingused.thiswayitwouldbeeasytoimplement collaborativeapplicationswhichareabletousedierenttransportinfrastruc- userandgroupmanagement. separatedfromtransport-dependentissuesandimplementedinaseparateandreusable Theapproachtakeninthispaperillustratesthatthereisfunctionalitywhichcanbe tures. component.inordertoelaboratethishypothesis,therestofthepaperisstructured asfollows.section2givesashortoverviewoverotherworkinthisareaandrelated activities.section3thendescribesourmodelofhowsuchacomponentcouldbeused insideatransportinfrastructure.movingontoamodelofhowsuchacomponent couldbedesigned,section4describesourarchitectureofsuchamodel.section5gives ashortoverviewoverimplementationissues,andsection6thenconcludesthepaper. mostoftheworkconcentratesonmulticastprotocols(iethetaskoftransmittingdata Groupcommunicationshasbecomeaveryactiveeldinthelastyears.However, 2.RELATEDWORK distributedmultimediaapplications. multimediamulticastprotocols,andhigh-levelissues,suchastoolkitsforprogramming overanetworktomorethanonereceiverwithoutwastingnetworkresources),especially standardizationeorts.therestofthissectionwilldescribesomeoftheseprojects.a tionframeworksarenotsowide-spread,althoughthereareresearchactivitiesandalso moredetaileddescriptionhasrecentlybeenpublishedbymautheetal.[4]. Developmentsintheareaofgroupandsessionmanagementforgroupcommunica- 2.1.Researchactivities amultimediamailservice(mmm)andamultimediatransportservice(mmt).mmt al.[5,6]isanexampleforanapplicationorienteddevelopmentofacommunications platform.mmcisapartoftheberkommultimediateleservices,whichalsoinclude TheBERKOMMultimediaCollaborationService(MMC)describedbyAltenhofenet
isapuretransportserviceanddoesnotoeranygroupmanagementservices.itis basedonavariantofxtpwhichiscalledxtp-lite.mmccontainsvariouscomponents,ofwhichconferenceinterfaceagents(cias),conferencemanagers(cms),antionbetweenthesecomponentsisrealizedbytwoprotocols,thecdaccessprotocol (CDAP)andtheCMaccessprotocol(CMAP).TheseprotocolsareRPC-basedand aconferencedirectory(cd)arerelevantforthescopeofthispaper.communica- thearchitecturedescribedinthispaper.however,theserviceprovidedisapplication specicandthereforecanberegardedasonepossibleapplicationofthegeneralconcept ofagroupandsessionmanagementservicedescribedinthispaper. builtontopoftheisorosemechanisms.thearchitectureofmmcissimilarto concernedwiththesupportofgroupcommunication,especiallyformultimediadata. tectureqos-adescribedbycampbelletal.[9].thetransportaspectsofgcomms OneofthecomponentsofthearchitectureproposedforGCommSistheQoSarchi- GCommSbyMautheetal.[7,8]isaprojectatLancasterUniversitywhichis abstractlevel.currently,nospecicationisavailable,althoughatransportservice(the aredenedindetail,butthegroupmanagementservicesareonlydescribedonavery so-calledm-connectionservice)hasbeenimplemented.gcommsthereforecanberegardedasoneofthemanyprojectswheregroupmanagementisnecessarytoprovidea well-functioningplatform,butisnotspeciedindetail.otherexamplesforplatforms indetailarethexamparchitecturedescribedbyrodriguesandverssimo[10],prism bythetoutains[11],ortenetdescribedbyferrarietal.[12,13]. conceptintermsoffunctionality.thetransportgroupmanagementdenedforthe CIOtransportservicehasmanysimilaritiestothemodelwedescribeinthispaper.A useroftheciomulti-peertransportserviceusestwodierentcomponentsforaccessing CIOmulti-peercommunicationsasdescribedbyHenckel[14,15]isaveryinteresting wheregroupmanagementisidentiedasanimportantcomponentbutnotinvestigated arehandledwithtwocompletelyseparateprotocols.however,ciotransportgroup thetransportserviceandthetransportgroupmanagementservice.communications theciotransportservice),andithasnotbeenimplemented.furthermore,sincethe managementislimitedtoonecommunicationsplatform(iedependsontheusageof X.500directoryserviceisproposedasabasisforthetransportgroupmanagement 2.2.Standardizationbodies service,itmaybeimpossibletohavenoticationssenttousers. ITU'sT.120seriesofrecommendations[16]isanexampleforastandardizedapplication basisofthet.120infrastructurearethenetworkspecictransportprotocolsdened int.123[17],whichatthemomentsupportdatatransferusingintegratedservices digitalnetworks(isdn),circuitswitcheddigitalnetworks(csdn),publicswitched architecturewhichalsoincorporatesgroupandsessionmanagementfunctionality.the communicationsservicet.122/t.125[18,19],whichdenesanetworkindependent toincludefuturebroadbandnetworksareunderstudy.t.123isusedbythemultipoint digitalnetworks(psdn),andpublicswitchedtelephonenetworks(pstn).extensions addressing(onetoall,onetosub-group,andonetoone),andmultipointrouting servicewithexibledatatransfermodes(broadcastandrequest/response),multipoint (shortestpathstoeachreceiveranduniformsequencing).recommendationt.124[20]
Application Generic Conference Control (T.124) Multipoint Communications Service (T.122/T.125) Network Specific Transport Protocols (T.123) thendenesagenericconferencecontrolwhichusest.122'smultipointcommunicationsservice.theabstractservicesoftheconferencecontrolincludecreate,query, Figure1:ArchitectureoftheITUT.120infrastructurerecommendations T.120 Infrastructure Recommendations tions,whichthenuset.124andt.122services.however,theapplicabilityofthese recommendationsislimitedbecauseoftheconcentrationonconferencing.thet.120 Theseservicesprovideapowerfulenvironmentforimplementingconferencingapplica- join,invite,add,lock,unlock,disconnect,terminate,ejectuser,andtransferservices. seriesofrecommendationscanthereforeberegardedasaspecicexamplewhichshould bekeptinmindwhendesigningmoregeneralgroupandsessionmanagementservices. groups.wewillonlyconsidertheworkgoingoninjtc1/sc6,whichiscurrentlythe mostactivewithrespecttogroupcommunications.iso'smultipeertaxonomy[21] (whichisalsodescribedinapaperbymathyetal.[22])givesageneralarchitectural InISO,groupcommunicationisdealtwithindierentcommitteesandworking modelforgroupcommunications,whichmaybeusedwithindierentosilayers.conceptsdenedinthistaxonomydescribeagroup(asetofentities),groupmemberships (entitiesbelongingtoagroup),populationcharacteristics(asetofattributesagroup mayhave),groupassociations(datatransferrelationships),andconversations(thebasiccomponentsofgroupassociations).theseconceptscanbecombinedtogetamodel whichisveryexibleintermsofgroupcommunications.however,aswithmanyother sibletoexperimentallyevaluatetheusabilityofthismodel.theisodraftdocument onanenhancedcommunicationstransportservice[23]incorporatesmostconceptsdescribedinthemultipeertaxonomy.thenamingandaddressingmodeldenedinthis andgroupassociationshavetobetakenintoaccount. standardizationactivities,noimplementationsoftheseconceptsexist,soitisnotpos- draftismorecomplexthaninpoint-to-pointtransportservices,becauseconversations saryineverysystemsupportinggroupcommunications.figure2showshowsucha Groupandsessionmanagementcanbeidentiedasonecomponentwhichisneces- 3.AMODELFORGROUPANDSESSIONMANAGEMENT componentmaybeintegratedintothecommunicationsplatform(thecomponentislabeledgua,anamewhichwillbeexplainedlater).themodelisindependentfromthe
Application API Security Management Data GUA Resource Management communicationsplatformbeingused,althoughitismainlyinuencedbydiscussions Figure2:Groupandsessionmanagementinsideacommunicationsplatform withinthedacapoproject.thisproject,wherethemaingoalsareecientcommunicationprotocolsachievedbydynamicconguration,developedtheneedforgroupand Transport Infrastructure sessionmanagementafterbroadeningthemodelfrompoint-to-pointcommunications groupcommunicationsplatform.thesetasksmaybedividedintosecurityissues, topoint-to-multipointconnections. management.thefollowingparagraphswilldiscusstheseissuesingreaterdetail. nametoaddressmapping,qosissues,andthecorefunctionality,groupandsession Agroupandsessionmanagementcomponentisusedfordierenttaskswithina Securityissuesareaddressedintheformofidentication,authentication,authorization,andcertication.Thesearethesecurityissueswhichareimportant itselfviaqosparameters,whereauthenticand/orprivatecommunicationsmay inthecontextofgroupandsessionmanagementandtheprovisionofcertied softwarecomponents.securityissuesmayalsobeaddressedforcommunications Nametoaddressmappingisthefunctionalitywhichenablesusersofanycommunicationssystemtousenamesinsteadofaddresses,ietouseanabstractformof namingentities(communicationendpoints).thismakesitpossibletouselogicalnamesindependentfromlocationsandconnectionswhicharemappedonto Saltzer[24]describestheconceptofnaming,addressing,andbindingforthe addresseswhichcanbeusedforaddressinginagiventransportinfrastructure. berequired.however,thistypeofsecurityfallsintothetopicofqosissues. QoSissuesareimportantwhenspeakingofactualconnections.Thewell-known Internet. seenasonespecialcaseofageneralcharacterizationwhichmaybedenedfor toallowtheutilizationofyettobedenedtypes.szyperskiandventre[25] eachconnection.theparametersbeingusedshouldbeasversatileaspossible multimediaqosparameterslikethroughput,errorrate,delay,orjitter,canbe
Groupandsessionmanagementisnecessaryformakingthenamingspace(ie andcarleetal.[26]describethisconceptofqosparametersformultipoint thenameswhichmaybeused)exibleandcongurable.typically,groupsof communicationsingreaterdetail. usersarechangingovertime,soitmustbepossibletocreatenewgroups,to changegroupmembers,andtodeletegroups.furthermore,thecommunications insideagroup(whichwecallasession)shouldalsobemanageablebyusersof thecommunicationplatform.itshouldalsobepossibletocreatespecialsessions, sessionswhichareopentoanyparticipant(opensessions).anotherimportant eganonymoussessions(wherethesendersand/orreceiversarenotknown)or Thearchitectureweproposeforthisfunctionalityisthatofadirectoryservice, modications. functionalityinthisareaistheprovisionofauthorizationsforgroupandsession accessprotocoltothedirectoryservice.withrespecttothisdesign,ourproposed whereeachuserofthedirectoryserviceusesacomponentwhichisimplementingthe groupandsessionmanagementserviceissimilartotheinternetdomainnamesystem (DNS)denedbyMockapetris[27,28],orthedirectoryservicestandardizedbyISO anditu,alsoknownasthex.500service[29,30].however,becauseinourcase sessionmanagementsystem(gms)andisavailablethroughagmsuseragent(gua). neveracts),andspecialfunctionality(suchasoperationsforjoiningandleavinggroups weneedmorethanapurelookupservice(wherethedirectorysystemonlyreactsand andsessions),anewserviceisrequired.thisnewserviceisprovidedbythegroupand deneanarchitecturewhichmaythenbeimplementedandtested.thefollowing ThegeneralGMSmodelinventedinthepreviouschaptermaybefurtherrenedto 4.GMS{GROUPANDSESSIONMANAGEMENTSYSTEM section,wherethedierentstepsanddenitionsofqosusageareexplained. architecture,thegmsobjecttypesarespecied.qosissuesarethetopicofthelast sectionsdescribedierenttopicsofthearchitecture.afterageneraldescriptionofthe 4.1.Architecture whichisusedbythegmssystemagents(gsa)tocommunicateandthusimplement bygmsuseragents(gua),andisimplementedbythegmssystemprotocol(gsp), thatthegmsserviceisavailablethroughagmsaccessprotocol(gap)whichisused ThearchitectureoftheGMSissimilartothatofotherdirectoryservices,inthesense thegms.theoverallviewofthisarchitectureisshowningure3. GMSuseragent(GUA).GUAsarethecomponentsoutsidetheGMSwhichare machinewhichimplementsthegmsaccessprotocol.assuch,theguaprovidesaninterfacewhichmaybeusedbyothercomponentsofthecommunication usedtoaccessthegms.typically,aguaisnotmuchmorethanaprotocol platform.itperformsencodinganddecodingofprotocolmessagesandalsoimplementssomelocalparameterchecking.theguaisnotdirectlyaccessibleto
GUA Application Data GSA GSA GSA GSA GMS GSP GSP GSP GUA Application Data GUA Application Data GAP GAP GAP Figure3:GMSarchitecture applicationprogrammers,becausethecommunicationplatformdesignersshould befreetodenetheplatform'sapiinacoherentwaywithouthavingtoaccept apredenedguaapiforapplications. GMSsystemagent(GSA).GSAsarethecomponentswhich,intheirentirety, makeupthegms.eachgsaisacomponentofthisdistributedsystemandcommunicateswitheitherothergsas(usingthegmssystemprotocol),orguas (usingthegmsaccessprotocol).inthegmssystem,datastorageisdistributed, sothateachgsamaystoresomelocaldatawhichmaybequeriedbyanother GSA.GSAsaregroupedintodomains,whereGSAscommunicatinginsideonedomainusetheintra-domainGMSsystemprotocol,whilecommunicationscrossing domainboundariesusetheinter-domaingmssystemprotocol. ThetwomaincomponentsoftheGMSarchitecture,GMSuserandsystemagents, arecommunicatingusingspecialprotocols.theseprotocolsareusedforaccessing thegms(viaguas)respectivelyforcommunicationsinsidethegms.thefollowing paragraphswillgiveamoredetaileddescriptionofthesetwoprotocols. GMSaccessprotocol(GAP).GUAsareusedforaccessingtheGMSusingentry pointsprovidedbygsas.theseentrypointsmustbeaccessedusinggap,which isanasymmetricalprotocol.thecompletespecication[31]containsdenitions ofusedobjecttypes(whicharedescribedinsection4.2ofthispaper),relations betweenobjects,pdudenitions,andstatetransitiondiagramsdescribingthe behaviorofthetwocommunicatingagents.figures4and5showthestatetransitiondiagramsoftheguaandgsasideoftheprotocol.thenotationofevents andactionsusedforthetransitionsistakenfromitu'sacsespecication[32]. Becausethenumberofstatesismuchbiggerthantheonesshowninthesegures,onlythetopmostlevelofthediagramsisshown,whichillustratesconnection setupandtear-down.doubleboundedboxesrepresentstateswhichcontaincompletestatediagramsthemselves.dashedlinesseparatestatediagramswhichare executedinparallel.furthermore,itispossiblethattheremaybeseveralparallel entitiesoftheguaboundstate,eachrepresentingoneuser'sconnectiontothe
BindGuaReq/ BindGuaRQ idle GUA binding UnbindGuaRE+/ UnbindGuaCnf+ GUA unbinding UnbindGuaReq/ UnbindGuaRQ GUA control idle BindGuaRQ/ BindGuaRE+ UnbindGuaRQ/ UnbindGuaRE+ Figure5:GAP/GSAstatediagram GUA control UnbindGuaRQ/ UnbindGuaRE- BindUserRQ/ BindUserRE- UnbindGuaRE-/ UnbindGuaCnf- BindGuaRE-/ BindGuaCnf- Figure4:GAP/GUAstatediagram BindGuaRE+/ BindGuaCnf+ GUA bound BindGuaRQ/ BindGuaRE- GMS.ThiswayitispossiblethatseveraluserscanbeconnectedtotheGMS GUA bound usingonlyonegua,whichisnecessaryforcommunicationframeworkswhere thetwogures,representingconnectionsetupandtear-downbetweenguaand GAPitselfcanbeseparatedintothreephases.Therstphaseisillustratedin onlyoneguaexistsforeachmachine. challengeswithmultipleiterations)canbeused.aftersuccessfulauthentication, weakandstrongmechanisms(fromnoneorstandardunixpasswordsuptorsa andauthenticated.authenticationishandledinaverygenericway,sothat GSA.Thesecondphaseistheauthenticationphase,whereauserisidentied thethirdphase,theuserboundstate(notshowninthegures),isenteredand servicesforaccessingthegms'sdatacanbeused.theseservicesincludecreate, GSAbecomesactive(egwhensendingnotications,invitations,orrenegotiation requests). initiatedbythegua(ietheuser),buttherearealsosomesituationswherethe modify,delete,join,andleavefortheappropriateobjects.mostgaprequestsare GMSsystemprotocol(GSP).GSAsarecomponentsoftheGMSwhichstoredata oftwodierentparts,anintra-domainprotocolandaninter-domainprotocol. andprovideaccesstothegms.gsascommunicateusinggsp.gspismadeup DependingontherelationoftwoGSAs,thecommunicationbetweenthemis
ThesedescriptionsofGMScomponents(GUAandGSA)andtheprotocolsused service,itisnotdescribedingreaterdetail. usingoneofthetwovariants.becausegspisnotvisibleforusersofthegms forcommunicationsbetweenthesecomponentsgiveanoverviewofthegmssystem. Thefollowingtwosectionswilldealwithtwoaspectsofthedatabeingstoredand exchanged,whicharetheobjecttypesavailableandthewayqosissuesarehandled. 4.2.GMSobjecttypes overviewoftheobjecttypes,theirattributes,possiblerelationsbetweenobjects,and thegeneralconceptbehindeachtype. DetaileddescriptionsaregivenintheGAPspecication[31],herewewillonlygivean AlldenitionsoftheobjecttypesavailableinsidetheGMSarespeciedinASN.1. User.AuserisapersonorentityusingGMS.Eachuserhasanidentity(a name)andoneormorewaysofauthenticatinghimself.thisauthenticationmay varyfromnoauthenticationatall(itissucienttousetherightname)tosophisticated,hardware-orientedauthenticationschemeswithmultiplechallenge iterations.theauthenticationmethodbeingusedisimportantforsomeoperations,whichmayonlybeperformedifacertainlevelofauthenticationhasbeen usedwhenbindingtothegms. Auserobjectcontainsinformationaboutauser,suchashisrealworldname,a description,hisemailaddress,andalistofthebindingsofauser,iethelistof activegmsconnectionsauserhas.therelationsofauserobjectdescribewhich objectstheuserowns,ofwhichgroupsand/orsessionstheuserisamanagerof, Group.Groupcommunicationsneedaexiblewayofhandlinggroupsofusers. forwhichowsheisasenderand/orreceiver. ofwhichgroupsheisamemberof,ofwhichsessionsheisaparticipantof,and GMSgroupsmayconsistofusersand/orgroups,dependingonthedenition ofthegroup.joiningandleavingagroupdependsonthegroup'sjoinpolicy managersand/ormembers.groupsmayalsobestatic(opposedtodynamic), andauthenticationrequirements.joinsandleavesmaybenotiedtoagroup's denedattimeofthegroup'screation). whichmeansthatnojoinsorleavesarepossible(groupmembersthenmustbe Eachgroupobjectmaycontainagroup'srealworldname(egthenameofa address,andtheaccessrights,whichdeterminewhoisauthorizedtomodifythe group,managersofthegroup,membersofthegroup,andsessionsassociated attributesofthegroup.possiblerelationsforagroupspecifyanownerofthe companyoracompany'sdepartment),adescriptionofthegroup,agroup'smail FlowTemplate.Forseveralapplicationsandcommunicationplatformsitisuseful withthatgroup. tohaveanumberofpredenedpossibilitiestosetupconnections.flowtemplates containinformationaboutdatatypeswhichmaybecarriedbyaowofthattype, thenecessarytransportservice,datawhichisneededtosetupaowofthattype,
alsobecreatedwithoutusingaowtemplate. whichcanbeusedtogiveadescriptionoftheowtemplate.however,owsmay informationaboutuni-orbidirectionalservices,andasetofqosparameters, Flow.Aowisoneconnectionfordatatransport.Dependingontheow'sdefinition,itiseitheruni-orbidirectional,hasalimitednumberofsendersand/or receivers,andarenegotiationpolicy,whichdetermineswhoisauthorizedtoinitiateqosrenegotiationsforthatow.flowsarecreatedwhenasessioniscreated andaredeletedwhenasessionisdeleted.joiningaowtakesplacewhena sessionisjoined,andaowisleftwhenthesessionofaowisleft. (theaddressinginformationisalsopartoftheowanddiersdependingon Eachowhasrelationswhichdescribetheuserssendingandreceivingthatow tocreatearelationshipbetweenowswhichdenotesasynchronizationbetween thetypeofaddressingbeingused),dependencieswithotherows(incasedata ows(apopularexampleforthisareindividuallytransmittedaudioandvideo isbeingsentwhichneedsdatabeingsentonotherowsforbeinginterpreted correctly,suchashierarchicallycodeddatalikempeg-2[33]).itisalsopossible Session.Themainmetaphorfordatatransferisasession.Eachsessionisusedto thesynchronizationmustbedoneinsidethecommunicationsplatform. datawhichmustbesynchronizedforplayback),however,theimplementationof logicallygroupanumberofowsandtocreateanabstractionformanagement, authorization,andadmissioncontrolforows.theowsofasessionarecreated whenthesessioniscreatedanddeletedwhenthesessionisdeleted,iethereisno possibilitytodynamicallyaddorremoveowsfromanexistingsession.however, Sessionsmayhaveapplicationspecicinformation,whichconsistsofanapplicationidenticationandapplicationspecicdata,whichmaybeinterpretedbythe levelausermusthavetosuccessfullyjoinasession(providedheisauthorized suciently).authorizationisbasedonthesession'sjoinpolicywhichmaybe open(everyonemayjoin),group(onlymembersofthegroupassociatedwiththe conrm). sessionmayjoin),ormanaged,whichmaybeeitherrelative(agivenpercent- whenjoiningasession,notallowsofthesessionsmustbejoined,souserscan choosewhichowstouse(provideddependenciesbetweenowsarerespected). application.furthermore,thedurationofasessionmaybegivenwitheitherstart orendtimesorboth.inaddition,itispossibletospecifywhichauthentication Asession'srelationsdescribetheownerandmanagersofasession,whichare ageofmanagersmustconrm)orabsolute(agivennumberofmanagersmust importantformodifyingthesessionobjectanddeterminingwhomayjointhe session(ifthejoinpolicyissettomanaged).theparticipantsofasessionare alluserswhohavejoinedthesession(excepttheuserswhohaveleftalready). Certicate.Applicationswithspecialsecurityrequirementsmayhavetheneed Asession'sowsareallowswhicharepartofthissession.Alastrelation determines,whichgroup(ifany)thesessionisassociatedwith. tostorecerticatesinsidethegms,whichareusedforcheckingdataidentity
andintegrity.certicatesincludethetype(whichmaybeapredenedtypeor checkingthedata.theonlyrelationacerticatehasistheonewithitsowner. anddataandsignatures,whichcontaintheinformationswhichisnecessaryfor andthepossibilitytodeneowntypes),thecerticate'svalidity,asimplename, anyothertype),thenametype(whichalsohasanumberofpredenedvalues modied,anddeletedwithgapservices.however,becauseanumberofattributes andrelations(suchastheaddressinginformationattributeandthesendersrelationof ows)needstobemodiedaccordingtotheirsemantics,theyareimplicitlymodied TheseobjecttypesareavailableforusageinsidetheGMSandmaybecreated, toaowhejoinedandmodifythesendersrelationaccordingly). byusinggapservices(suchasthejoinsessionservice,whichaddsasender'saddress 4.3.QoSissues issuescanbeidentiedhere,theqosparametertypes(deninghowqoscanbe makeitsuitableforthesupportofmultimediamultipointcommunications.twomain isalsotakenintoaccount.gmsmustbeabletosupportqosaspectsinawaywhich QoSisaveryimportantaspectofmultipointcommunications,especiallyifmultimedia howqoscanbeapplied). dened)andtheproceduresavailabletomanipulateparametersofthesetypes(dening values,andrealvalues.unsortedvaluesareasetofpredenedvalues,whicharenot inanyparticularorder(anexampleforthisisaqosparameterwhichdenesacoding algorithm,whereitisnotpossibletoarrangethedierentalgorithmsinanyorder). GMShasfourQoSparametertypes,whichareunsortedvalues,sortedvalues,integer becauseitispossibletoarrangetheminanorder(anexampleforthistypeofqos SortedValuesarealsopredenedvalues,butthesevaluesaregivenasasequence, parameteristheselectionofaerrordetectionalgorithm,whichmaybegivenasa sequenceofnone,crc8,crc16,andsomemoresophisticatedalgorithms).integer andrealvaluesrepresentthetwobasictypesofnumberswhichmaybeused(which maybeusedforthroughputorerrorprobabilitynumbers). Theinterpretationoftheparameter'svaluesdependsentirelyontheparameter'sname. avoidmisinterpretations.forthisreason,anumberofpredenedqosparametersis ItisthereforeimportantforGMSuserstoagreeonnamesforQoSparametersto Anyparameterdenedforaowtemplateorowmaybeofoneofthesetypes. available,wherethesemanticsofaparameterareclearlydened(takenfromtheiso draftdocumentforaqosframework[34]).additionalparametersmaybeusedat anytime,althoughitisstronglyrecommendedtousethepredenedtypeswhenever possible. nipulatingqosparameters.giventhegmsobjecttypes(asdescribedinsection4.2), fourdierenteventswhereqoscomeintoplaycanbedescribed. ThesecondaspectofQoS,asmentionedabove,aretheproceduresavailableforma- Flowtemplatecreation.Whenaowtemplateiscreated,itmayalsobegiven anumberofqosparameters.dependingonthetransportinfrastructure,the numberofparametersalreadynecessaryorevenknownatthispointintimemay
Sessioncreation(owcreation).Everydatatransferisrepresentedbyaow, alreadybedened,ifpossible. dieralot.forthedierenttypesofqosparameters,values(resp.limits)may whichiscreatedwhenthesessionitisapartofiscreated.eachow'sqos forrenegotiationsmaybedened.forunorderedvaluesqosparameters,thereis Optionally,aweakestlimitforjoiningtheowandstrongestandweakestlimits isthevalueusedforjoiningparticipantsifnolocalmodicationsarerequested). parametersaredenedbytheirnameandtypeandatleastadefaultvalue(which Sessionjoining.Whenjoiningasession,theQoSparametersbeingusedare assetsofvalues. noorderofthevalues,thereforethejoinandrenegotiationvaluesmustbegiven takenfromtheow'sqosdenitions.accordingtotheuser'srequirements,a oftheweakestlimitforjoiningtheow.becausetheactualqosestablishment weakervaluethanthedefaultmaybeselected,aslongasitdoesnotfallshort liesoutsidethescopeofgms(whichisonlyresponsibleforstoringthevalues), QoSrenegotiation.QoSrenegotiationistheprocessofdeningnewdefaultvalues rametersaccordingtothevaluesprovidedbythegms. itisrequiredthattransportinfrastructuresusingthegmscontroltheqospa- participants(sendersandreceivers)ofaowareinformedofqosrenegotiations andweakestlimitsforqosparametersofanyrenegotiableow.thisrenegotiationmaybelimitedbytherenegotiationlimitsofaqosparameter,ifpresent.all alongwiththeasn.1denitionscanbefoundinthegapspecication[31].however,itshouldalwaysbekeptinmindthatqosestablishmentandrenegotiationare distributionofqosvaluesandrenegotiationnotications. taskstobeperformedbythetransportinfrastructure,whilethegmsisonlyusedfor AdetailedandcompletedescriptionoftheQoSparametersandtheirmanipulation ofthatow. Theimplementationofthearchitecturedescribedinsection4isoneofthekeyaspects ofthegmswork.sofar,researchhaseitherconcentratedonimplementingtransport 5.IMPLEMENTATION components,oronmerelyspecifyingmanagementservices.gmsisbeingimplemented protocols,onimplementingapplicationstogetherwithapplication-specicmanagement atthetimeofwritingandwillbeintegratedinatleasttwocommunicationplatforms. ThesewillbetheextendedDaCaPoplatformdevelopedatourlab,whichhasbeen protocolswithqosguarantees.furthermore,verysmallgroupcommunicationplatformsbasedonipmulticastandatm/unimulticastfacilitiesshouldbeimplemented modiedtoincludegroupcommunications,andamultipointcommunicationsframework(mcf,describedbybaueretal.[35]),whichaimsatimplementingmulticast thattheapplicationofthegmsconceptwithindierentcommunicationplatforms toprovetheapplicabilityofthegmsconcepttodierenttransportservices.wehope aswellasthedevelopmentofapplicationsontopofthesecommunicationplatforms
Written Code Parameter + State Checking Programming Interface Finite State Machine State Machine Management Figure6:GMSuseragent(GUA)design Packet Coding ASN.1 Encoding and Decoding and Decoding Network Adaptation managementserviceintermsofprotocols,objecttypes,andperformanceissues. willleadustoabetterunderstandingoftherequirementsforagroupandsession laris2)usingc.twotoolsarebeingused,oneistheasn.1compilersnaccdescribed bysampleandneufeld[36,37],whichisperformingallthecodinganddecodingof incomingpdus,theothertoolisthecommercialsoftwarestatemate,whichisbeing TheimplementationofaGUAiscurrentlybeingdoneinaUnixenvironment(So- accordingtogure2)andtheinterfacetothetransportsystemaresubjecttochange usedforimplementingthestatemachinewhichhandlestheprotocol.theprogramminginterface(whichisusedbyothercomponentsofthecommunicationplatform componentsareisolatedfromtherestofthecodeandeasilyreplaceable. forintegrationoftheguawithindierentcommunicationsplatforms,thereforethese groupandsessionmanagementsystem(gms).gmsconsistsoftwocomponents,gms Inthispaperwehavepresentedthemodelandarchitectureforatransport-independent 6.CONCLUSIONS useragents(guas),andgmssystemagents(gsas).thesecomponentscommunicate usingthegmsaccessprotocol(gap,forgua-gsacommunications)respectivelythe GMSsystemprotocol(GSP,forGSA-GSAcommunications).TheGMSserviceisdesignedasadistributednameservicewithadditionalfunctionality,suchasnotications. Thereisasetofdenedobjecttypeswhichmaybeusedtomodelinformationabout municationplatforms.becausethedesignofobjecttypesandoperationsisindependent areavailableandmakethedesignofsecurecommunicationplatformspossible. users,groups,sessions,andows.mechanismsforauthenticationandauthorization fromaspecictransportservice,thegmsservicemaybeusedbyvariouscommunicationplatforms.thecurrentimplementationwillbeintegratedintotwoplatform, TheimplementationoftheGUAcomponentpermitstheeasyintegrationintocom- extendtheguawithregardtothetransportinfrastructurebeingused. incorporationoftheguacomponentintodierentplatforms.itisalsoplannedto thedacaposystemdevelopedatourinstitute,andamultipointcommunications framework,whichwillalsobedevelopedatourinstitute.futureplansincludethe Generated Code
groupcommunicationplatformswithamoreabstractserviceintermsofnaming,addressing,nameandaddressmanagement,andauthentication.wealsobelievethat WebelievethattheGMSserviceingeneralandtheGUAasacomponentforthe inclusionintocommunicationplatformswillpermitthedesignandimplementationof fromanapplicationpointofviewandwhichservicesshouldbeprovidedbythegua component. tionplatformswillleadustoabetterunderstandingofwhichservicesarerequired theimplementationofsuchasystemanditsusageinsideactualgroupcommunica- [1]T.Rodden,J.A.Mariani,andG.Blair.SupportingCooperativeApplications. ComputerSupportedCooperativeWork,1(1{2):41{67,1992. 7.REFERENCES [2]TomRoddenandGordonS.Blair.Distributedsystemssupportforcomputer [3]NeilWilliamsandGordonS.Blair.Distributedmultimediaapplications:Areview. supportedcooperativework.computercommunications,15(8):527{538,1992. [4]AndreasMauthe,GeoCoulson,DavidHutchison,andSilvesterNamuye.Group ComputerCommunications,17(2):119{132,1994. [5]MichaelAltenhofen,JurgenDittrich,RainerHammerschmidt,ThomasKappner, SupportinMultimediaCommunicationsSystems.InHutchisonetal.[40],pages CarstenKruschel,AnsgarKuckes,andThomasSteinig.TheBERKOMMultimediaCollaborationService.InProceedingsofACMMultimedia93,pages457{463, Anaheim,California,1993.ACMPress. 1{18. [6]MichaelAltenhofen,JoachimSchaper,andSusanThomas.TheBERKOMMultimediaTeleservices.InSteinmetz[38],pages237{250. [7]AndreasMauthe,DavidHutchison,GeoCoulson,andSilvesterNamuye.From [8]JoseF.deRezende,AndreasMauthe,DavidHutchison,andSergeFdida.M- RequirementstoServices:GroupCommunicationSupportforDistributedMultimediaSystems.InSteinmetz[38],pages266{279. ConnectionService:AMulticastServiceforDistributedMultimediaApplications. [9]AndrewCampbell,GeoCoulson,andDavidHutchison.AMultimediaEnhanced InHutchisonetal.[40],pages38{58. TransportServiceinaQualityofServiceArchitecture.InD.Shepherd,G.Blair, G.Coulson,N.Davies,andF.Garcia,editors,Proceedingsofthe4thInternational WorkshoponNetworkandOperatingSystemSupportforDigitalAudioandVideo, [10]LusRodriguesandPauloVerssimo.xAMp:aMulti-primitiveGroupCommunicationsService.InProceedingsofthe11thSymposiumonReliableDistributed November1993.Springer-Verlag. volume846oflecturenotesincomputerscience,pages124{137,lancaster,uk, Systems,pages112{121,Houston,Texas,1992.IEEEComputerSocietyPress.
[11]FrancoisToutainandLaurentToutain.NetworkSupportforMultimediaCommunicationsUsingDistributedMediaScaling.InHutchisonetal.[40],pages 139{158. [12]AnindoBanerjea,DomenicoFerrari,BruceA.Mah,MarkMoran,DineshVerma, andexperiences.technicalreporttr-94-059,internationalcomputerscience Institute,Berkeley,California,November1994. andhuizhang.thetenetreal-timeprotocolsuite:design,implementation, [13]R.Bettati,D.Ferrari,A.Gupta,W.Hener,W.Howe,M.Moran,Q.Nguyen, munication.inproceedingsofthe5thinternationalworkshoponnetworkand andr.yavatkar.connectionestablishmentformulti-partyreal-timecom- [14]LutzHenckel.MultipeerTransportServicesforMultimediaApplications.In OperatingSystemSupportforDigitalAudioandVideo,pages255{266,Durham, NewHampshire,April1995. 167{186,Grenoble,France,June1994.Elsevier. enceonhighperformancenetworking,volumec-26ofifiptransactions,pages S.Fdida,editor,ProceedingsoftheIFIPTC6/WG6.4FifthInternationalConfer- [15]LutzHenckel.MultipeerConnection-modeTransportServiceDenitionbasedon [16]InternationalTelecommunicationUnion.DataProtocolsforMultimediaConferencing.DraftRecommendationT.120,1995. June1994. thegroupcommunicationframework.technicalreport,gmdfokus,berlin, [17]InternationalTelecommunicationUnion.ProtocolStackforAudiographicsand [18]InternationalTelecommunicationUnion.MultipointCommunicationServicefor AudiographicsandAudiovisualConferencing{ServiceDenition.RecommendationT.122,1993. AudiovisualTeleconferenceApplications.RecommendationT.123,1993. [19]InternationalTelecommunicationUnion.MultipointCommunicationService{ ProtocolSpecication.RecommendationT.125,1994. [20]InternationalTelecommunicationUnion.GenericConferenceControlforAudiovisualandAudiographicTerminals.DraftRecommendationT.124,1995. [21]InternationalOrganizationforStandardization.DraftTextontheSubjectof [22]LaurentMathy,GuyLeduc,OlivierBonaventure,andAndreDanthine.AGroup "Multi-peerTaxonomy".ISO/IECJTC1/SC6N9161/IV,March1995. Hanburg,Germany,June1994.North-Holland. editors,broadbandislands'94:connectingwiththeend-user,pages167{178, CommunicationFramework.InWulfBauerfeld,OttoSpaniol,andFionaWilliams, [23]InternationalOrganizationforStandardization.FirstDraftofEnhancedCommunicationsTransportServiceDenition.ISO/IECJTC1/SC6,March1995.
[24]J.Saltzer.OntheNamingandBindingofNetworkDestinations.InternetRFC [25]ClemensSzyperskiandGiorgioVentre.EcientSupportforMultipartyCommunication.InHutchisonetal.[39],pages185{198. 1498,August1993. [26]GeorgCarle,JochenSchiller,andClaudiaSchmidt.SupportforHigh-Performance [27]P.Mockapetris.DomainNames{ConceptsandFacilities.InternetRFC1034, November1987. MultipointMultimediaServices.InHutchisonetal.[39],pages219{240. [28]P.Mockapetris.DomainNames{ImplementationandSpecication.Internet [29]InternationalTelecommunicationUnion.TheDirectory{OverviewofConcepts, RFC1035,November1987. [30]BohdanSmetaniuk.DistributedOperationoftheX.500directory.Computer ModelsandServices.RecommendationX.500,March1995. [31]ErikWilde.SpecicationofGMSAccessProtocol(GAP)Version1.0.TechnicalReportTIK-ReportNo.15,ComputerEngineeringandNetworksLaboratory, NetworksandISDNSystems,21:17{40,1991. [32]InternationalTelecommunicationUnion.AssociationControlProtocolSpecication.RecommendationX.227,1988. SwissFederalInstituteofTechnology,Zurich,March1996. [34]InternationalOrganizationforStandardization.Informationtechnology{Quality [33]InternationalOrganizationforStandardization.Informationtechnology{Generic ofservice{framework.iso/cd13236,july1995. codingofmovingpicturesandassociatedaudioinformation.iso/dis13818,1995. [35]DanielBauer,ErikWilde,andBernhardPlattner.DesignConsiderationsfora [36]MichaelSample.Snacc1.1:AHighPerformanceASN.1toC/C++Compiler. shoponcomputercommunications,eastsound,washington,september1995. MulticastCommunicationFramework.InProceedingsoftheTenthAnnualWork- [37]MichaelSampleandGeraldNeufeld.ImplementingEcientEncodersandDecodersForNetworkDataRepresentations.InProceedingsoftheIEEEINFOCOM Technicalreport,UniversityofBritishColumbia,Vancouver,July1993. [38]RalfSteinmetz,editor.ProceedingsoftheSecondInternationalWorkshopon 1993.IEEEComputerSocietyPress. '93ConferenceonComputerCommunications,pages1144{1153,SanFrancisco, oflecturenotesincomputerscience,heidelberg,germany,september1994. AdvancedTeleservicesandHigh-SpeedCommunicationArchitectures,volume868 Springer-Verlag.
[39]D.Hutchison,A.Danthine,H.Leopold,andG.Coulson,editors.Multimedia TransportandTeleservices{ProceedingsoftheInternationalCOST237Workshop,volume882ofLectureNotesinComputerScience,Vienna,November1994. [40]D.Hutchison,H.Christiansen,G.Coulson,andA.Danthine,editors.Teleservices Springer-Verlag. shop,volume1052oflecturenotesincomputerscience,copenhagen,denmark, andmultimediacommunications{proceedingsofthesecondcost237work- November1995.Springer-Verlag.