SHARP: An Architecture for Secure Resource Peering∗Yun Fu†, Jeffrey Chase†, Brent Chun‡, Stephen Schwab§, and Amin Vahdat†ABSTRACTThis paper presents Sharp, a framework for secure dis-tributed resource management in an Internet-scale comput-ing infrastructure. The cornerstone of Sharp is a constructto represent cryptographically protected resource claims—promises or rights to control resources for designated timeintervals—together with secure mechanisms to subdivide anddelegate claims across a network of resource managers. Thesemechanisms enable flexible resource peering: sites may tradetheir resources with peering partners or contribute them toa federation according to local policies. A separation ofclaims into tickets and leases allows coordinated resourcemanagement across the system while preserving site auton-omy and local control over resources. Sharp also introducesmechanisms for controlled, accountable oversubscription ofresource claims as a fundamental tool for dependable, ef-ficient resource management. We present experimental re-sults from a Sharp prototype for PlanetLab, and illustrateits use with a decentralized barter economy for global Plan-etLab resources. The results demonstrate the power andpracticality of the architecture, and the effectiveness of over-subscription for protecting resource availability in the pres-ence of failures.Categories and Subject DescriptorsC.2.4 [Computer-Communication Networks]: DistributedSystems; D.4.6 [Operating Systems]: Security and Pro-tection; H.4.3 [Information Systems Applications]: Com-munications Applications∗This research is supported in part by the National Sci-ence Foundation (EIA-99772879 and ITR-0082912), HewlettPackard, IBM, and Intel. Vahdat is also supported by anNSF CAREER award (CCR-9984328).†Department of Computer Science, Duke University,{fu,chase,vahdat}@cs.duke.edu.‡Intel Research Berkeley, [email protected].§Network Associates Laboratories, [email protected] to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SOSP’03, October 19–22, 2003, Bolton Landing, New York, USA.Copyright 2003 ACM 1-58113-757-5/03/0010 ...$5.00. 0 10 20 30 40 50 60 70 80 90 12 13 14 15 16 17 18 19 20 21 22 23 24 25% of available nodesMarch dateNodes at full cpu utilization50% - 100% cpu utilization25% - 50% cpu utilizationFigure 1: Demand for PlanetLab production nodesleading up to the SOSP paper submission deadline(March 24, 2003). The heavy, bursty demand madeit difficult for authors to find resources or obtainstable results. Other resources (e.g., network band-width) showed similar impacts.General TermsExperimentation, Management, Performance, SecurityKeywordsResource Allocation, Resource Peering, Peer-to-peer1. INTRODUCTIONSeveral research threads are converging toward federatedsharing of dispersed pools of networked computing resourcesunder coordinated control. Examples include Internet ser-vice utilities (e.g., Content Services Networks), computa-tional network overlays such as PlanetLab [36] and Netbed [48],peer-to-peer services, and grid computing systems, whichharness federated computing resources for massive compu-tational problems and network services [23]. All of these sys-tems are built above rapidly maturing support for location-independent service naming and instantiation.These systems need effective resource management for fairsharing of community resources, performance isolation andpredictability, and adaptivity to changing conditions. Asone motivating example, Figure 1 shows a classic “tragedyof the commons” for PlanetLab during a period of high de-mand. Here, a growing number of PlanetLab users simul-taneously request “slices” of resources from arbitrarily se-lected nodes to host distributed systems experiments. Inthis system, the PlanetLab nodes schedule their requests lo-cally, with no mechanism to discover or reserve resources,coordinate resource usage across the system, or control re-source usage by users or groups. Users have little basis topredict the resources available to them at each site, creatingan incentive to request more resources than needed. Userswho obtain poor results due to overloading at one or moresites either retry their experiments—consuming even moreresources—or give up. The scenario is similar to congestioncollapse in the Internet.This paper proposes a new approach to flexible resourcemanagement for wide-area networked systems such as Plan-etLab. Consider a collection of logical sites or domains, eachrunning local schedulers for physical resources (e.g., proces-sors, memory, storage, network links, sensors) under its con-trol. A site may be as small as a single computer, or it couldbe a large group of resources under common ownership, anal-ogous to an autonomous system. While the resources withineach site may be highly dynamic, we assume that the sitesthemselves are reasonably long-lived and static. The ac-tors in the system are software programs operating on be-half of users and organizations, which export local resourcesand consume global resources. The goal of our work is todevelop fundamental abstractions and mechanisms to allo-cate resources across the system in a coordinated way, underthe direction of pluggable policies for discovering resources,matching requests to available resources, and assigning pri-ority or control over resources.A system for flexible policy-based resource managementmust meet several basic goals. It must allow actors to reserveresources across the system for predictable behavior, and itmust prevent actors from stealing resources held by others.It must support admission control, so that users have an op-portunity to abort or redirect resource requests that cannotbe met in full, without consuming resources unnecessarily.It must balance global resource sharing with local auton-omy, leaving sites ultimate control over their resources andthe flexibility to adjust use of those resources to respond tolocal conditions. The system must be robust: in particular,it must protect resource availability if a resource holder failsor becomes unreachable. Finally, it must be secure:
View Full Document
Unlocking...