Upload File

iceberg: an internet-core network architecture for integrated … · 2004. 7. 18. · we designed...

  • Home
  • Documents
  • ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to
13
1 ICEBERG: An Internet-core Network Architecture for Integrated Communications Helen J. Wang, Bhaskaran Raman, Chen-nee Chuah, Rahul Biswas, Ramakrishna Gummadi, Barbara Hohlt, Xia Hong, Emre Kiciman, Zhuoqing Mao, Jimmy S. Shih, Lakshminarayanan Subramanian, Ben Y. Zhao, Anthony D. Joseph, Randy H. Katz http://iceberg.cs.berkeley.edu/ Contact: [email protected] Computer Science Division, U. C. Berkeley Abstract—In the ICEBERG project at U. C. Berkeley, we are develop- ing an Internet-based integration of telephony and data services spanning diverse access networks. Our primary goals are extensibility, scalability, ro- bustness and personalized communication. We leverage the Internet’s low cost of entry for service creation, provision, deployment, and integration. In this article, we present our solutions to signaling, easy service creation, re- source reservation, admission control, billing and security in the ICEBERG network architecture. Keywords— integrated communication, service creation, scalability, availability, fault tolerance, customization, cluster computing platform, sig- naling, resource reservation, admission control, billing, security, privacy, authentication. I. I NTRODUCTION Telecommunications networks are migrating towards Internet technology, with voice over IP maturing rapidly. We believe that the key open challenge for the converged network of the near future is its support for diverse access technologies (such as the Public Switched Telephone Network, digital cellular net- works, pager networks, and IP-based networks) and innovative applications seamlessly integrating data and voice. The ICE- BERG Project at U. C. Berkeley is seeking to meet this chal- lenge with an open and composable service architecture founded on Internet-based standards for flow routing and agent deploy- ment. This enables simple redirection of flows combined with pipelined transformations. These building blocks make possible new applications, like the Universal In-box. Such an application intercepts flows in a range of formats, originating in different access networks (e.g., voice, fax, e-mail), and delivers them ap- propriately formatted for a particular end terminal (e.g., handset, fax machine, computer) based on the callee’s preferences. We designed ICEBERG, an Internet-core network architec- ture for integrated communications, to meet these goals: Potentially Any Network Services (PANS): This means that any service can be accessed transparently from any end-device via any access network, such as accessing e- mails via a cellular phone. To achieve this goal, we make our system design and implementation network and device independent , which allows new networks and their access devices to be plugged into the ICEBERG architecture with- out changes to the system. Personal Mobility: This is the concept of having the per- son (and not the communication device) as the communica- tion endpoint 1 . By using a single identity for an individual, we can implement a level of indirection to the desired end- point for communication. Personal mobility is a key mo- The concept originally comes from Personal Communication Services [40]. The Mobile People Architecture [9] also identifies this principle. tivation for integrating services across heterogeneous de- vices from diverse networks. Service Mobility: This refers to seamless mobility across different devices in the middle of a service session (for ex- ample, switching from a cell-phone to an IP-Phone in the middle of a conversation). Easy Service Creation and Customization: The design of the signaling protocol directly affects the ease of im- plementing call processing services, such as call forward- ing, call waiting, etc. Easy service creation also requires the system’s assistance for resource reservation, admission control and integrated billing for the new services. Ser- vice customization requires user preference management and user activity tracking. Scalability, Availability and Fault Tolerance: We aim to scale our system incrementally to support a large user base (i.e., large geographic regions and hundreds of thousands of simultaneous calls). The components of the network should be available 24 hours a day and 7 days a week. The architecture should be able to tolerate failures gracefully and hide them from end-users. To this end, we leverage Ninja [21], a companion project at Berkeley, which offers a cluster 2 computing platform for scalable, available, and fault tolerant services. We envision our network as islands of ICEBERG-capable Ninja cluster computing platforms which act as single large-scale computers, with a robust signaling protocol running between them. Operation in the Wide-area: The challenges in the oper- ation of the ICEBERG network in the wide-area are man- aging network partitions and achieving quality-of-service (QoS). Our protocols must detect network partitions and react to them promptly. QoS directly relates to resource reservation, admission control and billing. We tackle these problems with a distributed Clearing House architecture that selects the best packet traversal routes across vari- ous Internet Service Providers (ISPs), makes aggregated resource reservation and maintains billing information for each user. Security, Authentication and Privacy: Security and pri- vacy issues related to personal mobility are critical and re- quire careful attention especially in ICEBERG, which fol- lows an open service model in the Internet. We use a hy- brid of shared and asymmetric key cryptography at differ- ent stages of call setup or generic service access. We ap- ply optimizations at different levels to bring down network A cluster refers to a number of PCs interconnected by high-speed network.

Upload: others

Post on 28-Aug-2020

1 views

Category:

Documents


0 download

Report

TRANSCRIPT

Page 1: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

1

ICEBERG:�

An Inter net-coreNetwork Ar chitecture for Integrated Communications

HelenJ.Wang,BhaskaranRaman,Chen-neeChuah,RahulBiswas,RamakrishnaGummadi,BarbaraHohlt, Xia Hong,EmreKiciman,ZhuoqingMao,JimmyS.Shih,LakshminarayananSubramanian,

BenY. Zhao,Anthony D. Joseph,RandyH. Katzhttp://iceberg.cs.berkeley.edu/

Contact:[email protected],U. C. Berkeley

Abstract— In the ICEBERG project at U. C. Berkeley, we are develop-ing an Internet-basedintegration of telephonyand data servicesspanningdiverseaccessnetworks. Our primary goalsareextensibility, scalability, ro-bustnessand personalizedcommunication. We leveragethe Internet’s lowcostof entry for servicecreation,provision,deployment,and integration. Inthis article, we presentour solutionsto signaling, easyservice creation, re-sourcereservation, admissioncontrol, billing and security in the ICEBERGnetwork architecture.

Keywords— integrated communication, service creation, scalability,availability , fault tolerance,customization,cluster computing platform, sig-naling, resource reservation, admissioncontrol, billing, security, pri vacy,authentication.

I . INTRODUCTION

TelecommunicationsnetworksaremigratingtowardsInternettechnology, with voice over IP maturingrapidly. We believethat the key openchallengefor the convergednetwork of thenearfuture is its supportfor diverseaccesstechnologies(suchasthePublicSwitchedTelephoneNetwork, digital cellularnet-works,pagernetworks,andIP-basednetworks)andinnovativeapplicationsseamlesslyintegrating dataand voice. The ICE-BERG Projectat U. C. Berkeley is seekingto meetthis chal-lengewith anopenandcomposableservicearchitecturefoundedon Internet-basedstandardsfor flow routing andagentdeploy-ment. This enablessimpleredirectionof flows combinedwithpipelinedtransformations.Thesebuilding blocksmakepossiblenew applications,liketheUniversal In-box. Suchanapplicationinterceptsflows in a rangeof formats,originating in differentaccessnetworks(e.g.,voice,fax,e-mail),anddeliversthemap-propriatelyformattedfor aparticularendterminal(e.g.,handset,faxmachine,computer)basedon thecallee’spreferences.

We designedICEBERG,an Internet-corenetwork architec-turefor integratedcommunications,to meetthesegoals:� Potentially Any Network Services(PANS): This means

that any servicecan be accessedtransparently from anyend-device via any accessnetwork, suchas accessinge-mailsvia a cellularphone.To achieve this goal,we makeour systemdesignandimplementationnetworkanddeviceindependent, which allows new networksandtheir accessdevicesto bepluggedinto theICEBERGarchitecturewith-out changesto thesystem.� PersonalMobility: This is theconceptof having theper-son(andnotthecommunicationdevice)asthecommunica-tion endpoint1. By usingasingleidentity for anindividual,we canimplementa level of indirectionto thedesiredend-point for communication.Personalmobility is a key mo-�

Theconceptoriginally comesfrom PersonalCommunicationServices[40].TheMobile PeopleArchitecture[9] alsoidentifiesthisprinciple.

tivation for integratingservicesacrossheterogeneousde-vicesfrom diversenetworks.� Service Mobility: This refersto seamlessmobility acrossdifferentdevicesin themiddleof a servicesession(for ex-ample,switchingfrom a cell-phoneto an IP-Phonein themiddleof aconversation).� Easy Service Creation and Customization: The designof the signalingprotocol directly affects the easeof im-plementingcall processingservices,suchascall forward-ing, call waiting, etc. Easyservicecreationalsorequiresthesystem’sassistancefor resourcereservation,admissioncontrol and integratedbilling for the new services. Ser-vice customizationrequiresuserpreferencemanagementanduseractivity tracking.� Scalability, Availability and Fault Tolerance: We aim toscaleoursystemincrementallyto supporta largeuserbase(i.e., large geographicregionsandhundredsof thousandsof simultaneouscalls). The componentsof the networkshouldbeavailable24hoursa dayand7 daysa week.Thearchitectureshouldbe able to toleratefailuresgracefullyandhide themfrom end-users.To this end,we leverageNinja [21], a companionprojectat Berkeley, which offersa cluster2 computingplatform for scalable,available,andfault tolerantservices.We envision our network asislandsof ICEBERG-capableNinja clustercomputingplatformswhich act as single large-scalecomputers,with a robustsignalingprotocolrunningbetweenthem.� Operation in the Wide-area: Thechallengesin theoper-ationof the ICEBERGnetwork in thewide-areaareman-agingnetwork partitionsandachieving quality-of-service(QoS).Our protocolsmust detectnetwork partitionsandreactto them promptly. QoS directly relatesto resourcereservation,admissioncontrolandbilling. We tackletheseproblemswith a distributed Clearing Housearchitecturethat selectsthe best packet traversal routesacrossvari-ous InternetServiceProviders (ISPs), makes aggregatedresourcereservationandmaintainsbilling informationforeachuser.� Security, Authentication and Privacy: Securityandpri-vacy issuesrelatedto personalmobility arecritical andre-quirecarefulattentionespeciallyin ICEBERG,which fol-lows an openservicemodelin the Internet. We usea hy-brid of sharedandasymmetrickey cryptographyat differ-ent stagesof call setupor genericserviceaccess.We ap-ply optimizationsatdifferentlevelsto bringdown network�

A clusterrefersto anumberof PCsinterconnectedby high-speednetwork.

Page 2: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

2

round-triptimesaswell ascomputationalrequirements.For the rest of the paper, we first discussthe relatedwork

(SectionII). Next, we introducethe ICEBERG architecture(SectionIII). Then we describeour signalingprotocolwhichperformsthe call setupandcontrol (SectionIV). The key fea-turesof our signalingprotocolarethat it capturesall call ses-sion dynamics(suchas membershipchanges),toleratescom-ponentfailuresandtransientnetwork partitionsanddetectstheprolongednetwork partitions. Our signalingprotocolsupportsthemulti-devicecommunicationasa first-classservice.In Sec-tion V, we discusshow datapathcreationenableseasyservicecreation,thenwe presenthow our signalingprimitivessimplifythe implementationof servicesthat requireendpointchangesincluding a novel servicecalled servicehandoff which allowsusersto switchdevicesin themiddleof acall. Also, in thesamesection,we demonstratehow ICEBERGcomponentssimplifiedour tasksof providing the Universal In-box service, the NinjaJukeboxserviceand the Room Control Service. We illustrateour initial solutionsto resourcereservation,admissioncontrol,andbilling throughthe useof the ClearingHousearchitecturein SectionVI. Thenwe describeour securitymeasuresin Sec-tion VII andpresentour implementationandperformanceeval-uationin SectionVIII. Finally we discussour futurework andconcludein SectionIX.

I I . RELATED WORK

A wide assortmentof commercial products that provideservice-integration are becomingavailable: e-mail-to-fax ser-vices[20] [24], voice-e-mail-fax integrationservices[22] [26],andenhancedtelephony services[27]. Thesecommercialser-vicesshow thestrongdesirabilityof having personalized,inte-gratedcommunication.While they addressspecificintegratedservices,the ICEBERG architectureprovides building blocksandinfrastructurefor enablingany typeof services.

A desireto morerapidly deploy new servicesin thetelecom-municationsnetwork hasdriven the developmentof the Intel-ligent Network (IN). This is achieved by creatinga standard-ized servicecreationenvironmentindependentof the underly-ing vendor-specificswitch platforms. A critical enablingtech-nology for IN is SignalingSystem7 (SS7),an internationallystandardizedchannelsignalingsystemfor controllingswitchesanddatabasesthroughoutthe phonenetwork. ServiceSwitch-ing Points(SSPs)interceptcertainpatternsof call processingstepsto invoke servicelogic in ServiceControl Points(SCP).Theservicelogic theninfluencesthesubsequentcall processingsteps.It is throughsuchmechanismsthat800numberandcallforwardingservicesaredeployedin thePSTN.IN is intimatelycoupledto thehierarchicalswitchingstructureof thephonenet-work and the logical sequencingof call processingwhich, inreality, aredifferentamongvariousswitch vendors.Thereforeit hasfailed to provide serviceinter-operabilityacrossswitchesof differentvendors.In addition,thereis no elegantintegrationbetweenfixedandmobiletelephony services,let aloneintegra-tion with other typesof networks. Finally, servicecreationinIN hasa high cost-of-entryandis limited to a relatively smallnumberof network operators[13] (morespecifically, telecom-municationsserviceprovidersandnotendusers).

The IETF PINT working group, in particularits WebIN ar-chitecture[31], identified the difficulty of servicecreationin

IN. They proposedrunningthe servicelogic in the Internet(inotherwords,SCPsarepartof theInternetimplementedby non-proprietaryprogrammingor scriptinglanguages).Nonetheless,the difficulty of integratingwith othernon-telephony networksremains. We believe that this difficulty is inherentin PSTN-corebasednetworks. ICEBERG takesan Internet-corebasedapproach.By isolatingtheaccessnetwork specificfunctionali-tiesin only onecomponentof thesystem,addingnew networksis simplifiedin ICEBERG.In addition,ICEBERGeasesthecre-ationof services,includingnovelandsophisticatedservicesthatarebeyondtelephonecall features,throughtheflexible compo-sition of computationunits, powerful signalingprotocolprim-itives, and preferencemanagementand useractivity trackingcomponents(SectionV).

Hybrid services,in [12], are definedas servicesthat spandifferent network technologies,similar to our “PANS” con-cept. The hybrid servicearchitecturealso takes an Internet-corebasedapproach.Its network is composedof managednet-works (“clouds”) interconnectedby their edgegateways. Eachcloudhasaserviceplatform,amiddlewarelayerto provideasetof commonlyneededfunctionalcomponents.A cloud is anal-ogousto an ICEBERG-capableNinja clustercomputingplat-form. While their architectureis similar to oursat a high level,thedetailedmechanismsof preferencemanagement,namemap-ping, location tracking,signaling,andnovel serviceshave notyetbeendiscussed.

TOPS[3] is a packet telephony architecturewhich includesa directoryservice,applicationlayersignalingprotocol,a logi-cal channelabstraction,andanencapsulationformatto insulatetelephony applicationsfrom the underlyingnetwork transportcapabilities,andmechanismsto supporta varietyof conferenc-ing modes.The directoryserviceis the key componentof thesystem. It managesusers’call receiving preference,performsnamemappingbetweenterminal addressesand uniquenamesandtrackscurrentuserlocation. Thesethreefunctionalitiesareseparatedintodifferentcomponentsin ICEBERG(namely, Pref-erenceRegistry, NameMappingService,andPersonalActivityCoordinator)for bettermodularityandmoreeffectivedataman-agementsincethesethreetypesof datahavedifferentdynamics.Conferencecontrolin TOPSis accomplishedusinganexpandedsetof its signalingprotocol,while in ICEBERG,thebasicsig-naling readily supportsmulti-party calls. Issueson scalability,availability, fault tolerance,andwide-areaoperationsarenotad-dressedin TOPS,which we do in both our architecturedesignandthesignalingprotocoldesign.

The Mobile Peoplearchitecture(MPA) [9] [35] tacklestheproblemof personalmobility by introducinga personlayer ontopof theapplicationlayeremphasizingtheideathattheperson,ratherthanthedevice,is thecommunicationendpoint.Eachper-sonis identifiedby a globally uniquePersonalOnlineID. EachPersonalProxyis associatedwith apersonandperformsperson-level routingincludinglocationtracking,acceptingcommunica-tionson a person’s behalf,convertingthecommunicationsintodifferentapplicationformatsaccordingto preferences,andfor-wardingtheresultingcommunicationto theperson.Theuseofa PersonalProxy achieves locationprivacy. While a PersonalProxyis independentof theexisting network andtelecommuni-cation infrastructureand is easyto extendto new devicesandnetworks, one drawback is that regardlessof wherea personis, all communicationto the personmust go throughher Per-

Page 3: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

3

sonalProxy, which canyield inefficient routes. This canonlybe preventedby interceptingthe call signalingand resolvingthe calleedestinationduring the call setupinsteadof after thecall setupto thePersonalProxyin theMPA. This capabilityre-quiressupportfrom the infrastructure.ICEBERGarchitectureprovidessuchsupportby managinguserpreferencesandper-forming locationtrackingin the coreinfrastructureratherthanatendpoints.Here,weprovidea trustworthy infrastructurewithappropriatesecuritymechanisms.In addition,we preserve lo-cationprivacy by not revealinguserlocationsoutsidetheir ad-ministrative domains,namely, their ICEBERGserviceprovider(SectionIII).

For scalability, availability, andfault tolerance,we leveragecluster computingplatforms like Ninja [21] and Active Ser-vice (AS1) [1]. Although eachintendsto be a generalclustercomputingenvironmentthatsupportany cluster-basedservices,Ninja targetslong runningserviceswith infinite lifetimes(suchaswebservers),while AS1 focuseson serviceswith finite ses-sion lifetimes (like video-conferencing). ICEBERG containsboth kinds of services. We augmentNinja with AS1 featuresfor session-basedservices(SectionIII-A).

In termsof thesignalingprotocols,theITU’sH.323[23] andtheIETF’s SessionInitial Protocol[37] arethedominantInter-net Telephony signalingprotocols.Schulzrinne,et al., in [36],providesan extensive evaluationof H.323. H.323 is complexdueto its numerouscomponentprotocols,hardto extendduetoits requirementof full backwardcompatibilitybetweenversionsandcentrally registeredcodecs,non-scalabledue to its useofstatefulTCP connectionsfor signalingtransportanda centralcontrol for conferencecalls, and limited in preferencesupportfor customizableservices.Both SIPandour signalingprotocolprovide significantimprovementson theseaspects.NeitherSIPnor H.323 have addressedfault toleranceand scalablemech-anismsof trackingaccuratemembershipin a multi-party call,which we do(SectionIV).

Several bandwidthbroker implementationshave beenpro-posedin [34] as a scalablemechanismfor QoS provisioningover a Diff-Serv (RFC 2475)architecture.In [17], M. Gunteret al. presentedthe broker signalingtrade-offs in [8], but theydo not optimizeend-to-endpathselections.The Internet2QoSworking groupoperatesQbone[25], an inter-domainDiff-Servtestbed.They havestartedto investigatetheinter-brokersignal-ing to automatetheadaptive reservationscenario,but currentlythe brokersareconfiguredmanually. Duffield et al. describein [10] anadaptivereservationschemethatis optimizedfor vir-tual privatenetworks (VPNs), andcompareits performancetostaticprovisioningusingreal traffic traces.However their workonly considersa singleISPscenario.Our ClearingHouse(CH)design(SectionVI) providesa scalableapproachfor inter-ISPsignalingandcoordinatesresourcereservationsbetweenmulti-ple ISPsdynamically. TheCH usesa capabilitybasedsecurityscheme,similar to Kerberos[38], that requiresusersto presentticketsto useISPservices.Wepickedacapabilitybasedsecurityschemeinsteadof anaccesscontrolbasedschemeto ensurefastcall setuptime. The CH alsoprovidessecurebilling services,which, to our knowledge,havenot beenaddressedbefore.

Fig. 1. ICEBERGArchitectureOverview

I I I . ICEBERG ARCHITECTURE

Figure1 depictsthe ICEBERGarchitecture.TheICEBERGnetwork planeshows two ICEBERGServiceProviders repre-sentingtwo differentadministrativedomains:A andB. Theser-vicesthey provide arecustomizableintegratedcommunicationserviceson top of the Internet. Similar to the way that Inter-net ServiceProviders (ISP) provide Internetservicesthroughthe useof Pointsof Presence(POPs)at different geographiclocations3, ICEBERG ServiceProvidersconsistof ICEBERGPointsof Presence(iPOPs). Both A andB have iPOPsin SanFrancisco(SF) andNew York (NY). EachiPOPcontainsCallAgents(CAs) which performcall setupandcontrol, an Auto-maticPathCreationService(APC) which establishesdataflowbetweencommunicationendpoints,a PreferenceRegistry (PR)for users’call receiving preferencemanagement,aPersonalAc-tivity Coordinator(PAC) for userlocationor activity tracking,andaNameMappingService(NMS) whichresolvesusernamesin variousnetworks. iPOPsmustscaleto a largepopulationanda largecall volume,behighly availableandberesilientto fail-ures.This leadsusto build the iPOPon theNinja clustercom-putingplatform. TheICEBERGnetwork is anoverlaynetworkof iPOPson top of theInternet.

ICEBERGAccessPoints(IAPs) arethe gatewaysto the ac-cessnetworks,suchasthe PSTN,GSM cellular networks,andthe pagernetworks. They serve asbridgesbetweenthe accessnetwork planeandtheICEBERGnetwork plane.

EachiPOPemploys an InternetServiceProvider (ISP)4 (forexample,in Figure1, SF iPOPsof bothA andB employ ISP1,NY iPOPsof A andB employ ISP3). The ISP makesservicelevel agreementsandpeeringarrangementswith other ISPstocarry thetraffic amongiPOPs.TheClearingHouseservesasabandwidthbroker andaccountantfor iPOPsandinteractswiththeISPs.

Establishinga new ICEBERGServiceProvider, is simply a�ISPsgenerallylocatePOPssuchthat userscanmake a local call andgain

Internetaccess.�Pleasenote that ICEBERGserviceprovidersarecompletelyorthogonalto

InternetServiceProviders

Page 4: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

4

matterof creatingan iPOPwith an NMS, PR, PAC, andAPCservicerunningon it, and IAPs for the accessnetworks to besupported.Differentserviceprovidersmaysharetheir compo-nents,suchasthe IAPs, basedon somepre-establishedagree-mentsor arrangements.

In our system,theNMS, PR,andPAC areusedin thecontrolpath. The APC serviceestablishesandmanipulatesdataflows(for example,voicestreams).The IAP dealswith bothcontrolpath(signalingtranslation)anddataflow (voicestreampacketi-zation).

For therestof thesection,we first describehow we leveragethe clustercomputingplatforms. Thenwe describeeachICE-BERG componentin detail. Finally, we presenta scenariotoillustratehow ICEBERGcomponentsinteractwith oneanother.

A. LeverageClusterComputingPlatforms

EachiPOPrequiresprocessingscalabilityto a largecall vol-ume, ����� availability5 through fault masking, and cost-effectiveness. Clustersof commodity PCs interconnectedbya high-speedSystemArea Network (SAN), acting as a sin-gle large-scalecomputer[2] (assumingno network partitionswithin a cluster), are especiallywell-suited to meetingthesechallenges[16]. Cluster computingplatforms like the NinjaBase[11] and Active ServicePlatform (AS1) [1] provide aneasyservicedevelopmentenvironmentfor servicedevelopersand mask them from cluster managementproblemsof load-balancing,availability, and failure management.We describebriefly theunderlyingmechanismof bothplatformsandhow weleveragethem.

In a Ninja Base, eachnodehousesanexecutionenvironmentinto which mobile codecan be pushed. Serviceshave manyinstanceswithin the clusterfor fault tolerance,but clients areshieldedfrom this by usingaserviceRedirectorStubto interactwith the cluster. The RedirectorStubfor a serviceis dynami-cally generatedat run-timeandcontainstheembeddedlogic forclientsto selectoneserviceinstancefrom a setof nodeswithinthe cluster. Within the Base,all nodesmaintaina replicatedregistry of all serviceinstances;eachnodeperiodically sendsout a multicastbeaconcarrying its list of local servicesto allother nodesin the Baseand listensfor the multicastbeaconsfrom other nodes. The Basealso maintainspersistentservicestates.As a result,thefailureof a serviceinstanceon onenodeautomaticallytriggersanotherserviceinstanceto take over forthe failed one. To the outsideworld, a Baseactslike a non-distributed,robust,highly-available,andhigh-performanceser-vice.

AS1 platform differs from the Ninja Baseapproachin thatserviceclientssendkeep-aliveservicerequestsinsteadof usingredirectorstubs. AS1 maintainsa tablemappingeachservicerequestto its associatedserviceagent. A new servicerequestcausesAS1 to spawn a new serviceagent,andto entertheser-vicerequestandagentpair into thetable.A timeoutonaservicerequestin thetableindicatestheendof theservicelifetime, andcausesthetableentryto beremoved.A failedserviceagentwillalsocauseits entry to beremovedfrom the tablejust the sameasin a Ninja Base.Servicerequestscontainthecurrentsessionstate,andserviceagentsareentirelysoft state. ��������

: 24hoursa dayand7 daysaweek.

We run iPOPson Ninja Baseswhichshouldhaveat leasttwonodesin the clusterfor load-balancingandfault tolerance. Inaddition,we have addedsupportfor the keep-alive servicere-questfrom AS1: call requestsare the servicerequests;CallAgents are serviceagents. We run the PreferenceRegistry,NameMappingService,PersonalActivity Coordinator, andAu-tomaticPathCreationServiceonNinja Bases,whichhandlethefaultdetectionandrecoveryof thesecomponents.For therestofthepaper, “iPOP” refersto anICEBERG-capableNinja Base.

B. NameMappingService

PersonalMobility is akey mechanismfor managingcommu-nication acrossheterogeneousdevices from diversenetworks.Theideaof PersonalMobility is to maketheperson6, andnotthecommunicationdevice,bethecommunicationendpoint[9] [40]Theconceptisbecomingmoreimportantaspeopleacquiremoreandmoreenddevices. By usinga single identity for an indi-vidual, ICEBERGprovidesa level of indirectionto thedesiredcommunicationendpoint.

In ICEBERG, we associateeach user with an ICEBERGUniqueID (iUID). Thestructureof iUIDs is still anopenprob-lemin ICEBERG.For now, aniUID takestheform of ane-mailaddress. The NameMapping Servicemaintainsthe mappingbetweenthe users’variouscommunicationendpointsandtheiriUIDs.

C. ICEBERGAccessPoint

An ICEBERGAccessPoint(IAP) is a gateway thatintercon-nectsanaccessnetwork with therestof theICEBERGnetwork.It consistsof hardwareandsoftwarefor transcodingbetweenthesignalingprotocolsandthedataformatsusedby theaccessnet-work and thoseusedby the ICEBERGnetwork. For keepingtrack of eachstageof the call initiation process,an IAP main-tainscall statemachinesfor all thecalls(eitherinboundor out-bound)handledby it, in cooperationwith the accessnetworksignalingprotocol(likeSS7);andtheIAP issuesICEBERGcallrequeststo theiPOPs.

RunninganIAP onaNinja Basewouldprovideminimalben-efits, asan IAP includesa network-specificgateway that maycontainhardstatefor eachcall (afunctionof thesignalingproto-col usedby theaccessnetworks).Suchaccessnetwork-specificstatecannotbe replicated,thusthe failureof an IAP causesallcalls handledby it to be dropped(asa comparison,the failureof a BaseStationController in the GSM network would causeall callshandledby it to bedropped).Thus,it is thegateway’sresponsibilityto provide theappropriatelevel of fault tolerancefor its accessnetwork.

D. Call Agent

A Call Agent is a serviceagentthatperformscall setupandcontrol for a caller’s device. A Call Agent interactswith theClearingHousefor resourcereservation,call admissioncontrolandaccounting,with a NameMappingServiceto resolvecalleror calleeidentitiesor addresses,with the PreferenceRegistryfor the desirablecall receiving device, andwith the AutomaticPathCreationServicefor dataflow establishment.Thereis oneCall Agentperdevicepercaller. An iPOPspawnsa Call Agent�

It is possibleto nameroles(e.g.,departmentchair, graduateadmission)aswell asindividuals.

Page 5: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

5

on a nodein the clusterwhenever a call request(for eitheraninboundor outboundcall) arrivesat theiPOP. TheCall Agentiskeptaliveby theperiodiccall requestsfrom its client(thedeviceor its IAP). TheCall Agentis terminatedwhenthecall requestsceaseafterthedevicehangsup.

We choosenot to build Call Agentsor iPOPsaspart of theIAPs for threereasons.First, call setupandcontrol within theICEBERG network is the samefor all accessnetworks. It isnot desirableto duplicatethis functionality in the IAPs of eachaccessnetwork from the software engineeringpoint of view.Second,sinceIAP failurescausecall drops,we want to mini-mizetheamountof logic in IAPs,andthereforemakethemlessfailure-prone.Lastly, building iPOPinto anIAP doesnot scaleto a large numberof calls asan accessnetwork gateway con-tainedin anIAP canonly handlealimitednumberof calls,whilean iPOPasa separateentity canhandlecalls from many IAPs.The benefitof this decouplingis that IAPs arethe only accessnetwork dependentcomponents.All other ICEBERGcompo-nentsaredesignedin anetworkanddeviceindependentfashion.This greatlysimplifiestheexpansionof ICEBERGto new net-worksanddevices.

E. AutomaticPath CreationService

TheAutomaticPathCreationService(APC) establishesdataflows betweencommunicationendpoints.A datapath is anab-stractionof a dataflow – a setof transcodingoperators strungtogetherusingconnectors [21]. An operatoris a unit of compu-tationonsomedata,andaconnectoris anabstractionof theAp-plication Data Unit (ADU) transportmechanismbetweentwooperators(e.g.,RTP connector, UDP connector, etc.). For in-stance,a seriesof codecoperatorsfollowedby a speech-to-textoperatoris a path.Data path is a powerful conceptfor enablingcommunicationamongheterogeneousend-devices becauseofits flexible servicecomposability.

In our architecture,Call Agentsmake requeststo the APCservicefor datapathcreation.TheCall AgentsprovidetheAPCservicewith endpointinformation, suchas the endpoint’s ad-dress(e.g.,IP addressandport numberfor a desktopphone,thephonenumberand cellular gateway addressfor a cell phone)andtransportprotocol(e.g.,RTP).Theemploymentof APCen-capsulatesthedatapathcreationandinstantiationprocessfromtherestof thesystem,andcleanlyseparatesdatafrom control.

F. ClearingHouse

The ClearingHouse(CH) is a third-partyentity (outsidetheICEBERGServiceProviders)thatmanagesthe traffic flow be-tween the ICEBERG Network planeand the ISP Plane(Fig-ure1). This entity interpretstraffic specificationsreceivedfromtheiPOP, andsearchesfor theoptimalpacketflow pathfrom thesenderto thereceiveron theISPplane.TheCH alsomaintainsresourcereservationsacrossISPs,performsadmissioncontroland provides authenticationand securebilling servicesto theICEBERGarchitecture.We assumethat theCH canbetrustedby both the ISPsand ICEBERG,and ISPscooperatewith theCH for resourcereservation. We illustratethe CH architecturein moredetail in SectionVI.

Note that thepacket flow pathis differentfrom thedatapathdescribedin the previous section: the former describesthe se-quenceof ISPsthe packetstraverse,while the latter refersto a

sequenceof operatorsassociatedwith connectors.Wewill showin SectionV-A thateachdatapathis containedin oneiPOP, sotheoperatorsandconnectorsof a pathliveon thesameiPOP.

G. PreferenceRegistry

To achievethegoalof customizablecommunicationservices,we needmechanismsfor user preferencemanagement.ThePreferenceRegistry is sucha servicethat storesandprocessesuserpreferences.It takesasinput thecaller ID, calleeID, timeof day, anddynamicuserinformation(e.g.,currentlocationorcurrentuserbehavior), and returnsthe callee’s preferredend-point (e.g.,cell-phonenumberor e-mail address).During callsetup,thePreferenceRegistry is queriedfor a callee’spreferredendpoint. Usersconvey their preferences(suchas when theywant to be called,on what device, by whom) usinga tool thatgeneratesscripts(e.g.,Perl,Tcl, or somecall processingspecificscriptinglanguage)andstoresthemin thePreferenceRegistry.

H. PersonalActivityCoordinator

The Personal Activity Coordinator (PAC) assiststhe Pref-erenceRegistry for morepowerful servicecustomization.ThePAC tracksa user’s currentactivity (for example,“Alice is onher cell phonewith Bob, who is a VIP”) and other dynamicevents,suchasa user’s currentlocation,or the call statusof adevice– busy, on-hold,etc.ThePAC allowsusersto controlpri-vacy policies,suchaswhichinformationis trackedandto whomtheinformationcanbereleased.TheinformationmaintainedinthePAC is usedby thePreferenceRegistry asadditionalinputsand hints in processinguserpreferences.This information isstoredassoft state. Somedefault userbehavior is assumedifthePAC doesnot provideany information.

I. An Illustration

In thissection,weillustratehow ICEBERGcomponentsworktogetherto provideapersonalizedcall handlingservicethrougha scenario:Alice usesher cell phoneto dial Bob’s cell phonenumber. Bobcurrentlyprefersto receivephonecallsfrom Aliceon his officePSTNphone.

Thecall from thecell phoneis interceptedat anIAP (or onecould imaginethat Alice first dials into an IAP). The IAP lo-cates7 an iPOPfor Alice andissuesan ICEBERGcall requestto the iPOP. The iPOP informs the CH aboutthe call requestsothattheClearingHousecanmakeresourcereservations,per-form admissioncontrolanddo accounting.If thecall is admit-ted, the iPOP spawns a CA to serve Alice’s cell phone. TheCA first findstheidentity of thecalledparty(i.e.,Bob),aswellas the location of Bob’s PreferenceRegistry, using the NameMappingservice.It findsBob’spreferredendpoint,andreturnsan appropriateiPOPfor reachingthe callee8, from his Prefer-enceRegistry. The calleeiPOPalso interactswith the CH forresourcereservation, admissioncontrol andaccounting.Next,Bob’s iPOPspawnsa CA to serve Bob. This CA thenlocatesaPSTNIAP to ring Bob’s office phone.WhenBob picksup thephone,the CAs interactwith the APC serviceto establishthedatapath. From this point on, Alice andBob arein conversa-tion.�

This canbedonethroughsomeservicediscovery service.�Pleasenotethatthepreferredcall receiving endpointitself is not returnedfor

userprivacy.

Page 6: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

6

IV. THE ICEBERG SIGNALING SYSTEM

A signalingsystemis a collectionof network elements,CallAgents(CA) in our case,thatusea communicationprotocoltoeffectcall setup,routing,andcontrol. In thissection,wepresentthe ICEBERGsignalingsystem.We follow thesameapproachof separatingsignalingfrom dataasin many othercommunica-tion systems.Also, our signalingprotocolis independentof theaccessnetworks. Detailedsecuritymeasuresfor signalingarepresentedin SectionVII.

Currenttelecommunicationsystemsdesignedtheir signalingprotocols,suchasSS7for thePSTN,to supporttwo-partycallswith homogeneousdevices(i.e., telephones),as the basiccallservice. Additional services,suchascall forwardingandcon-ferencecalls,areimplementedthroughoverriding,augmenting,andreusingthebasiccall signalingprimitives.As aresult,theseservicesincur extra expensesto users.In ICEBERG,we aim toprovidemoresophisticatedbasicserviceswith little costto userswhile enablingmorepowerful servicebuilding primitives. Ourarchitecturesupportsmulti-device communicationasthe basiccall serviceandallows it to becomea commoncase.A multi-device call caninvolveanunlimitednumberof participantsandheterogeneousdevices9 (for example,usinganaudiotool andavideo tool togetherfor a call). Theseprimitivesmake services,suchasconferencecalls, call forwarding,anda novel servicecalledservicehandoff, trivial to implement. We detail this inSectionV. Weassumethatin amulti-devicecall, thecall partic-ipationis invitation-based,andnotsubscription-based.Any callparticipantcaninvite new partiesto join thecall.

A multi-device call canbehighly dynamic.New devices(ornew call parties)may be invited to join the call (possiblysi-multaneously),andthey mustestablishdataflowswith eachcallparticipant. A participatingdevice may leave the call, and itsCA needsto teardown a portion of the datapath. In addition,CAs that serve the call may fail, thenget restartedwith a newidentity at a new location.Thenew CA mustobtainthecurrentstateof the call (suchas the currentcall membershipandde-vice status)includingthestatechangesthatoccurredduringthefault recovery process.Network partitionsmayalsooccur, andthenarehealed.The statechangesoccurringin eachpartitionmust be capturedby the participants. The signalingprotocolmust addressthe issuesof maintainingaccuratecall member-ship andcapturingthe completecall statein faceof any faultsand in a scalablefashion. To our knowledge,thesehave notbeenaddressedeffectively in otherInternetTelephony signalingprotocols.

For call membership,weintroducethenotionof acall sessionamongacollectionof communicatingCAs. Thecommunicationis broadcastmessagesto asharedgroupcommunicationchannelper call session,ratherthanpairwisecommunicationsbetweenCA pairs. This yieldsscalabilityto a largenumberof call par-ticipants.Thechanneloffersa level of indirectionthathidestheidentity andthelocationof theCAs andrelieveseachCA frommaintainingthedynamicsessionmembership– this effectivelyaddressestheissueof membershipdynamics.

Now we turn to the issueof call state. New participantsina call sessiondo not have thesessionmembershipinformation,�

A call partycanusemultipledevicesat thesametime in a coordinatedway.If thesedevicesareusedin anuncoordinatedway, thenthecall party is merelymakingmultiplecallsat thesametime.

andthereforedonotknow whereto obtainthecompletesessionstate.Werejecttheapproachof usingacentralizedsessionstatemanager. This would introducea singlepoint of failure andabottleneckin the control pathsinceall stateupdatesmustflowthroughit. Finally the single entity managingcall statemustalsoimplementrigorouserrordetectionandrecovery, incurringprotocolcomplexity andimplementationoverhead.Rather, wemaintain the call stateas soft state [6]. Soft stateis definedoperationallyas statethat is periodically refreshedby updatemessages.Protocolactionsaretriggeredby new messagesandtimer expirations. Becausethe sessionstateis sentto the callsessionperiodically(seeSectionIV-B for details),newcomersto a sessionwill automaticallyobtain the currentsessionstatethroughtheseupdatemessages(with somelatency).

The useof the sharedgroup communicationchannel,com-binedwith asoftstateprotocolfor call statemanagement,mapsperfectlyontotheLight WeightSession(LWS)architecture[33].LWS is describedasa lightweight(soft state),loosely-coupled,anddecentralized(anonymousCAs)communicationmodel.WeuseIP multicastasthesharedgroupcommunicationchannelandcall sessionsareidentifiedby multicastaddresses.

Usingonemulticastaddresspercall sessionraisestwo scal-ability concerns:multicastaddressscarcityandscalingroutingstateto alargenumberof smallmulticastgroups.Thefirst prob-lem, due to the flat IPv4 multicastaddressspace,will vanishwith the deploymentof IPv6 [4], MASC [18], or with new IPmulticastmodelslikeSimpleMulticast[14] andExpressMulti-cast[19]. For thesecondproblem,by pushingtheroutingstateto edgeroutersof thebackbone[5], or to endsystems[28] (suchasiPOPs),andbuilding the control structureacrosstheseedgeroutersor endsystemsthroughtunneling,the accumulationofthe routing statefor all the multicastgroupsin the backboneis prevented,and this yields scalability to a large numberofgroups.

Oursignalingprotocolconsistsof two phases:call sessiones-tablishmentandcall sessionmaintenance.Thefirst phaseis theformationprocessof the call session,namelyinstantiatingtheCAs, which in turn join themulticastsession.The latterphaseinvolvesexchangingcall statesamongthe CAs in the session,andcreatesor modifiesthe datapathbasedon the call states.In [39], we describedour signalingapproachandcall sessionmaintenancein greaterdetail.

We first describethe call sessionestablishmentprotocol inSectionIV-A, thenthecall sessionmaintenanceandcontrolpro-tocol in SectionIV-B.

A. Call SessionEstablishment

The communicationin this phaseis pairwiseamongCAs.Groupcommunicationtakesplaceafter the sessionis initiallyestablished(SectionIV-B).

Figure2 shows themessageflowsandstatetransitionsin callstatemachineson IAPs duringa call sessionestablishment.Weusedthefollowing techniquesto provideafaulttolerantcall ses-sionestablishmentprotocol:� For all thecallshandledby anIAP, theIAP sendsperiodic,

idempotent,andstatefulICEBERGcall requests,astheirkeep-alive heartbeats,to their servingiPOPs.Thecall re-questscontainthe currentstatein the call statemachinesmaintainedon theIAPs,andareidentifiedby thecall party

Page 7: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

7

Initial

O_CallingCR (O_Calling,

call info)

Initial

T_RingingOrBusy

Established

O_RingingOrBusycall info)

CR (O_Rng/Bsy,

Call SessionEstablishedCR(Established,

call info)

Caller IAP

Outgoing Call Request

iPOP

CA CA

iPOP

InstallState (T_RingedDev, call info)

(ringing or busy)Device Response

Device picked up

Callee IAP

Receive-Call-Reply

call info)

call info)

CR(Established,

CR (T_RingingOrBusy,

Receive-Call (call info)

device response) Receive-Call-Reply

(device status)

Announcecall state

Listen

InstallState (Establish)

Announce

call state

CR: Call RequestCA: Call Agent

O_ : call Originating statesT_: call Terminating states

: iPOP routes the message to a CA

T_RingedDevCR (T_RingedDev,

call info)

InstallState (O_RingingOrBusy,

Listen

Fig. 2. Call SessionEstablishment

iUID andhis/herdevice in use.� The call requestsare handledby the call statemachine-aware(but softstate)CAs. An iPOPmaintainsatablemap-ping eachcall requestto its associatedCA just thesameasin AS1. iPOPsareresponsiblefor routingthecall requestsandothermessagesto their servingCAs,or spawningnewCAs for new call requests.Basedon the call statecarriedin acall request,theCA performsappropriateactions,suchasnamelookupor PreferenceRegistry lookup,etc.� CAs advancethe call statemachineson the IAPs to thenext stateby sendingperiodic “InstallState” messagestotheIAPs until call requestswith thenew statearrive at theCAs.� Inter-iPOPcommunicationalsotakestheform of idempo-tent soft stateheartbeatmessagesfor thedetectionof net-work partitionsbetweentheiPOPs.

Thenatureof soft stateandidempotentmessagesenablesourprotocol to recover gracefully from transientfailureswith noextra logic in additionto thenormaloperation.In addition,pro-longedfailurescanbedetectedandtheappropriateclean-upac-tionstakenin reactionto them.

Now we illustratethefaultdetectionandrecoveryof ourpro-tocol in detail. CAs arekeptalive by theperiodiccall requestsfrom IAPs. WhenaCA fails,thenext call requestwill causetheiPOPto spawn a new CA for thecall. Thecall requestcontainssufficient statefor the new CA to continuethe serviceof thecall. A timeouton call requestsindicatesthat eitherthe callerhashungup thecall or theIAP is network partitionedfrom theiPOP. As a result, the iPOPterminatesthe associatedCA, andremovesthecall requestandCA pair from its table.

Timeoutson the heartbeatsbetweenthe two iPOPsindicatean extendeddurationof network partition betweenthe iPOPs,andthecall establishmentis aborted.

iPOPsalsosendheartbeatsto IAPs so that the IAPs cande-tectnetwork partitionsbetweenthemselvesandIAPs(notshownin thefigure). A non-transientnetwork partitioncausesan IAPto usean alternative iPOPto continuecall establishment.Theheartbeatsbetweenthe two iPOPsconvey the new identity ofthe iPOPto theotheriPOP. Thesoft statemessagesexchangedbetweenthetwo iPOPseliminatetheneedfor explicit error re-

coveryon bothiPOPs.

B. Call SessionMaintenanceandControl

Following the call sessionestablishmentphaseis the callmaintenancephase.During this phasethecall participantsmayhangup or interactwith their devicesin the middle of the call(e.g.,invite a new call party, switchto a new device,or performcall forwarding,etc.). This phaseinvolvesalteringandpropa-gatingcall statesto all the CAs in the establishedcall session.Thecall stateof a call sessionincludescall party identities,theinvolvedcommunicationdevicesandtheir status(e.g.,busy oronhold),datapathendpointinformationfor all thedatastreamsin the session(e.g., IP addressesandport numbersof the datastreamendpoints,locationof transformationagents,etc.),andthetimethecall stateis sent.Maintainingdynamiccall sessionsandcarryingout the control functionsin a fault tolerantfash-ion completesthe designof a robust signalingsystem. In thissection,we describethecontrolprotocolin detail.

EachIAP periodicallysendsthecall requestwith theEstab-lished stateto the iPOP in this phase,as shown in Figure 2.Thecall requestcontainsthecall stateof its endpoint.Thecallstateis oneof therows in TableI. TheCA, in turn,periodicallyannouncesthe call statein the call requestto the call session.At the sametime, the CA alsolistensto the multicastchannelandreceivescall statesof theotherendpoints.Hence,eachCAmaintainsthecompletecall stateof acall session:theentireTa-ble I, eachentryof which is uniquelyidentifiedby “iUID” and“Device” (the primary key of the table). The reliability of callstatepropagationis ensuredsimply by periodicretransmissionover thelifetime of thecall session.

iUID Device Status PathEndpointInfo Timesent

[email protected] laptop busy 123.3.4.5/9876 13:34:45:[email protected] cell phone busy gw: 10.3.2.2/66 13:34:42:87

time slot: 5... ... ... ... ...

TABLE I

CALL STATE IN A CALL SESSION

Page 8: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

8

The combinationof periodicity and the useof multicast isoften called the announce/listenmodel in the literature, andis appropriatewhereeventualconsistencyratherthan transac-tional semanticsaresufficient. A desirablepropertyof the an-nounce/listenmodelis that componentfailuresaretoleratedasnormaloperations,ratherthanaddressedthrougha separatere-covery procedure[1]. Recovery is enabledby simply listeningto channelannouncements.Theannounce/listenmodelinitiallyappearedin IGMP [7], andwasfurtherdevelopedandclarifiedin systemssuchas the MBone SessionAnnouncementProto-col [32].

Whena CA receivesa new call state(i.e., if the state’s keycannotbefoundin thecall statetable),it knowsthatanew end-point just joinedthecall session,andthis CA needsto establisha datapathto thenew device throughtheAutomaticPathCre-ationService(morein SectionV-A). Call statechanges(for ex-ample,changingthe datapathendpointinformation)aremadeby theIAPsthroughperiodiccall requestswith themodifiedcallstate,andthenthemodifiedstateis propagatedto thecall sessionthroughtheCA’speriodicannouncements.WhenaCA receivesa modifiedcall state,the associateddatapathwill be modifiedaccordingly.

EachCA of asessionis obliviousto thetransientfailuresandrecovery of the otherCAs, sincethe recoveredCA only needsto join the signalingmulticastgroupandre-build the call ses-sion state(including the additionalsessionstatechangesmadeduring theCA fault recovery). Prolongedfailuresof a CA willcausethe device it serves to be cut off from the session.Ex-tendednetwork partitionsamongiPOPsinvolved in a call dur-ing this phasearedetectedby the call statetimeouts,andfor amulti-partycall, thecall maybepartitionedinto multiple calls.Nonetheless,thepartitionedcallswill automaticallyre-integratewhenthenetwork partitionsarehealed.

Despitethe simplicity of the design,this schemehandlessi-multaneouscall statechangesatmultiple CAsgracefully.

We areinvestigatingthe appropriatechoicefor heartbeatin-tervals. This variableaffectsthetime to recognizenetwork par-tition andIAP failures.

C. Discussion

Thesignalingsystemdescribedabovemeetsthefollowingde-signgoals:� Fault Tolerance: Throughtheuseof lightweightcall ses-

sionandsoft stateprotocols,thesignalingsystemtoleratescomponentfailures,adaptsto dynamiccall sessionmem-bershipanddetectsnetwork partitions.� Scalability: The useof groupcommunicationratherthanpairwise communicationfor signaling scalesto a largenumberof call participantsin acall.� Network and Device Independence: Our signalingpro-tocol is designedto beindependentof theaccessnetworksanddevices.

V. SERVICE CREATION

Easyservicecreationis an essentialgoal of the ICEBERGarchitecture.Theconceptof a datapathis anenablerandsim-plifier for servicecreation,which we discussin SectionV-A.Our signalingprotocolprimitivesandotherICEBERGcompo-nents,suchasthePreferenceRegistry, NameMappingService,

PersonalActivity Coordinatoralsoempowernovel servicesandsimplify their creationprocess,which we illustrate in the fol-lowing sections.

A. Data Path,a Simplifier

Datapathconstructionestablishesthe flow of databetweenthe communicationendpointsof differentcall parties. A pathconsistsof a sequenceof operatorsand connectors(seeSec-tion III). The power of the pathconceptcomesfrom the flex-ible composabilityof operatorsandconnectors.Giventwo end-pointdataformatsandlocations,theAPCserviceautomaticallyconstructa pathconsistingof a sequenceof operatorswith ap-propriateconnectorsandmaintainsthe path in a fault tolerantfashionby restartingfailedoperatorsandconnectors.Wedonotyet have a full-fledgedAutomaticPath CreationService. ThecurrentAPC serviceonly createsandplacespredeterminedop-eratorsat the appropriatelocations.An operatordescriptionisassociatedwith eachoperatorfor its creation(which code toexecute),placement(which host in the cluster), and destruc-tion (what to cleanup after the operatorterminates).Modify-ing a datapathinvolveschangingtheoperatordescriptions,andrestartingor modifying thecurrentlyexecutingoperators.

Creatingpathsin the wide areaand maintainingthem in afault tolerantfashionarethemainchallengesfor datapathcre-ationandmaintenance.A centralizedAPC serviceresponsiblefor instantiating,executing,andmaintainingthepathsis notap-propriatefor the wide area,becausewhen it is out of service(from hostcrashesor network partitions),it orphansall thepathsit maintains(with operatorsandconnectorsrunningondifferenthosts). In addition,the reality of themultiple independentser-vice providersprecludesthe practicalityof usinga centralizedAPCservice.

Distributedpathcreationandmaintenanceposedifficult ques-tionsof pathownershipandaccesscontrol(i.e.,who is allowedto createor destroy paths).Also, oursignalingprotocolis basedon an asynchronous(soft state),anonymous10 (usingmulticastaddressasalevel of indirectionandtherendezvous)groupcom-municationmodel,whichmakestheprotocolincompatiblewithsynchronouspath creationand maintenancebetweenpairs ofendpoints.Multiple ownersof a singlepathwould needto co-operatesynchronouslyto createanddestroy thepath,soa pathshouldbeownedby only oneentity. This is somewhatcounter-intuitive since a path describingthe communicationbetweentwo devicesdoesindeedinvolve two endpoints,andtherefore,thepathis perceivedto beownedby thesetwo endpoints.

Instead,we presentadifferentview for this scenariowith thefollowing additionalinformation: an intermediatedataformat(thatmaycoincidewith thedataformatsupportedby eitherend-point). Fromeachendpoint’s view, all it needsto do is to con-structadatapathto sendandreceivedatausingtheintermediatedataformat. This essentiallydecomposesthe communicationbetweentwo devices into two pathswith the output datafor-mat of onepaththesameasthe input dataformat of theother,namelythe intermediatedataformat. This way, eachendpointownsits half of thepath,andit createsanddestroysthedatapathautonomouslywith no needto synchronizewith theotherend-���

Anonymity hererefersto thefact thatany CA is oblivious to dynamicses-sionmembership,anddoesnotmeanthatanyonecanparticipatethecall session.In fact,call participationis invitation based,andnotsubscriptionbased.

Page 9: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

9

point. Eachhalf-pathcanbecomposedof operatorsall runningonthesameiPOPthatis servingtheendpoint,soit is reasonableto runasingleAPCserviceoneachiPOP(wherenetwork parti-tionsarerare),responsiblefor creatinghalf-pathsfor endpointsservicedby thatiPOPs.Likeany Ninja service,theAPCservicewill behighly availableandfault tolerant.

The intermediatedataformat is determinedin the followingmanner. EachiPOPknowswhatoperatorsandconnectorsit hasandwhich are running. Therefore,it canexport a list of dataformatsthatit supports.During thecall setup,thecaller’s iPOPobtainsthis list from thecallee’s iPOP. Thenit selectsa match-ing dataformat asthe intermediatedataformat. We currentlytake thefirst match,but we areinvestigatingmoresophisticatedalgorithmsthatselectthemostcost-effectivedataformatfor allcall participants.

Now we addressthe failuremodesof datapaths.Datapathsare separatedfrom control paths,except at an IAP, since thenetwork-specificgateway interactswith both the control anddatacomponentsof theaccessnetwork. Thus,thefailureof theIAP will jeopardizethedatapathaswell. However, failures(al-thoughunlikely) of Call Agents,NameMappingServers,andPreferenceRegistrieswill not affect the datapath. Failed op-eratorsandconnectorsin a datapatharerestartedby the APCservicerunningon theNinja Base.

B. Multi-deviceCall Primitivesfor EasyServiceCreation

The operationsthat carry out the basiccall serviceare theprimitivesfor additionalservices.By having multi-devicecom-municationsasthe basiccall service,we have enrichedthe setof the building blocks. The multi-device call operationsareaddinga new communicationendpointof any type to the calland removing an existing communicationendpoint from thecall. Changinga communicationendpointaddsthe new end-point, andthenremovestheexisting one. Servicesthat requireendpointchanges,suchascall forwardingandcall transfer, canbeimplementedeasilyon top of theseuser-initiated operations.For example,call forwardingcanbeimplementedby having theforwarderinvite theforwardeeendpointandthenleave thecall.

Servicehandoff is anotherexample. It occurswhen userschangetheir communicationdevices during a call. Servicehandoff enablesservicemobility, the ability to retainaccesstoservicesasusersswitchbetweennetworks. In telecommunica-tions,theterm“servicemobility” usuallymeans“serviceporta-bility”, the ability for diversenetworks to shareuserserviceprofilesand to carry out the samesetof servicesin eachnet-work [15]. However, whenonecrossesthenetwork boundaryinthemiddleof a servicesession,thatserviceis terminated.Theusermustthenrestartthe servicein the new network. In con-trast,servicemobility providesseamlessintegrationof hetero-geneousdevicesfrom diversenetworks,asif they areaccessingthesamenetwork,achieving thegoalof PotentiallyAnyNetworkService(PANS).

Servicehandoff canalsobeviewedasageneralizedcall trans-fer service. Insteadof call transferringbetweenhomogeneoustelephones,servicehandoff allows oneto performcall transferacrossdiversedevicesfrom heterogeneousnetworks.

Now imaginethefollowing servicehandoff scenario:Alice isonhercell phone.Shewalksinto herofficeanddecidesto hand-off thecall to herlaptopIP phone.Shedoesthisby first pressing

somekeys on her cellular phoneto indicatethe intent andthetargetof a servicehandoff (e.g.,“*SHIP” – ServiceHandoff toIP phone).TheservingIAP thatcontainsa cellulargateway in-terceptstheDTMF (Dual-ToneMulti-Frequency) or touch-tonemessageandrelaysit to theservingCall Agent for Alice’s cellphone.TheCall Agent looksup theendpoint information(theIP phone’s IP addressandport numberin this case)in thePref-erenceRegistrywith theinputof Alice’siUID andendpointtype(“IP”). Thenthe Call Agent invites the IP phoneto join in theconversation,as illustratedin SectionIV-A (i.e., the operationof addinga communicationendpointto a call11). Finally, Aliceturnsoff hercell phone,which informstheCall Agentthatwasservingthecell phonethatit shouldleavethecall (i.e., theoper-ationof removing anendpointfrom thecall) andcompletestheservicehandoff.

C. ICEBERGComponentsas ServiceEnablers: Our Experi-ence

C.1 UniversalIn-box

TheUniversalIn-box is a servicethatenablestheuserto re-ceive or retrieve voice mail, e-mail, phone-calls,fax, instant-messages,etc. in a unified fashion. It featuresan any-to-anycommunicationcapability betweenthe different endpoints(e-mail to fax, voice-mailto e-mail,pager-messageto phone-call,etc.).Thisapplicationwasoneof thefirstwebuilt ontopof ICE-BERGandit drovemuchof theinitial design.It exemplifiesthedeviceindependenceandpersonalizationaspectsof ICEBERG.Device nameindependenceis providedby the NameMappingService.Devicetypeindependenceis enabledby theIAP (whichdoestheprotocolconversion)andtheAPCservice(which takescareof any dataformatconversionin agenericfashion).

The PreferenceRegistry providesa cleanmodelfor the per-sonalizationfeaturesof theUniversalIn-box. We havebuilt thePreferenceManager, a graphicaltool thatallows usersto con-venientlyspecifytheir communicationhandlingpreferencesfortheUniversalIn-box.

The UniversalIn-box startedwith supportfor just two end-points:cell-phonesandvat (desktopaudiotool). We havesinceaddedsupportfor voicemail, e-mailandrecently, interfacedtoan instantmessagingsystem. The no-frills interfaceto the in-stantmessagingsystem,which is less than 300 lines of Javacode(with theappropriatecalls to theotherICEBERGcompo-nents)washalf a day’s work. Althoughwe did not have a fullyfunctionalAPC serviceduring theseadditions,we have foundaddinga new dataformatandaccessnetwork to bestraightfor-ward.Thissimplicity is dueto thecleanseparationbetweentheICEBERGcomponentswhich providesdifferentlevelsof inde-pendence.Thus,this applicationhasgivenusgoodexperiencein building servicesthatareextensibleto new endpoints.

C.2 JukeboxServiceon ICEBERGendpoints

The Jukebox service was built as part of the Ninjaproject [11], independentof ICEBERG. It plays MPEG3-encodedsongsstoredon thedisksin a clusterof workstations.

As anexercisein testingtheeaseof introducingnew servicesin ICEBERG,we have built a virtual IAP (with no actualac-cessnetwork gateways,but similar to a proxy) for theJukebox���

A datapathis not createdbetweentwo devicesof onecall party.

Page 10: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

10

servicethatmakestheservicebehaveasanICEBERGcommu-nicationendpoint.This IAP handlescalls from any ICEBERGendpointto theJukeboxserviceandmaintainsthecall statema-chineon behalfof theJukebox.Thespecialfunctionalityin thisIAP is its ability to interpretrequestsissuedto theJukeboxfromthecaller, suchasthenameor ID of thesong(this couldbeen-teredasDTMF signalsfrom the caller’s device suchasa cellphone). Thentheserequestsare translatedto regular Jukeboxservicerequestsfor theJukeboxservice.

Theeaseof introducingnew servicesis demonstratedby thefact thatbuilding thesingleIAP wassufficient to make theser-vice availableto any ICEBERGendpoint. Implementinga nofrills IAP requiredonly 500 lines of Java code,mostof whichimplementedtheproxy functionality.

TheJukeboxserviceis now availablethroughthis IAP to theendpointsin our testbed- GSM cell phonesandIP desktopau-dio applications,vat. We expectthat aswe addothertypesofendpointsto our testbed(like thePSTNphone),theservicewillbeimmediatelyaccessiblefrom thoseendpointsaswell.

D. RoomControl Service

We have implementeda complex composableservice formulti-modalcontrol of smartspacesusingseveral of the ICE-BERG accessnetworks. The end-deviceswe connectedto thesystemincludeadesktopcomputerGUI, microphoneandspeak-ers,a cell phone,anda 3ComPalm Pilot PersonalDigital As-sistant. Userscanusegraphical,text, or speaker-independentspeech-baseduserinterfacesto interactwith oneanotherandtocontroltheA/V resourcesin severalroomsin SodaHall.

The SmartSpacesControl (SSC)server usesthe AutomaticPathCreationserviceto createapathbetweenthesenderandre-cipientthatperformsany necessarytranscodings(e.g.,transcod-ing GSM-encodedaudioto PCM-encodedaudioor performingspeech-to-text recognition).Usinga controlchannelthatis par-allel to thedatachannel,we candynamicallycustomizetheop-erators(e.g., the speechrecognizerusesa constrainedn-gram,baseduponroomcontrolcommands,to improverecognitionac-curacy andspeed).

The implementationof the SSCapplicationsleveragedtheICEBERG and Ninja infrastructureand was completedwithonly 1000lines of codein only a few person-monthsof work.Extendingtheapplicationshasbeenequallyeasy. Adding sup-port for a graphicalPersonalDigital Assistant,usinga GUI in-steadof speech,requiredonly two hoursof work.

We arecurrentlyextendingthe speechrecognitionoperatorsto includemoresophisticatedoperators,suchaspauseremoval,pitch emphasisdetection,time codeextraction,andconfidenceextraction.

VI . CLEARING HOUSE: RESOURCE ALLOCATION AND

BILL ING

A. Overview

In this section,we describeour initial designof the Clear-ing House(CH), whichcoordinatestheinteractionsbetweentheICEBERG Network planeand the ISP Plane(Figure 1). Thestructureof CH is designedfor efficient provision of resourcereservationsandsecurebilling of services.In addition,theCHmustscaleoverbothdistanceandnumberof ISPsto supporttheoperationof ICEBERGin thewidearea.

To make the CH scalableto a large userbaseover a wideareanetwork, weareimplementingtheCH asahierarchicaldis-tributedsystem.Weassumethenetwork to becomposedof vari-ousbasicdomains(basedoneitheradministrativeor geographicboundaries),with minimaldomainoverlap.In ourdesign,phys-ically adjacentdomainsareaggregatedto form bigger logicaldomains. This inducesa hierarchyof logical domainsin thenetwork anda distributedCH is associatedwith eachof them.At eachlevel, multipleCH’ssharethetaskof searchingthroughtheISPspaceto constructinter-domainsubpaths,aswell asstor-ing this informationfor futureusage.Whena call betweentwoendpointsacrossthewideareais requested,a recursivecall willbe madefrom the parentlevel of the CH hierarchyfor a pathbetweena local ISPandanadjacentdomain. ThechildrenCHnodeswill performthe local searchautomaticallyto constructpathswhich spanto theboundaryof theadjacentdomain.

The implementationof the CH is still on-going,andfurtherstudiesareneededto maptheCH hierarchicaltreeandits logi-caldomainsto theexisting Internetthatspansmultipleadminis-trativedomainswithoutcleargeographicalboundaries.

B. ClearingHouseInfrastructure

Domain 1

Reservation

ClearingHouse

StatusReservation

CA

iPOP

CA

iPOP

Credit Based Reservation

ICEBERGDomain 2

3. Reservation Requests & Clustered Billing Tickets

4. Reference to Billing Statement2. Search for Optimal Path

1. Call Specifications

ContactiPOP

ISP 2 ISP 3

ISP 1

2

ICEBERG

1

4

3

3

3

Status

Fig. 3. A High-level view of theCH architectureduringcall setup.

First, we demonstratehow the CH handlesthe varioustasksby describinga typical sequenceof eventsthat take placeaftera call setuprequestarrivesat the iPOP, aslabeledsteps1-4 inFigure3:

1. iPOP passescall specificationsto the CH.WhentheiPOPreceivesa new call request,it looksup theNameMappingServiceandPAT to locatethe caller andthe callee,andobtainstheir preferredcontactpoint fromtheirrespectivePR(SectionIV-A). TheiPOPthencontactstheCH, andpassesalongthefollowing call specifications:[caller location,calleelocation,enddeviceof contact,traf-fic statistics,desiredqualityof service, misc.]

2. The CH performs an optimal path search.TheCH usesits internalcacheinformationaboutinter-ISPreservation statusandthe call specificationsto searchfortheoptimalend-to-endpacketflow paththroughISPs.Thispath is optimizedbasedon the desiredquality of service(e.g.network latency), andreservationavailability.

3. The CH sendsreservation requestsand billing ticketstoISPs.TheCH aggregatesreservationrequestsandbilling tickets

Page 11: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

11

for calls that travel throughthe sameISP. After a presettime period,the clusteredreservation requestsandbillingticketsaresentto eachof theISPsinvolvedin thepath.

4. The CH authorizesthe ISPsin the path.If sufficient resourcesarereservedalongtheoptimalpath,thecall is admitted.

Admission Control: If theCH fails to locateany links withsufficient resourcesreservedto completea chosenpath,theCHwill eitherblock thenew call, or renegotiatewith the iPOPfortheamountof requiredresourcesto carrythecall. Thedecisioninvolvessometrade-offs in theuserperceivedqualityof thecall,thecostfor increasinglyscarceresources,andtheadditionalla-tency to completethecall setup.

In the following discussions,we elaborateon how the CHprovidesresourcereservationandsecurebilling servicesto theICEBERGarchitecture.

B.1 ScalableResourceReservation

We proposea credit-basedresourcereservation scheme,ofwhich onevery importantfeatureis that the resourcereserva-tion is notperformedonaper-call basis,but ratheris aggregatedovervariousconnectionsthatusea particularlink. As shown inFigure3, resourcereservationsaresetup from ISP to ISP, in-steadof end-to-end.TheneighboringISPssendregularupdatesto theCH whichkeepstrackof the”reservationstatus”,i.e.,howmuchof theavailableresourcesarecurrentlyreservedon a par-ticular link. Thetruthfulnessof suchupdatescanbeverifiedbycompaniessuchasInverseNetwork Technology[29]. An ISPpaysanotherISPa certainamountof creditto reserveresourcesfor a presettime window, andonecanenhancethe reservationby increasingthe credit of the existing reservation, insteadofrequestinga separatereservation.

Sinceonlineresourcereservationis verycostlyandtimecon-suming, the goal of our designis to minimize the amountofper-link reservation that hasto be doneduring call setupfor aparticularcall. In Step2 above, theoptimalpathis chosensuchthat the numberof new per-link resourcereservationsis mini-mized.

B.2 Billing

Oncethe CH finds the optimal path,it returnsan authoriza-tion ticketandabilling ticket for eachISPinvolvedto theiPOP.For eachaggregatereservationrequest,theCH sendstheautho-rization ticketsin groupsto eachISP. Along with this, the CHalsoperiodicallysendstheclusteredbilling ticketsto eachISP.

The iPOPhandsthe pairsof ticketsto eachISPon the path,settingup the call in the process.EachISP authenticatestheauthorizationticket beforeallowing the call setup. After eachcall ends,its billing ticket is kept in persistentstorage.At theendof the regularbilling cycle, eachISP aggregatesits billingticketsandsendsthemto theCH for lumpsettlementpayments.

Security: WeassumethattheISPstrustthelocalCH to storetheirserviceinformation.TheCH’ssecuritystructuremustpre-ventISPsfrom forgingtheir own billing ticketsor unauthorizedcall setupmessages.We providea securesystemthatusesdigi-tal signaturesandasymmetricandsymmetricencryptionto pro-vide securitywhile maximizing performance(seefurther dis-cussionsin SectionVII). To reducetheCPUoverheadimposedontheCH by encryptionoperations,theCH aggregatesmultiple

billing ticketsfor a given ISP within a fixed time window, andprovidesadigital signaturefor theconcatenatedbilling tickets.

B.3 Discussions

The resourcereservation and billing mechanismsdescribedabovemeetthefollowing designgoals:� Scalability: Resourcereservation requestsare madefor

aggregateconnectionsinsteadof for individualusers.Nei-ther the CH nor the ISPsneedto maintainper connectionstate.Similarly, theCH clustersthecorrespondingbillingtickets for a presettime window beforesendingthem toISPs.Thisallows theCH to scalenicely.� Heterogeneity:TheCH designprovidesresourcereserva-tion andbilling mechanismsthatoperateacrossheteroge-neousaccessnetworks andservices.Sincereservation isdoneusingtime-basedcredits,servicehandoffscanbeper-formedwithout having to teardown resourcereservationson every link. This functionality supportsPANS andper-sonalmobility in ICEBERG.� Minimize Signaling Overhead and Setup Time: Theflexibility in allowing existing resourcereservationsto beenhancedgreatlyreducesthe needto setup new reserva-tions for every single link whenever a new call is made.Sincereservationsmay alreadyexist on somelinks in thesender-to-receiver path,both resourcereservationandcallsetuptimecanbereduced.Theclusteringof billing ticketsalsoreducesthe amountof CPU overheadfor encryptionoperations,andlessensthenumberof controlmessagesthatareexchanged.� Inter -operability in the Wide Ar ea: The CH’s designcan easily be extendedto work with future Internetpro-tocolsthatprovidedifferentservicelevels(e.g.,Dif ferenti-atedServiceor IntegratedServicewith RSVP).

VI I . SECURITY AND AUTHENTICATION ISSUES IN CALL

SETUP

ICEBERGis built upon the untrustedInternet,which posesprivacy andauthenticationissuesin the call setupprocess.Webriefly discusstheseissuesin this section.

Authenticating Name Mapping Service lookup: Thislookup operationis an important step in call setup. Nameserversin our architectureareakin to DNS nameservers: theyareassumedto storepublic information. This abstractionsim-plifies the authenticationrequirementfor a Name MappingServer (NMS) lookup — only the reply from the NMS needsto be authenticated,and the reply neednot be encrypted. WeusetheNameMappingServiceto bootstrapauthentication;it isusedto get thepublic key of any useror network infrastructurecomponentthatis requiredfor furthercryptographicoperations.We assumethe existenceof a PKI (Public Key Infrastructure)for authenticatingtheNameMappingServicereply.

Preventing caller spoofing: Call setup(from caller � tocallee� ) involvesthelookupof � ’sPreferenceRegistry( �� "! )by � ’sCall Agent( #$�&% ). At thisstage,�� &! hasto verify that#$�$% is a valid Call Agentof thecallerto preventboguscallers.In ourmodel, �� &' , user� ’sPreferenceRegistry, is consideredto betheauthorityof theinformationaboutthelist of valid CallAgentsfor � . This modelis flexible: �� ' canupdatethe listwhenthe usersubscribesfor the servicesof #$�&% andinforms

Page 12: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

12

�� ' aboutit (throughanout of bandchannel).�� ' canthenissuea certificateto thateffect to #$� % , which canthenbepre-sentedto �� ! for therequiredauthentication.

Enforcing calleecontrol and calleepri vacy: Thereis an-other subtle requirementin the call setupprocesswhen theoriginatingandterminatingcall agentscommunicate( #$�&%)(#$�"* ): #$�"* hasto beableto verify that #$� % hasindeedcon-tacted�� ! in therecentpast.This is to enforcecalleecontrolanddisallow callersfrom by-passingthePreferenceRegistrybe-forecalling. Ourapproachto dealwith thisis to have �� "! issueanencrypted,signedticket to #$� % . This ticket, visible only to�� ! and #$� % , is for one-timeuseonly, andhasanexpirationtimestamp.Theticket is usedby #$� * for therequiredverifica-tion. Call privacy is alsosupportedby this mechanism:�� &!canhidetheactualendpointidentity of thecalleeby encryptingthis informationin theticket.

Secure billing: To prevent tamperingof billing tickets,weneedto provideauthenticityguarantees.Thenaturalchoiceis tousepublic-privatekey encryption,wheretheCHdigitally signsabilling ticketwith its privatekey for authenticity. Usingthedigi-tal signature,aprovidercanauthenticatetheorigin of thebillingticket, and provide undeniableproof of the charged amount.However, publickey cryptographyimposesamuchhigherCPUoverheadthansymmetrickey encryption. Our designchoicesdirectly impactcall setuplatency, andrequirefurtherstudiesofthetrade-offs involved.

Encryptionfor secrecy in any of the above stepsis doneinoneof two ways: (a) by usingthe public key of the recipient,or (b) by establishinga sharedsessionkey beforeinformationexchange.Both thesemethodscould involve extra round-trips(for learningthepublickey, or for establishingthesessionkey).The latter method(establishedsessionkey) would be usedforsecrecy of the messagesexchangedduring call sessionmain-tenance.Note that the useof IP multicastmakescall sessionmanagementvulnerableto denial-of-serviceattacks.Nonethe-less,new multicastproposals,like SimpleMulticast [14], offeraccesscontrolandpreventdenial-of-serviceattacks.

The completecall setupprocesscould involve a significantamountof latency for all of the authenticationsteps. Fortu-nately, almostall of theauthenticationstepscanbeoptimizedbycachingpreviousauthenticationinformation,public key lookupinformation,or the pre-establishedsharedsessionkeys. Theseoptimizationscansave network round-trips,aswell ascrypto-graphicoperationsat theendpoints.

We arein theprocessof implementingthesesecuritymecha-nismsin our existing ICEBERGtestbed.

VI I I . IMPLEMENTATION

To gain experienceand to iterate on our design,we havebeenimplementingICEBERG componentsin a testbed. Thiscurrentlyconsistsof a GSM cellular base-station,laptopswithWaveLAN wirelessinterfaces,aH.323gateway, anda two-waypagingbase-station.We have built IAPs for interfacing withcell-phonesandIP-telephony, andarein theprocessof buildingIAPs for theH.323andpaginggateways.

In termsof the othersoftwarecomponents,we have imple-mentedour signalingprotocol in Call Agents, the PreferenceRegistry, theNameMappingService,andtheAPC service.Weareusingthe H.323gateway in our testbedto experimentwith

billing mechanisms.We arein the processof working out thenext level of detailsof our ClearingHousedesignandsecuritydesign.

TheCall Agent,PreferenceRegistry, andtheAPCserviceareimplementedasservicesin Java with an RMI interface. We’recurrentlyusingan LDAP server (from www.openldap.org) forservicelocationandtheNameMappingService.

Our implementationis asyet untunedandshows thata high-endPC (with 500Mhz Intel PentiumII processorand256MBRAM) can handle10 call initiations per second. The currenttelephoneusagemodel,accordingto [30], is a meancall arrivalrateanda meancall durationduringbusyhoursof 2.8callsperhourand2.6minutespercall respectively. Usingthismodel,wewould requireapproximately500PCsto handlethe call trafficfor a region on the scaleof theSanFranciscoBay Areawith apopulationof six million.

Our examinationof thecall processinglatenciesshows thatalarge part of the cost is dueto the Java services.RMI lookupandcalls take on the order of 10msand requiremultiple net-work round-trips. Performanceis also limited by the fact thatwe’re usinga Java implementationwith user-level threadsthatspin idly while waiting for network packets.With a largecom-munityof researchersworkingonJavaCPU,aswell as,JavaI/Operformance,we expectthatthesecostswill bereduced.

IX. CONCLUSIONS AND FUTURE WORK

In this article,we presentedtheICEBERGnetwork architec-ture: an Internet-corenetwork for integratedcommunications.Ournetwork canbeviewedasislandsof clustercomputingplat-formsthatoffer scalable,available,androbustservicesonthem.Our signalingprotocol takes the approachof lightweight ses-sionsandsoft state,enablingscalableandrobust call servicesin thewidearea.With multi-devicecommunicationasthebasiccall servicecombinedwith ICEBERGcomponentsthatmanageuserpreferences,behaviors,andcomposeunitsof computation,we provide aneasyservicecreationenvironmentfor customiz-ableservices.To addresswideareaqualityof serviceissues,weuseaClearingHouse-basedapproachthatleveragesaggregationto providescalableresourcereservationandbilling mechanisms.TheICEBERGarchitecturealsoprovidessecure,authenticatedcall setupandbilling for services.

We have a significantamountof futurework aheadof us, inparticularwehavenotyetaddressedtheproblemof Operations,AdministrationsandMaintenance(OA&M), a critical technol-ogy that is maturein moderntelecommunicationsnetworks. Inaddition,wearecontinuingourexperimentswith moresophisti-catedandnovelservicesandwearein theprocessof formulatinga well-definedservicecreationmodel. We alsoplan to addresstheincrementalwideareadeploymentof ICEBERGarchitectureandClearingHouseinfrastructureover theexisting Internet.

REFERENCES[1] ElanAmir, StevenMcCanne,andRandyH. Katz.An activeserviceframe-

work and its applicationto real-timemultimedia transcoding. In Pro-ceedingsof ACM SIGCOMM98. ACM, August1999. Vancouver, BritishColumbia.

[2] T. E. Andersonandetal. TheCasefor NOW (Network of Work Stations).In IEEE Micro, feb 1995.

[3] N. Anerousisandet. al. Tops: An architecturefor telephony over packetnetworks. IEEEJournal of SelectedAreasin Communications, jan1999.

[4] W. Biemolt, M. Kaat, andH. Steenman.A Guideto the IntroductionofIPv6 in theIPv4World. InternetEngineeringTaskForce,April 1999.

Page 13: ICEBERG: An Internet-core Network Architecture for Integrated … · 2004. 7. 18. · We designed ICEBERG, an Internet-corenetwork architec-ture for integrated communications, to

13

[5] Ljubica Blazevic andJean-YvesLe Boudec. DistributedCoreMulticast(DCM):+ a multicastroutingprotocolfor many groupswith few receivers.In NGC, Pisa,Italy, nov 1999.

[6] D. D. Clark. Thedesignphilosophyof theDARPA Internetprotocols,.[7] Steve Deering. Host Extensionsfor IP Multicasting, Aug 1989. IETF

RFC-1112.[8] B. Stiller et al. Charging andaccountingtechnologyfor the internet. In

MultimediaApplications,Services,andTechniques, May 1999.[9] Guido Appenzelleret al. The Mobile PeopleArchitecture. In Technical

Reportof Stanford ComputerScienceLabCSL-TR-99-777, January1999.[10] N. Duffield et al. A flexible model for resourcemanagementin virtual

privatenetworks. In ACM SIGCOMM, September1999.[11] StevenD. Gribbleet al. TheMultiSpace:anevolutionaryplatformfor in-

frastructuralservices.In UsenixAnnualTechnicalConference, June1999.Monterey, CA.

[12] C. Gbaguidiet.al. An Architecturefor the Integration of InternetandTelecommunicationServices. In IEEE Infocom’99, New York, March1999.IEEE.

[13] Jean-PierreHubauxet.al.Theimpactof theinternetontelecommunicationarchitectures.In TheInternationalJournal of ComputerandTelecommu-nicationNetworking, 1999.

[14] R. Perlmanet.al. SimpleMulticast: A Designfor Simple, Low-OverheadMulticast. InternetEngineeringTaskForce,December1998.

[15] NadegeFaggionandCegetelThierry Hua. Personalcommunicationsser-vicesthroughtheevolution of fixedandmobile communicationsandtheintelligentnetwork concept.IEEE Network, Jul/Aug1998.

[16] A. Fox andet al. Scalablenetwork services.In Proceedingsof the16thACM Symposiumon Operating SystemsPrinciples(SOSP-16), St. Malo,France,oct 1997.

[17] M. GunterandT. Braun. Evaluationof bandwidthbroker signaling. InIEEE Seventh International Conferenceon Network Protocols (ICNP),October1999.

[18] M. Handley. SessionDirectory andScalableInternetMulticast AddressAllocation. In Proceedingsof ACM SIGCOMM, sep1998.

[19] HughW. HolbrookandDavid R. Cheriton. IP Multicast Channels:EX-PRESSSupportfor Large-ScaleSingle-SourceApplications.In Proceed-ingsof ACM SIGCOMM, sep1999.

[20] http://info.ox.ac.uk/fax/. Email to Faxat Oxford University.[21] http://ninja.cs.berkeley.edu/. TheNinja Project.[22] http://planetarymotion.com/. PlanetaryMotion’s CoolMail Service.[23] http://www.databeam.com/h323/h323primer.html. A Primer on theH.323

SeriesStandard.[24] http://www.fax away.com/. Faxaway:ThePremierEmail to FaxService.[25] http://www.internet2.edu/qos/qbone/. Internet2 QoS Working Group:

Qbonetestbed.[26] http://www.thinklink.com/.ThinkLink.[27] http://www.wildfire.com/.Wildfire.[28] Yang hua Chu, Sanjay Rao, and Hui Zhang. EndSystemMulticast.

http://www.cs.cmu.edu/kunwadee/research/other/endsystem-index.html.[29] Inversenetwork technology. http://www.inverse.net/.[30] C. N. Lo, R. S. Wolff, and R. C. Bernhardt. An estimateof network

databasetransactionvolume to supportuniversal personalcommunica-tions services. In First InternationalConferenceon Universal PersonalCommunications(ICUPC ’92), 92.

[31] Colin Low. Theinternettelephony redherring. In Proceedingsof GlobalInternet, November1996.London,England.

[32] MaryannP. MaherandColin Perkins. SessionAnnouncementProtocol:Version2, nov 1998.IETF InternetDraft: draft-ietf-mmusic-sap-v2-00.txt.

[33] StevenMcCanne.Scalablemultimediacommunicationwith internetmul-ticast, light-weight sessions,andthe mbone. TechnicalReportCSD-98-1002,ComputerScienceDivision,U.C.Berkeley, july 1998.

[34] British Columbia Institute of Technology. CA*net II DifferentiatedServices: Bandwidth Broker High Level Design, November 1998.http://www.merit.edu/working.groups/i2-qbone-bb/.

[35] MemaRoussopoulosandet al. Personal-level routing in themobilepeo-ple architecture. In Proceedingsof the USENIXSymposiumon InternetTechnologiesandSystems, oct 1999.

[36] H. SchulzrinneandJ. Rosenberg. A comparisonof sip andh.323for in-ternettelephony. In Networkand Operating SystemSupportfor DigitalAudioandVideo(NOSSDAV), July 1998.

[37] HenningSchulzrinne.A comprehensive multimediacontrol architecturefor the Internet. In Proceedingsof InternationalWorkshopon NetworkandOperatingSystemSupportfor Digital AudioandVideo, May 1997.

[38] J. G. Steiner, C. Neuman,andJ. I. Schiller. Kerberos:anauthenticationservicefor opennetwork systems.In USENIXAssociationWinter Confer-ence, Dallas,TX, 1988.

[39] HelenJ.Wang,Anthony D. Joseph,andRandyH. Katz. A signalingsys-temusinglightweightcall sessions.In Proceedingsof IEEE INFOCOM,Tel-Aviv, Israel,March2000.

[40] MohammedZaid. Personalmobility in PCS.IEEEPersonalCommunica-tions, FourthQuarter1994.


Iceberg lettuce

Iceberg Casero

Iceberg Asombrosos

Revisat iceberg núm 42

Palestra-Operação Iceberg

Architec Line

Iceberg - Xlibros- LIBRERÍA DIGITAL GRATIS · ICEBERG Clive Cussler Prólogo

Our Iceberg is Melting

OPERAÇÃO ICEBERG

Punta Del Iceberg

Chapo Iceberg

Ola O Iceberg

Revista Iceberg nº37

tornado iceberg

Nuestro Iceberg Se Derrite

Fem un iceberg

Iceberg organizacional

Iceberg a la_vista[1]

Tipologia iceberg

La Punta Del Iceberg

Iceberg Consulting Linkedin Profile

Revista Iceberg núm. 45

Modelo del Iceberg

A ponta do Iceberg

: Iceberg - nuitdelalecture.culture.gouv.fr

Revista Iceberg núm. 43

SUNLESS ICEBERG NOUMATROUFF 2

ICEBERG, O MANIFESTO

DevOps Iceberg agileindiaconf2016

Revista Iceberg núm. 44

Iceberg 21

ICEBERG - IndelB IndelB... · El Iceberg 40 está disponible en versión autoportante con mueble de madera (Iceberg 40 MB). Minibar com Móvel O minibar iceberg 40 está também disponível,

T Iceberg

Revista Iceberg núm 34

ﻥﺁ ﻱﺭﺎﺠﺗ ﻡﺎﻗﺭﺍ ﻲﻓﺮﻌﻣ ﻭ Iceberg) …Iceberg) گﺮﺒﺴﻳﺁ ﭗﻴﺗ ﻱﻮﻫﺎﻛ ﺪﻴﻟﻮﺗ ﻥﺁ ﺕﺍﺯﺍﻮﻣ ﻪﺑ ﺎﻣﺍ