virtcloud&couniverse one2eservicesforgridsandmultimedia · 2008-12-02 · ams-ix písek sanet...

1/36

On E2E Services and Apps CoUniverse VirtCloud Demos Outlook for the future

VirtCloud & CoUniverseOn E2E Services for Grids and Multimedia

Petr Holub<[email protected]>

Laboratory of Advanced Networking TechnologiesCESNET, Czech Republic

Masaryk University

1st E2EWorkshop – Establishing LightpathsTERENA

Amsterdam, 2008–12–02

http://www.sitola.cz/

http://www.ces.net/

mailto:[email protected]


http://www.ces.net/

2/36


Talk Overview

On E2E Services and Apps

CoUniverse

VirtCloud

Demos

Outlook for the future


http://www.ces.net/

3/36


What do we understand under E2E?

. . . actually a very good question

● dedicated L1 paths

● dedicated L2 clouds (pure, VPLS)

● dedicated L3 networks

● dedicated point-to-point links

● private multi-point networks

. . . but why dowe call all of this end-to-end?

● because we need to connect to all of them

● we need it all the way to the end-node


http://www.ces.net/

4/36


What do we understand under E2E?

. . . but is it any di�erent from any other network?

. . . and how about

● application-speci�c networks

● overlay networks


http://www.ces.net/

5/36


Why do we need E2E?

● Get bandwidth to somewhere◾ . . . workaround for �awed production networks◾ sometimes easier to solve last hop problem◾ sometimes easier to get funding for (it has to be research then)

● Tra�c isolation and “guarantees”◾ important for applications with bitrates comparable to linkcapacities◾ to what extent can this be implemented in productionnetworks?

● Cheaper L2 equipment◾ “lame” excuses of network administrators when it comes to10GE ports on their routers ;-)◾ we’re down to 1.200 EUR per 10GE LR port w/o VAT


http://www.ces.net/

6/36


Why do we need E2E?

● Low-jitter of L2 network● Some special properties

◾ introduction of various devices on de�ned positions in thenetwork◾ re�ectors, optical multicasting switches, tra�c monitors, etc.


http://www.ces.net/

7/36


Our applications of interest● UltraGrid: low-latency high-de�nition video over IP

◾ 1.5 Gbps uncompressed streams◾ 250Mbps compressed streams◾ Holub P., Matyska L., Liška Miloš, Hejtmánek L., Denemark J., Rebok T., Hutanu

A., Paruchuri R., Radil J., Hladká E. “High-de�nition multimedia for multipartylow-latency interactive communication.” Future Generation Computer Systems,Elsevier Science, The Netherlands. ISSN 0167-739X, 2006, vol. 22, no. 8, pp.856–861.

● CoUniverse: orchestration of real-time collaborativeapplications◾ Liška M., HOLUB P. “CoUniverse: Real-time User-empowered Collaborative

Environment Framework.” In Real-Time Online Interactive Applications (ROIA) onthe GRID (ROIA 2008), EuroPar 2008.

● VirtCloud: virtualized network for virtualized Grids◾ Antoš D., Sitera J., Holub P., Matyska L. “METACenter Virtual Networks.” Cracow

GridWorkshop’08. 2008.

● CzechLight Multicasting Switch: recon�gurable broad-bandphotonic multicast


http://www.ces.net/

8/36


In collaboration with our partners

● Louisiana State University◾ Visualizations with distributed data sources◾ Introduction to High-Performance Computing by prof. ThomasSterling

● Electronic Visualization Lab (EVL)◾ Collaboration on utilizing OptIPortal

● CineGrid


http://www.ces.net/

9/36


CoUniverse

● Self-organizing application orchestration for real-timemedia-based collaborative applications● Requirements

◾ self-organized system that can accommodate changes inunderlying infrastructure◾ support for applications with bandwidth requirementscomparable to link capacity◾ incorporation of external applications◾ support for multi-point data distribution◾ built-in monitoring and visualization◾ as user-empowered as possible

● Universe◾ each for single collaborating group


http://www.ces.net/

10/36


CoUniverse

● Architecture◾ control plane

◆ distribution of control information◆ self-organizing P2P control plane◆ optimized for robustness◆ not optimized for throughput

◾ data plane◆ uses native network

◾ application encapsulation◆ start/stop/restart◆ on-the-�y control if supported

◾ built-in monitoring◆ network (end-to-end)◆ nodes◆ applications

◾ scheduler for media streams◆ including multi-point data distribution based on re�ectors


http://www.ces.net/

11/36


CoUniverse

● Implementation◾ Java-based implementation◾ JXTA overlay network for control plane◾ Application Group Controller

◆ scheduler based on constraints solver◆ creates plan for setting up nodes based on users’ requirements◆ handles network setup if needed◆ distributes plan to required nodes to con�gure themselves◆ when change in the underlying infrastructure is detected, new

plan is computed◾ currently supported applications

◆ UltraGrid in various modes◆ MBone Tools◆ several �avors of re�ectors


http://www.ces.net/

12/36


VirtCloud

● Virtualization changes the way Grids can work◾ interactive jobs based on preemption◾ migration of virtual (typically computational) nodes◾ nodes may run insecure (user-provided) virtual machines

● We need networks that can support these usecases◾ reasonable setup time◾ private network by default◾ migration of IP addresses (which need to be retained by theapplications in order to ensure uninterrupted operation)◾ high performance, low latency, low jitter needed (datatransfers, MPI communication, etc.) Ô⇒ minimize the penalty


http://www.ces.net/

13/36


VirtCloud

● Virtual network for virtual clusters

● Managed by the virtual cluster management system

● Architecture

◾ �at private L2 network for each virtual cluster


http://www.ces.net/

14/36


VirtCloud

● Architecture (cont’d)◾ core network

◆ con�gured only once to carry the VLANs needed◆ should use some native technology (QinQ, VPLS, Xponders)

◾ site network◆ this is dynamically recon�gured to enable VLANs for individual

physical hosts◾ physical node

◆ hosts one or more virtual nodes◆ each virtual node can access one VLAN◆ physical host uses trunking to connect to the site network

◾ incorporation of additional services if needed◆ tunnels (OpenVPN, SSH), routers (for direct access from/to

outside), �le servers◆ user can publish his/her cluster using his own address range

(providing own router)


http://www.ces.net/

15/36


SBF: Slartibartfast Prototype

● Simple implementation, that virtual cluster managementsystemMagrathea can interact with

● Uses Ethernet over CESNET2 network● Core network: VPLS or Xponders

◾ VPLS uses production MPLS backbone (shares tra�c)◾ Xponders run over a separate λ over production DWDM system

● Site networks: Brno, Prague, Pilsen◾ L2 equipment frommultiple vendors: HP, Force10, Cisco


http://www.ces.net/

16/36


Talk Overview

On E2E Services and Apps

CoUniverse

VirtCloud

Demos

Outlook for the future


http://www.ces.net/

17/36


CESNET Network Topology

Praha

Liberec

Pardubice

Brno

Olomouc

Ostrava

Opava

NIX

Internet

ChebPoděbrady

GÉANT

AMS-IXPísek

SANETACONET

PIONIER

Dvůr Králové

Krnov

Kyjov

Jihlava

Řež

Děčín

Ústí n. L.

Plzeň

Beroun

Č. TřebováLitomyšl Karviná

ZlínVyškov

Břeclav a Lednice

České Budějovice

Nové Hrady

J. Hradec

Tábor

TřeboňTelč

Znojmo

Hradec Králové

Most

Kostelecnad Č. L. Kutná

Hora

MariánskéLázně

Jablonec n. N.

Prostějov

Uherské Hradiště

DWDM10 Gb/s1–2,5 Gb/s100 Mb/s<100 Mb/s


http://www.ces.net/

18/36


Introduction to HPC Class● Class taught at LSU by prof. Thomas Sterling

◾ others may participate using technology of their choice(UltraGrid uncompressed or compressed HD over IP, HD H.323,AccessGrid, webcasting)◾ Masaryk University participates using uncompressed HD over IP◾ Runs twice a week for each spring semester


http://www.ces.net/

19/36


Introduction to HPC Class● Uses CzechLight and LONI, interconnected in StarLight usingVLAN 90◾ Louisiana Optical Network Initiative – state-wide network withuplinks, e.g., to StarLight◾ currently moving from NLR to Internet2 DCN

Starlight / ChicagoCCT-LSU / Baton Rouge

Brno

LSUSender

BrnoReceiver

ArkansasReceiver

LATechReceiver

172.30.3.101

130.39.195.71

172.30.3.102

130.39.195.72

172.30.3.103

130.39.195.73

172.30.3.104

130.39.195.74

Brno

Sender

LSU

Receiver

172.30.3.10

147.251.54.34

172.30.3.11

147.251.54.35

CISCO

6509Calient PXC

LSU Reflector172.30.3.150

Calient PXC E 1200 HDXc

Starlight Reflector

172.30.3.56

Netherlands HDXc

Prauge CISCO 15454

CISCO 15454

CISCO 6506

LATech

LATech

Sender

LSU

Receiver

172.30.3.201

xxx.xx.xxx.xxx

172.30.3.202

xxx.xx.xxx.xxx

CISCO 6509

LONI

Univ of Arkansas

ARK

Sender

LSU

Receiver

172.30.3.151

xxx.xx.xxx.xxx

172.30.3.152

xxx.xx.xxx.xxx

Switch

OneNet

Tulsa, OK

NLR


http://www.ces.net/

20/36


SuperComputing’08 Demos

● EVL demo: Visualcasting◾ streaming to 4K prototype display at EVL booth◾ large international collaboration◾ streaming to number tiled screens world-wide


http://www.ces.net/

21/36



● EVL demo: Visualcasting◾ SAGE middleware (EVL)◾ SAGE streaming: video and visualizations (EVL, CalIT2, CineGrid)◾ UltraGrid displaying on SAGE screen (Sitola/CESNET/MU)◾ uses application-level re�ectors for multi-point datadistribution


http://www.ces.net/

22/36



● EVL demo: Visualcasting◾ Bandwidth Challenge �nalists


http://www.ces.net/

23/36



● LSU demo: Visualization withdistributed data sources◾ multiple data sources (clusternodes) in Brno◾ visualization server at LSU◾ streaming of rendered data toshow�oor


http://www.ces.net/

24/36


Internet2 Fall 2008 MM Demo

● Showcase for Introduction to HPC● Allocation of E2E services: Internet2 DCN and AutoBAHN

◾ integration of two middleware systems◾ real-time demo, took about 10 s to setup Internet2 DCN

● two 250Mbps streams – 1GE limitation on show�oor


http://www.ces.net/

25/36


Internet2 Fall 2008 MM Demo


http://www.ces.net/

26/36


GLIF’07 Demo● Demonstration of CzechLight Multicasting switch (CLM) in aCESNET network● Demonstration of physical properties of CLM 4×4

◾ independence on input signal format◾ can work on many wavelengths at once

● Demonstration of what can be done with a good productionnetwork◾ 1.5 Gbps uncompressed tra�c carried along with normal tra�c

Prague

Brno

Pilsen

iperf-s

iperf-r HD-s

HD-r

HD-r iperf-r

HD-r

HD-s

CLM

sw

itch

4x4


http://www.ces.net/

27/36


GLIF’07 DemoActual setup


http://www.ces.net/

28/36


GLIF’08 Demo

● Deployment of CLM in larger network spanning multipleorganizations● Streaming from Brno to multiple locations using UltraGrid

◾ CLM in StarLight◾ target locations:

◆ PNWGP, Seattle (CineGrid workshop)◆ Cal-IT2 UCSD, San Diego◆ i2CAT, Barcelona◆ Brno (backward channel)


http://www.ces.net/

29/36


GLIF’08 DemoActual setup

UCSDCalit2

PNWGPCW

6506GLIFMog

HD RX

7609

CW6506

ERS8600

Barcelona

i2CATHD RX

SLe1200 HD RX HD TX

CW65066509

e1200

HD RX

StarLight

CzechLight

NetherLight

BrnoC6506

PrahaE300

CAVEwave(2155)

C-Wave(2155)

C-W

ave

(215

5)

INR

C(2

155)

(440)(441)

CESNET(trunk 440,441)

(2155)

(2155)

EVLe600

CESNETMOXC

(441)

I1O1O2

O3

O4

(445)(2155)

Spanning tree OFF on these ports

static route:10.200.200.0/24 10.200.100.1IP 10.200.100.100

IP: 10.200.200.200MAC: 10:10:10:10:10:10

IP: 10.200.200.200MAC: 10:10:10:10:10:10 IP: 10.200.200.200

MAC: 10:10:10:10:10:10

IP: 10.200.200.200MAC: 10:10:10:10:10:10

Configuration for EVL e600 and C7609 on the next slide

‚TX only‘RX onlyRX only

RX only

Tx

Rx

6/2

6/66/106/14

7609# Ten?/? unidirectional send-only

MRENe1200

RX only

0/0


http://www.ces.net/

30/36


Future ideas on our apps

● Extensions of CoUniverse◾ more scalable, topology-aware scheduling◾ interfaces for Internet2 DCN and AutoBAHN◾ embedding DHCP server for private L2 networks◾ improved monitoring

● VirtCloud◾ evaluate longer term stability◾ attempts to span the Atlantic (collaborators from LSU, ANL)◾ further investigation what other middleware systems can do forus and if found useful, integrate with them


http://www.ces.net/

31/36


How to connect to the E2E services?

● . . . from the end-user point ofview● A�ordable technologies toaccess core◾ 10GE PCIe cards (e.g., Myrinet)◾ dense L2 10GE switches◾ LR optics 10GE◾ DWDM XFP for 10GE cards◾ copper or optics for 1GE


http://www.ces.net/

32/36


What do we need from E2E services?

● Finely crafted APIs

● Multi-point clouds, not point-to-point links● Information on topology of built cloud

◾ important for media streams with bitrate comparable to linkcapacity◾ what links are “additive”

● Virtualization of network elements: getting more functionalityinside the network◾ is this correct at all?◾ separation of applications in resource-controlled virtualmachines may help control and stabilize behavior of networknodes◆ infamous example of multicast: what if I need it as a �rst class

service?

◾ DiProNN by Tomáš Rebok (CESNET/MU)


http://www.ces.net/

33/36


Well. . . and how about network virtualization?A few heretic ideas

● Everybody talks about it. . .but what is network virtualization?◾ “giving you sense that you have the network for yourself”◾ multiplexing of tra�c◾ some (QoS) guarantees◾ virtualization of network elements◾ virtualization on L1◾ overlay networks


http://www.ces.net/

34/36


Well. . . and how about network virtualization?A few heretic ideas

● OK, and what is new about it?◾ we use multiplexing in packet networks anyway◾ we have attempted to do QoS in the past

◆ and often failed for various reasons. . .so why should it succeed this time?

◆ virtualization of network elements could bring some fresh ideas◾ virtualization on L1 is here for some time

◆ maybe if we can make it more �exible (photonic switches, etc.)

◾ overlay networks are known to work, but not that e�cient


http://www.ces.net/

35/36


Why do we need E2E?(Heresy again)

● Is it something that will co-exist with “perfect” productionnetworks?

● May it become part of the “perfect” production network?


http://www.ces.net/

36/36


Thank you for your attention!

Q?/A!

<[email protected]>


http://www.ces.net/

mailto:[email protected]

virtcloud&couniverse one2eservicesforgridsandmultimedia · 2008-12-02 · ams-ix písek sanet...

Documents