Http:// Multi-Partner European Test Beds for Research Networking MUPBED/NOBEL Workshop Torino, November 2005 Interfacing applications.

http://www.ist-mupbed.org/

Multi-Partner European Test Beds for Research Networking

MUPBED/NOBEL WorkshopTorino, November 2005

Interfacing applications with network control plane

Based on the work of MUPBED Work Package 2

Henrik Wessing Technical University of Denmark (DTU)Department of Communications, Optics and Materials (COM)

Disclaimer

Nothing new in this speech Anyway: “Everything that can be invented has been invented” Heard at NOBEL MUPBED workshop 2005 But originally from Charles H. Duell, 1899

High demandingapplication client

GMPLS

MPLS

High demandingapplication server

Motivation

Application initiates at client Application requests network resources Network dynamically allocates resources Issues to consider

Application to network interface User network interface (UNI) Multidomain traffic engineering Application requirements

UNI

UNINNI

Outline

Why WP2 i MUPBED? Applications for trial in the MUPBED test bed

Application requirements Preparation of lab facilities Mapping of application to service classes

Application network interface discussion Receiving resource requests Translation of requests Advance reservation emulation

Modelling Identification of level of dynamicity

Conclusions

WP2 partners (with MM in WP2)

Equipment Manufacturers Juniper Networks (Ireland)

Network Operators Telecom Italia – TILAB (Italy) Telefonica I+D (Spain)

Research Centres Acreo (Sweden) DTU (Denmark) CSP - Innovazione nelle ICT s.c. a r.l.

(Italy) University of Erlangen-Nuremberg

(Germany) GARR (Italy) CSIC/Red.es (Spain) PSNC (Poland)

General WP2 activities

Applications Which applications to trial in test bed? Requirements of today’s and future research applications. Preparation of applications for trial in the test bed

User groups Professional user groups and sub contractors Research and development user groups Groups within and outside the MUPBED consortium

Modelling Simulations to identify the minimum application burst time where an LSP

setup is beneficial. Application network interface

API based interface Translation of application requirements to network parameters Triggering of resource allocations Interfacing to packet and circuit layer.

The way to go!

Iterative process Definition and selection of first batch of applications to trial Specification of application to network interface

Translation of network requirements Development of API Implementation of light version of interface

Disseminate and promote API for user groups Let user communities use API in MUPBED

If possible for their operations Else for test and research purposes

Next iterations of applications and special requirements Experimental and simulation work to fine tune parameters

Outline

Why WP2 i MUPBED Applications for trial in the MUPBED test bed


Application network interface discussion Receiving resource requests Translation of requests Advance reservation emulation


Conclusions

HQ uncompressed video production (I)

For remote studio with online editing

Delay < 150 ms Each camera:

BW: 300-600 Mbit/s

Jitter should be low (< 1ms)

HQ uncompressed video production (II)

Connectivity Equipment Jitter measurements

Uncompressed VLC MPEG-2

Grid computing and VO (I)

Grid computing – generic requirements

From Kbit/s to Tbit/s Diverse delay requirements

Virtual Organisations Remote signature and

compression functions BW and QoS dependent on

user patience Require exact provisioning to

take advantage of dynamicity Security an issue

Internet

Control Framework

Server MD5 Application

Web Server

Server ZIP Application

QoS VPN

Virtual Organization

MPLS/IP

Client

ASP-1

ASP-2

Optical Network

Optical Network

MUPBEDNetwork

Video conferencing - Requirements

Point to point HQ video conferencing Person to person communication High quality Audio: 1.5 Mbit/s Video: 20 Mbit/s (depending on codecs)

Multipoint conferencing Latency less than 40-50 ms Max skew of 80 ms Video pr. client: 11 Mbit/s Audio pr. client: 1.4 Mbit/s Clients across MUPBED infrastructure

Multipoint video conferencing setup

1. Static provisioning for specific hardware

2. Mechanisms for dynamic service provisioning

3. 3 partner scenario established with client on different MANs

4. Scenario includes link failure and switchover

LS1010

STM1 155-MbpsATM

PVC-2 (70/50) 34 Mbps130.206.206.14/30

130.206.206.13/30

Video-conference partner-1

IP/MPLSBACKBONE

NAT 10.4.x.x/16

193.146.141.0/29

RedIrisRedIris

hdtvserver10.4.100.34

(193.146.141.1)

MAN-1

A/VoD serverHDTV serverWeb serverDNS server

MAN-2



RP

GeantGeant

GBE

FE

MSMMSMServices ManagerServices Manager

Stream

ing m

(1)

Sig

na

llin

g m

(4)

m(3

)

m(1

)

Signal

ling m

(4)

m(2

)

m(3

)

Str

eam

ing

m(2

)

Signalling m(4)

Streaming m

(3)m

(2)m

(1)

Shared-tree

Source-tree

Content – and storage - Requirements

Backup and restore service Distance from data center 50-100 km Backup time of 1-5 min for 1 TB data Bandwidth:

120 Mbit/s for backup600 Mbit/s for restore

Dynamic BW required Security as data sensitive

VoD streaming CDN and E2E investigated CDN: 100 Mbit/s E2E: 50 Mbit/s Requirements for latency, jitter and packet loss

Content – and storage – Lab setup

Backup and restore logical scenario

ClientSite

Optical Network

Optical Network

MPLS/IP

Control Framework

QoS

IP/ OpticalBackbone

CDNCache

CDNCache

ServerSite

VoD logical scenario

ClientSite

Optical Network

Optical Network

MPLS/IP

Control Framework

QoS

Storage Area Network

Fibre Channel/iSCSI

applicationservers

storage

LAN

Server Site

IP/ OpticalBackbone

Open Media Streaming

Evaluating Free OMSP distribution Server: Fenice Player: Nemesi Web based scheduling: Palinsesto

BW from 128 Kbit/s to 1 Mbit/s Allows up to 70 clients in MUPBED setup: 490 Mbit/s in total

Peer to peer communication problem

Problem of peer to peer communication when: Peer are on same LAN They wish to use different ISP

In collaboration with KTH in Stockholm Problems discovered in typical network architectures

VLAN ring architecture VLAN Policy based routing and a control station Pure IP layer 3 equipment

Solution to investigate: MPLS-IX to interconnect several MANs Allows local traffic to stay local User can choose ISP of their choice Easy adaptable solution

HostA

Host BEthernet network

Transport linkISP 1

IP router

ISP 2Ethernetswitch

Summarising application

Service Quality Requirements

BW Latency

jitter

Packet loss Mode Reliability

Storage and backup

High 120-600 Mbps Unicast

Accelerated VoD streaming

High to very high

50-100 Mbps Unicast

Uncompressed video production

High to very high

300-1500 Mbps

150 ms / 1 ms Multicast

P2P conferencing

High 1.5-20 Mbps 150 ms / 50 ms

< 1% Unicast

Multipoint video conferencing

High to very high

2-13 Mbps pr. partner

150 ms / 50 ms

< 1% Multicast

Grid (VO) High Very high – depending on content

Low Unicast

MUPBED Service classes

8 service classes 6 in use

T = 150 ms B = 100 Mbps P = 1 %

Most new applications should be mapped to the service classes

For each service class Separate API Different triggering

parameters Flexible

Separation only recommended

Outline



Application network interface discussion Receiving resource requests Translation of requests Advance reservation emulation “Bottom up” approach – what do we have?


Conclusions

Adaptation function

MUPBED multi-service transport network

Data Plane

Control Plane

SDH

IP/MPLS

Overlay Peer-to-Peer

Application

IP/MPLS

Ethernet Ethernet

FibreOTH

API

Application

API

App-Net-If

Adaptationfunction

App-Net-If

Adaptationfunction

Adaptation function defined in WP1 API model

Components of adaptation function

Grid middlewareVideo

conferencingContent Storage

class

NSR 1 NSR 2 NSR 3

NSP 1

API basedon SOAP

NSP 2 NSP 3

Class specificfunction



Translation of requirements

Advance resource allocation function

Circuit domain resourceallocation

Packet domain resourceallocation

UNI-C (OIF/IETF)RSVP-TE (MPLS)

UNI-N - (OIF/IETF)RSVP-TE (Edge node)

Interfacing

Requirement translation

Resource allocation

Ada

ptat

ion

func

tion

Generic API proposal

Generic or specific depending of service class definition

Can include parameters for circuits (protection)

Parameters to be discussed.

API format Web services based SOAP?

API Name Description Sinchronous Return

Parameters RP Type Argument Name Argument Type

SetQoS QoS Contreol

Request X

Return Int session_id Int

Handler Int Service String

Media String

Codec String

QoS_class String

Bandwith Bw

SourcePort Int

DestinationPort Int

Transport String

Direction Enum

1..N

Priority Int

SourceAddress IP_Address

DestinationAddress IP_Address

start_time Time

end_time Time

UnSetQoS Unset Resources

Request X

Return Int Session_id Int

Handler Int

Translation of resource requests

Translation of requirements From fuzzy application requirements to hard network parameters

Complete decoupling between the resource request and the application

Service classes helps in defining default parameters

Max. delay

Max. delay jitter

Avg. bandwidth

Peak bandwidth

Connection start time

Connection terminatetime

Constraints to route

The world we live in!

Advance reservations not supported A path is established only at the beginning of the reservation time No acknowledge before then Advance reservations changed to a probability issue

Example scenario E2E circuits on demand Communication from A

Request handling Registering Aggregating Triggering resources Failure or success before deadline Development of algorithms

D

C

B

UNI

UNIA

Resource triggering algorithms (I)

Resource registrationupdate

A

B

End

Register/delete request indatabase

Update aggregationparameters

Confirm registration/deletion. Notify the totalaggregated traffic for the

period

C

Resource triggering

Compare presently reservedresources with required

registered resources withinpredefined period

A

Unused resources?

Are more resourcesrequired?

No

BYes

No

Yes

Request resources in thecircuit layer

C

Release unusedresources in circuit layer

End

D

E

Yes

Notification

A

B

End

Compare reserved resourceswith resource registrationwithin ”deadline” period

Send reservationconfirmations for request IDs

involved

Sufficient capacity

No

Send error messages for IDsinvolved. Remove request

from databaseC

Resource registration

Resource triggering

Request confirmation

Resource triggering algorithms (II)

No hard guarantees provided No real advance reservation Inherent for RSVP signalling based path setups

Different parameters for each service class Increasing preallocation period

Reduced utilisation Increased possibility of successful resource allocation

Decreasing preallocation period Increased utilisation The resources may not be fully available at time of reservation

Cost model important For applications (clients) using the service For circuits depending on the current usage

Definition of parameters Experimental work with the integration of the applications into the testbed Comments from user groups Modelling and simulation work

Outline





Conclusions

Modelling and simulation in WP2

Objectives Support definition of limits for dynamics (scale of dynamics) Identification and tuning of adaptation function parameters What happens with an increased number of users and

applications? (WP1/WP2) Scenarios for scale of dynamics

High bursts (simulating uncompressed video) Question:

When is it beneficial to set up an LSP (packet or circuit)?What is the impact of the LSP?

Effect of traffic engineering

For this specific case Infinite router queues Results as expected Routing Path

Pure IP: all on blue Constraint LSP: blue and red

Node Pkt end-to-end delay

Link p2p delay notes

Pure IP 223.67s LSR_0->LSR_1: 189.65

LSR_3->LSR_1: 189.69;link rate < 2 services

1-way LSP 223.67 LSR_3->LSR_1: 189.69; Blocking in return way

Bi-LSP 0.118 - <150ms accepted

Dynamic setting up of LSP

Service period Client node

100s ~ 200 s Client_1

220s ~ 320 s Client_4

340s ~ 440 s Client_2

Client_5

OSPF-TE as routing protocol – default configuration

Data transmission is permitted after setting up LSP.

10 second for LSP setting up and tearing down

20s between two data transmission Trade of in OSPF-TE

LSP set up

Data transmission

LSP tear down

Outline





Conclusions

What to do? What to expect?

To do! A lot! Continue the specification of the interface

APIResource triggering

Implementation of a light functionality interfaceSupporting simple API for few applications

– First iteration: Multicast videoconferencingDissemination/promotion/demonstration for user groups

Integration of the applications with the interface To expect!

A lot! Suggestions for implementing BoD in existing telco networks Generic interface for future applications

Conclusions

We want application driven bandwidth provisioning in heterogeneous networks!

NREN networks Telco networks

Applications have been studied and classified Lab facilities for integrating selected applications in the test bed

have been installed Definition of application network interface

Emulation of advance reservations Running over standardised networks

Tuning of parameters through modelling and experimental work Implementing, disseminating and demonstrating light interface

to user communities

Questions

?Contact details:

Henrik Wessing

+45 45253804

[email protected]

Http:// Multi-Partner European Test Beds for Research Networking MUPBED/NOBEL Workshop Torino, November 2005 Interfacing applications.

Documents

network parameters

specification of application

development user groups

interfacing applications

preparation of applications

network control plane

future research applications

batch of applications