Embed Size (px)
Citation preview
Contents
• Contents
• Wireless Subnets
• User Service
– Operator Portal
– Researcher Portal
– Common Sub-Services
– Instrumentation & Data Repository
• Conclusion
Wireless Subnets
Programmable Edge Node (PEN)
• Connect to GENI backbone and wireless subnets
• Wireless subnets includes PWN sets, client devices
• Consists of commodity processors and Network cards
• Mux / Demux between backbone circuit and PWNs
• Support Socket, Virtual Link, Virtual Radio Interface
Programmable Wireless Node (PWN)
• Includes Radio-cards, Commercial-transceiver (WiFi, Cellular), etc.
• Number of radio technologies, high-bandwidth, CR is possible
• Support Virtual Radio Interface
• Data channel support experiment of GENI
• Control channel support to retrieve experimental statistics
Subnet Deployments
• Each subnets is treated as a distinct aggregate
• Aggregate Manager is connected to the constituent components through control channel
• Aggregate Manager implements O&M Control and Slice Coordination functionality
• Aggregate monitors compatible frequency allocation, power, and so on
• RF sniffers measure ambient RF spectra
802.11 Urban Mesh Network
• Lower-cost solutions with large-scale system in high-density urban
• Provides access to GENI experiments and services from moving vehicles and other mobile devices
• End user mobile device can be opt into GENI urban mesh
• ~1000 PWNs ,
• ~10 Sq-Km,
• ~ 8m height,
• ~100 vehicle
mobile nodes
(bus, taxi)
Suburban Cellular / WiMax-WiFi Hybrid
Network
• 10 Cellular,
• 100 802.11
based nodes,
• 50 Sq-Km
• 20~50 mobile
nodes
• Important to Future Internet scenario – Integration with cellular network and internet• Research Issues : cellular transport-layer, future internet mobility, 3G/WLANhandover, multicasting and broadcasting, 4G security, information caching delivery, location aware service• Experiment - Cellular and WiMax/Wibro network architecture, hybrid WiFi/WiMax and hybrid WiFi/Cellular networks
Cognitive Radio Access Network
• Building adaptive, spectrum-efficient systems• Research Issues : radio spectrum architectures, hardware platform (SDR) integration, cognitive networking adaptation algorithms, mobile / wireless network control and management functions, developing new protocols supporting new network services
Application-Specific Sensor Subnets
• 100 for local
sensor net
• 1000 for out
door
• Sensor deployment kit – network proxy from sensor radio to 802.11 or Cellular• Platform software related with Sensor module for user• Research Issue - general-purpose sensor network protocol stacks, data aggregation, power efficiency, scaling and hierarchies, information processing, platform hardware / software optimization, real-time, closed-loop sensor control applications, vehicular, smart space, etc.
Emulation Grids
• Large scale, wild environment
• Experiments run in controlled, repeatable way
• GENI wireless simulation cluster– Provide a means by which wireless network simulations may be l
inked into the end-to-end GENI system
• GENI controlled experimental facility– Consist of RF-shielded, anechoic rooms in which repeatable exp
eriments can be performed with radio signals
Discussion about chapter 3
• Programmable Edge Clusters(PEC)
• Programmable Core Nodes(PCN)
• Programmable Edge Nodes(PEN)
• Programmable Wireless Nodes(PWN)
• Common design : Constructed from general purpose processor running virtualization software
• Distinctions : Specialized for a particular purpose
User Services
�Goal• Support experiments running in GENI
– Means to create, manage, and harvest scientific measurement
• Make GENI usable– Lowering the barrier-to-entry for researchers
• Two main user populations– Operators and researchers
�Terminology• Portal
– Interface to the services tailored for a given user community
User Services
Operator Portal
• GENI must provide a stable and reliable platform– Problems must be detected and resolved quickly
• GENI operations must be automated– Able to detect and resolve most problems with minimal human in
tervention
• Operator Portal want to give a convenient interface– GENI operations staff can use it to manage GENI
• Online functions– Direct interact with components, FCAPS (by ITU)
• Offline functions– Used to manage less critical tasks
Fault Management
• Detects problems with GENI hardware and software
• Perform root-cause analysis– Monitoring Service : Collect data about the health
– Topology information : Understanding the relationship between components.
– Fault management rule : Mapping between an observed set of faults with the root-cause problem. By codifying these behaviors as rules, it is possible to accurately identify problems
• Restarting failed software repairs most failures
• However, some problems need human intervention
• Example : NAGIOS open source network and system monitoring application, HP OpenView, Micromuse NETCool
Configuration Management
Accounting Management• Configuration Management
– Facilitate introduction of new nodes, links, sensors into GENI
– Track hardware location, software versions, etc.
– Component registry
– Provision, configure, validate new components
– Example : PlanetLab management authority, Telcordia Granite Inventory Manager, Amdocs Cramer Inventory, MetaSolv Inventory Management Software
• Accounting Management– Map GENI users to real people and institutions
– Only authorized users can consume GENI resources
– Hierarchically managed
– Example : Accounting management tools used in PlanetLab and Emulab, Grid Account Management Architecture(San Diego Supercomputer Center)
Performance Management
Security Management• Performance Management
– Monitor resource
– Misbehaving slice need to be suspended automatically
– Example : Same as FMS+ CoMon system in PlanetLab
• Security Management– Logging security-related events so that Staff can figure out
– Bad behavior should be detected and stopped quickly
– Sometimes, violation is the result of buggy experiment-> Report to the researchers
– Intrusion detection system, policy-based network management, logging and auditing mechanism
– Operations staff notification mechanism is used
Offline Management Functions
• User Question– “Why is this traffic affecting my experiment?”
• GENI staff use Problem tracking system– Tracking GENI bugs, user questions, maintenance request, and
other problems
• Tracking problems be readily applied to GENI– Lots of existing tools such as Best Practical Solutions LLP Requ
est Tracker, Bugzilla, IBM/Rational ClearQuest tool
• Offline tools allow researchers to exchange “best practices”, shared code, and discuss experiments– To facilitate collaboration, cooperation, communication
– Report, upgrade, meeting between staffs and users
– Wiki, website, email, forum between users
Researcher Portal
• Allow researcher and developer to acquire GENI resources
• Give ability for researcher to create and steer their experiment
• Must be easy to use and comprehensive
• Front-end to a set of services
• Resource Allocation– How components resources are shared among experiments
• Slice Embedding– Governs the process of instantiating a researcher’s slice
• Experimenter Workbench– Tools to create, configure, and control their experiment
Resource Allocation
� Two modes• Best-effort mode
– Ensure high-level of resource utilization
– Reduce the barrier-to-entry
• Resource guarantee mode
� Brokerage Service• Under the control of GENI itself
• User present tokens and requirements to Resource Brokers
• Broker grant tickets for specific resource
• That is, Brokerage Service binds a token to concrete resources by converting it into a ticket that can be sued to acquire specific resources
• Organization offer resource to Resource Broker(RB), and RB return tokens, and then organization can subdivide tokes among its users
Slice Embedding
• Find a collection of system-wide GENI resources that match some criteria
• Three steps– Resource discovery : monitoring sensors
– Query processing : matching with requests and resources
– Slice-wide resource allocation : assign resources
• Constraint– Fully decentralized solution : increase complexity
– Inter-node : latency, bandwidth are hard to realize (NPC)
– Resource allocation from heterogeneous subnet
• Approach– Embedding interface
– Embedding service operate• Policy enforcement
• Slice stitching : break a request into different pieces and request the most difficult things and then extend the result by iteratively contacting other aggregates
Experimenter Workbench
• Tools to create, configure, and control their experiment
• Desired attributes of experiment management toolkit– Support gradual refinement
– Flexible programming environment
– Sophisticated fault handling
– Instrumentation, data collection and archiving
– Multi-experiment workflow
• Overall design for experiment support– Develop and implement an API
– Scripting language
– Parallel process management in asynchronous mode
– Simple forms of node selection
– Synchronization
– Permanent Service
– Interface the experiment support toolkit
– Fault-tolerant execution
– Monitoring abnormal behavior
– Address scalability issue
– Address network reliability issue
Common Sub-Services
• Contribute to making GENI easy to use
• Communication Services
• Storage Services
• Legacy Internet Services
Communication Services
• Bulk transfer service– Break large files into chunks
– Distribute those chunks to client machines
– Scalable : using caching and parallel transfer
– Easily Overloaded by too many client request
– Coblitz, Bullet, SplitStream
• Event dissemination service– Efficiently deliver small message to a widely distributed set of consumer
machines
– Leverage multicast tree
– Scalable
– Corona
• Information plane– Provide topology, failure, load information
– Aggregate this data and publish the result
– ScriptRoute, PlanetSeer, iPlane
Storage Services
• Experimenter need– Local storage, convenient remote access, high-performance
• Management require– Reliable storage, resource use accounting, tracking
• Three storage service Interface– Direct access, Access through database, Convenient remote
access
• GENI provide both local file system and SQL DB
• Convenient mechanism for Remote access– File- system-like access
• GENI provide Best-effort storage– Threat of disk failure
– GENI allocate disk storage to a service for a long time period with the promise not to reclaim that storage
Legacy Internet Services
• Foster the use of experimental service by end users
• Connecting the GENI to commodity Internet
• Want to make it easy for legacy applications on GENI
• Compatibility framework– Easily extent the function of existing service
– Lower development cost and barrier of acceptance
• Build as part of GENI– Virtualized BGP : multiple experimental architecture coexist
– Virtualized Data Plane : fast packet processing
– Virtualized HTTP : HTTP compatible interface
– Virtualized DNS : redefine DNS (Experiments on PlanetLab)
– Distributed Dynamic NAT : manipulate return packet
Client Devices / Opt-In
• Wide range of client service can participate in GENI– PC, PDAs, laptops, cell phones, sensors, etc.
• Integrated into GENI in four ways– Be full-fledged GENI component
– Decouple the Component Manager and the device
– Unmanaged GENI component
– Completely independent of GENI
• User can opt into a GENI in three way– Existing application can be directly configured to forward traffic
through a GENI slice
– Host operating system can run a generic proxy
– Native GENI
• Researcher have to program their slices to handle this traffic
Instrumentation & Data Repository
• GENI’s essential mission– Being able to collect, archive, and analyze measurements of
experimental service
– GENI Instrumentation Measurement System (GIMS)
• Requirements– Ubiquitous deployment, No impact on experiments, Extensibility,
Large capacity, High availability, Large capacity, Ability to measure detailed activity with high accuracy, Ability to specifyrequired measurements, Access control, Security, etc.
• Approach– Resource centric approach
– GIMS Specification • Instrumentation, Measurement synthesis, Analysis and archiving
• Tradeoffs– Special vs. General purpose measurement hardware
Instrumentation
• Link sensors– Deployed on all of the physical links
– Light or Electrical signal
• Node sensors– Deployed on all nodes interconnected by links in GENI
– Provide basic utilization, state and configuration information
– Example : /proc file system – real time measurement
• Time sensors– Deployed on all GENI node locations
– Network Time Protocol (mili-seconds)
– GPS (micro-seconds, require antenna)
– CDMA-based GPS
• Other issues– No specific data buffering or storage requirement for sensors
Data Synthesis
• Collect and synthesize the signals provided by sensors into meaningful data
• This system must be physically connected to sensors
• Frame and capture packets are important features
• Examples of collection / synthesis system– tcpdump utility
– Endace DAG daughter card
• Data gathering protocol is required– SNMP, Simple Common Sensor Interface for PlanetLab
Data Archive and Analysis
• Archival repository into which measurements from the collection systems are stored and then made available for analysis
• Provide a reliable repository
• Give a standard interface
• Repository itself sub-system– Distributed, resilient to site-specific failure primary sub-system
– AT&T’s Dayton : SQL-like interface
• Data catalog sub-system– Data index for all data in the archive
– Index enables user to find data
– Foundation for developing visualization and analysis tools
Conclusion
• GENI is an experimental facility intended to
enable fundamental innovations in networking
and distributed systems
• GENI is an open, large-scale, realistic
experimental facility that will revolutionize
research in global communication networks.
• Emerging technologies are issue!
