NetQoPE: A Middleware-based Netowork QoS Provisioning Engine for Distributed Real-time and Embedded Systems Jaiganesh Balasubramanian jai@dre.vanderbilt.edu.

Post on 20-Jan-2016

220 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

Transcript

NetQoPE: A Middleware-based NetQoPE: A Middleware-based Netowork QoS Provisioning Engine for Netowork QoS Provisioning Engine for Distributed Real-time and Embedded Distributed Real-time and Embedded

SystemsSystemsJaiganesh Balasubramanian

jai@dre.vanderbilt.eduWork done in collaboration with

Sumant Tambe, Aniruddha Gokhale & Doug Schmidt (Vanderbilt)

Srirang Gadgil, Frederic Porter & Dasarathy Balakrishnan (Telcordia)

ISIS, Dept. of EECS Vanderbilt University Nashville, Tennessee

May 3, 2007CS WithIt Seminar

www.dre.vanderbilt.eduwww.dre.vanderbilt.edu

2

Distributed Real-time & Embedded (DRE) Systems

• Network-centric and large-scale “systems of systems”– e.g., industrial automation, emergency

response• Satisfying tradeoffs between multiple (often

conflicting) QoS demands– e.g., secure, real-time, reliable, etc.

• Regulating & adapting to (dis)continuous changes in runtime environments• e.g., online prognostics, dependable upgrades,

keep mission critical tasks operational, dynamic resource mgmt

DRE systems developed via robust and reliable system composition and integration of services and applications

3

Variability in the solution space (systems integrator role)

•Diversity in platforms, languages, protocols & tool environments

•Enormous accidental & inherent complexities

•Continuous evolution & change

Challenges in Realizing DRE Systems

Variability in the problem space (domain expert role)

•Functional diversity•Composition, deployment and configuration diversity

•QoS requirements diversity

Mapping problem artifacts to solution artifacts is hard

4

Case Study: Modern Office Environment• Office traffic operates over IP

networks & Fast ethernets• Multiple application flows:

• Email

• Videoconferencing

• Sensory (e.g., fire alarms)

• Differing QoS requirements• Fire alarm – highest priority

• Videoconf – multimedia

• Email – best effort

• QoS provisioned using DiffServ

Network QoS Provisioning Steps

1. Specify network QoS requirements for each application flow

2. Allocate network-level resources and DiffServ Code Points (DSCP) for every application flow joining two end points

3. Mark outgoing packet with the right DSCP values

5

Challenge 1: QoS Requirements Specification

• x

6

Challenge 2: Network Resource Allocation

• x

7

Challenge 3: Runtime Network QoS Settings

• x

8

NetQoPE Multistage Architecture

• Stage 1• Capabilities for intuitive and scalable network QoS specification

• Stage 2:• Capabilities for resource allocation and configuration

• Stage 3:• Capabilities for runtime support for QoS settings enforcement

9

Stage 1 : Model Driven Engineering

Office Scenario• Server room to control room is HP• Parking lot to control room is • Videoconferencing is MM• Temperature sensor is HR

• Model Driven Engineering solution• Component QoS Modeling

Language

• Provides intuitive abstractions to specify QoS

• Scalable solutions

• Developed in GME

• Network QoS modeling allows modeling QoS per application flow• Classification into high

priority (HP), high reliability (HR), multimedia (MM) and best effort (BE) classes

• Enables bandwidth reservation in both directions

• Client propagated or server declared models

10

Stage 2: Resource Allocator Engine

• xyz

11

Stage 3: Runtime Policy Framework

• xyz

12

Evaluating NetQoPE• Experimental Setup

• ISISlab setup blade servers running Fedora core

• DiffServ QoS over IP Networks

• Telcordia Bandwidth Broker

• Objectives (describe in one line what the 3 eval criteria are)

13

Results 1: Measuring Runtime Overhead

• Rationale

• Observations

• Analysis

14

Results 2: QoS Customization Capabilities

• Rationale

• Observations

• Analysis

15

Results 3: Admission Control Capabilities

• Rationale

• Observations

• Analysis

16

Concluding Remarks

<CONFIGURATION_PASS><HOME> <…>

<COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this component

supplies…></EVENT_SUPPLIER></COMPONENT></HOME>

</CONFIGURATION_PASS>

<CONFIGURATION_PASS><HOME> <…>

<COMPONENT><ID> <…></ID><EVENT_SUPPLIER><…events this component

supplies…></EVENT_SUPPLIER></COMPONENT></HOME>

</CONFIGURATION_PASS>

Benchmarking

Weaver

Synthesis

FunctionalModel

SystemicModel

Analysis

Domain

Access Resources

Assembler

Assembler

Planner

Domain Administrator

Specifies

CreatesComponent

ResourceRequirements

Impl Impl Impl

Properties

COMPONENT REPOSITORY

QoS Specs

Configurations

Dependencies

Developer

CreatesComponent Assembly

ComponentComponent

ComponentComponent

Creates Packager

Repository Administrator

Component Packages

Configures

Desktop Printer Laptop computer

Ethernet Bridge

Firewall

Creates

Executor

Deployment PlanUses

Deploys

www.dre.vanderbilt.edu

Plan Analyzers

XML to IDL

LISP to IDL

2D Bin packing

path

Priority Sched .

path

Plan Managers

2D Bin packing

Priority Sched .

Output Adapters

To DAnCE

To OpenCCM

Applications that fetch XML or LISP and call appropriate plug -ins

R-F

F-R F-R

F-R

R-F

F-R. Line source is a Facet and Line destination is a Receptacle

R-F. Line source is a Receptacle and Line destination is a Facet

R-F

Multiple levels of abstraction required for resolving tangling of QoS issues

• Need expressive power to define QoS intent in the problem space, and perform design-time analysis

top related