No Slide Title

Download Report

Transcript No Slide Title

Real Time GENI
Workshop Report Preview
(Unofficial)
April 4, 2006
Ashok Agrawala & Lui Sha
1
Introduction
Motivation - 1


Internet technology has become pervasive as an enabling
technology for enterprise systems but (though used for
distributed real-time applications) has not penetrated real-time
sensing and control networks
The Internet is not quick to assimilate/enable new technologies:
 Wireless (e.g., Bluetooth, interference)
 Software-defined-radio, ad hoc networking
 RFID, Teleoperation, …
2
Introduction
Motivation - 2



Critical Infrastructures currently are managed “at risk” over the
Internet, on commodity platforms
Critical Infrastructure Protection concerns: interdependent
technologies (electricity, oil and gas, telecom, water,…)
 Cyber vulnerabilities
 Physical vulnerabilities
Future networked systems challenges and ambitions: health
care/medicine, power grid/energy systems, transportation,
manufacturing, …
 Future systems are envisioned in other disciplines
 Will the Internet enable, impair, prevent?
3
Introduction
Motivation – Sample Application


Current picture in power networks:

Equipment protection devices trip locally,
reactively

Cascading failure: August (US/Canada) and
October (Europe), 2003
Better future?

Real-time cooperative control of protection
devices

Or -- self-healing -- (re-)aggregate islands of
stable bulk power (protection, market motives)

Issue: standard operational control concerns
exhibit wide-area characteristics (bulk power
stability and quality, flow control, fault isolation)

Technology vectors: FACTS, PMUs

Context: market (timing?) behavior, power
routing transactions, regulation
IT Layer
4
Analysis of Challenges
Application Scenarios



Medical and Health

Scalable, reliable and secured RT architecture for pervasive health
monitoring at home, hospital, emergency, battlefield.

Reliable Real time closed loop therapeutic support for tele-surgery
& and anesthesia
Security and Defense

Large scale emergency response systems

Integrated border protection, FBI and police systems

Network centric surveillance & cooperative engagements across
space, air, land, sea, underground and underwater
Productivity enhancement and environmental protection

Large scale pollution, climate, and habitat monitoring

Distributed power and telecomm grids monitoring and control

Intelligent transportation including free flights

Integrated finance, production, logistic, and sales

Common standard replacing existing domain specific standards
5
Analysis of Challenges: Common Requirements
Top Level Requirements




Time and physical location are 1st class objects
 Globally consistent representation
 Resolution (technology dependent)
Timing Predictability: All composition & virtualization must provide
 Bounded delay, jitter, and loss
 Precise conditions under which the bounds hold, including
space networks with dynamic topology
Security and Robustness
 Automatic fault isolation
 Strong authentication: no spoofing
 Automatic trace, diagnostic and report
Consistent handling of QoS concerns at core, edge and wireless
networks
6
Analysis of Challenges: Common Requirements
Integration & Composability

Built-in support at middleware level:
 Time and event triggers
 Consistent views of distributed states in real time (resolution
technology dependent)
 Topology control and “dynamic RT coalitions” in the form of
packaged service classes of bounded delay, jitter and loss
under precisely specified conditions
 Interface: Access to the same type of controls regardless of
the underlying network technology
 Instrumentation for evidence based certification
 A coherent system composed of heterogeneous networks
7
Analysis of Challenges:
Community Specific Requirements

Medical and Health
 Scalable, reliable and secured RT architecture for pervasive
health monitoring at home, hospital, emergency, battlefield:
requires QoS controlled VPN across a wide range of public
and private networks.


Reliable Real time closed loop therapeutic support for telesurgery & and anesthesia: Requires secured, reliable and
delay and jitter sensitive circuits down to sub – millisecond
level.
FDA certification for components and systems. Instrumentation,
evidence collection and innovative certification process.
8
Analysis of Challenges:
Community Specific Requirements




Security and Defense
 Large scale emergency response systems
 Integrated border protection, FBI and police systems
 Network centric surveillance & cooperative engagements
across space, air, land, sea, underground and underwater.
Require strong and composable multi-level security and
survivability against sabotage and attacks
Require QoS controlled composability across a wide range of
network technologies
Require topological control and controlled preemption of normal
applications under emergency
9
Analysis of Challenges:
Community Specific Requirements



Productivity enhancement and environmental protection
 Large scale pollution, climate, and habitat monitoring
 Distributed power and telecomm grids monitoring and
control
 Intelligent transportation including free flights
 Integrated finance, production, logistic, and sales
Extensible common standard replacing existing domain specific
standards
Safety critical applications require strong isolation from other
applications, well formed dependency for interactions between
safety and non-safety applications, and support for certification
10
Analysis of Challenges
Research Agenda – High Level Questions - 1


How can we characterize the QoS requirements of:

Loosely coupled wide area system of systems such as power
generation, distribution and control as well as network
centric collaborative engagement?

Tightly coupled local systems such as automobile, avionics,
manufacturing plants and chemical process control?

Newly emerging high reliability and delay sensitive wireless
based systems such as operating rooms of the future?
For each class, what are the MINIMAL and LOWEST COST QOS
supports that GENI (the underlying networking infrastructure)
must support so that your [Avionics/power/auto/space/medical]
community would consider abandoning your domain specific
standard?
11
Analysis of Challenges
Research Agenda – High Level Questions - 2



How can we abstract diverse QoS requirements and construct a set of
QoS mechanisms and put them at the appropriate layers within a
coherent framework? What will be the structures of the control (setup
and reconfigurations guarantees) and data paths (bandwidth, delay,
and jitter guarantees) in a variety of core and peripheral networks
including wireless network with high mobility?
What kind of experimentation facility do you need to demonstrate
underlying mechanisms and applications at scale? How would you
design a "shared" facility for the community as opposed to dedicated
facility for each group to do experimentation on?
How would you promote collaborations among different communities
to create the best framework or architectures for real time networked
embedded systems?
12
Analysis of Challenges
Constraints and Tradeoffs - 1


Physical media dependent QoS constraints: fibers, coppers, and
different wireless technologies put limitations on realizable
timing & reliability
Regulatory constraints: safety critical applications such as flight,
nuclear, medical applications must be certified. It requires
evidence based demonstration of
 Strong isolation between applications with different criticality
levels in storage, in data transmission, in execution of
application code & system calls
 Mechanisms to support well formed dependencies when
application with different criticality level interacts
13
Analysis of Challenges
Constraints and Tradeoffs - 2

Need verifiable and quantifiable mechanisms to support slicing
and isolation at different levels of abstraction in network and
middleware services
 Efficiency & efficacy for slicing & isolation at different levels
of abstraction
 Verifiable QoS properties for slices and their composition of
resources.
 Tradeoff analysis of different compositions in terms of
efficiency and QoS loss
14
Analysis of Challenges
Research Agenda – Top Level Requirements



Globally consistent representation of time and physical location
as 1st class objects across core, edge and mobile networks
Predictable and verifiable composition & virtualization in terms
of bounded delay, jitter, and loss
Basic supports for security and robustness
 Automatic fault isolation,
 Strong authentication: no spoofing
 Automatic trace, diagnostic and report
15
Analysis of Challenges
Research Agenda – System Integration Support

Built-in support at middleware level:
 Time and event triggers
 Consistent views of distributed states in real time (resolution
technology dependent)
 Topology control and “dynamic RT coalitions” in the form of
packaged service classes of bounded delay, jitter and loss
under precisely specified conditions
 Interface: Access to the same type of controls regardless of
the underlying network technology
 Instrumentation for evidence based certification
 A coherent system composed of heterogeneous networks
16
Analysis of Challenges
Research Agenda – Primitives

Verifiable and quantifiable mechanisms to support slicing and
isolation at different levels of abstraction in network and
middleware services
 Slicing & isolation control at different levels of abstraction
 Admission and queueing control at entry and intersection
points.
 Strong isolation between service classes
 Well-formed dependencies for the interactions between
service classes with different criticality
17
Analysis of Challenges
Research Agenda – Composition



Deliver provable compositional QoS properties to
applications that will ease their assurance and
certification
Quantize diverse application QoS requirements into small
number of topologically controlled QoS service classes
composed by primitives
Serve as an integration framework for synchronous, safe,
secure, real time systems, replacing one of kind
networks such as those in avionics, auto and medical
devices
18
Experimental Facility - Requirements


Shared and managed open facilities
 Open source software
 System designs publicly reviewed before commit
 Co-existence of guaranteed, managed and best effort QoS
Control over infrastructure to make experiments repeatable
 Slicing and isolation control at different levels of abstractions
 Workload insertion, fault injection and security breach
mechanisms
 Non-interfering instrumentation and automated data
collection and computer aided analysis
19
Process and Organization
Timeline



Now
 key requirements for the baseline core infrastructure
 A compelling research agenda for realizing real time
networked embedded systems
Next 2+ years
 Example network architectures and components for
networked embedded systems
 Lead to more requirements for the baseline facility
 The baseline facility becomes available for experimentation
Next 2-10 years
 The architectures and components will be deployed on the
baseline infrastructure for experimentation and evaluation
20
Process and Organization
Research Groups




Baseline GENI facility providers
 Provide baseline GENI infrastructure with appropriate hooks
Real time network architects
 Provide real time networks and components on baseline facility
Real time application providers
 Build example applications
End users
 Use applications for their benefit and in the process test
21
Process and Organization
Inter-Group Requirement Management



What requirements you want to place on baseline GENI facility so
real time network architects can explore various options?
It is a balancing act
 If we put lot of requirements on the baseline infrastructure,
there will not be much for the real time network architects to do
 If not enough, real time network architects will not be able to
deliver key capabilities
Important to split requirements into two coherent parts, otherwise
 Random subset will make it into the baseline infrastructure
 Different communities will step on each others’ toes
22
Process and Organization
Example Baseline Requirements



Access to (a slice of) physical hardware within routers and
switches with dedicated bandwidth
 No virtualization or virtualization with acceptable
deterministic minimum delay
Ability to program the physical hardware
Access to global time with certain accuracy
23
Process and Organization
Example RT Network Architecture
On the baseline infrastructure

one team of real time network architects deliver a network that
provides guaranteed, managed, and best-effort QoS

One team provides real time networks with support for
 Guaranteed QoS
 Composability
 Support for time triggered and event triggered applications
 Topology control and “dynamic RT coalitions”
 Evidence based certification

One team focuses on providing
 Built-in support for composition and certification: assurance
and certification need a compositional systems view
24