Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Published byPhilomena Wilson Modified over 9 years ago

Similar presentations

Presentation on theme: "Multi-Partner European Test Beds for Research Networking MUPBED/NOBEL Workshop Torino, November 2005 Interfacing applications."— Presentation transcript:

1 http://www.ist-mupbed.org/ Multi-Partner European Test Beds for Research Networking MUPBED/NOBEL Workshop Torino, 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)

2 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

3 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

4 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

5 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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)

6 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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.

7 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

8 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

9 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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)

10 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed HQ uncompressed video production (II) Connectivity Equipment Jitter measurements Uncompressed VLC MPEG-2

11 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

12 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

13 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

14 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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 backup 600 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

15 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Content – and storage – Lab setup Backup and restore logical scenario VoD logical scenario

16 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

17 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

18 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Summarising application ServiceQualityRequirements BWLatency jitter Packet lossModeReliability Storage and backup High120-600 MbpsUnicast Accelerated VoD streaming High to very high 50-100 MbpsUnicast Uncompressed video production High to very high 300-1500 Mbps 150 ms / 1 msMulticast P2P conferencing High1.5-20 Mbps150 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)HighVery high – depending on content LowUnicast

19 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

20 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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 “Bottom up” approach – what do we have? Modelling Identification of level of dynamicity Conclusions

21 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Adaptation function Adaptation function defined in WP1 API model

22 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Components of adaptation function

23 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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?

24 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

25 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

26 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Resource triggering algorithms (I) Resource registration Resource triggering Request confirmation

27 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

28 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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 “Bottom up” approach – what do we have? Modelling Identification of level of dynamicity Conclusions

29 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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?

30 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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 delaynotes Pure IP223.67s LSR_0->LSR_1: 189.65 LSR_3->LSR_1: 189.69; link rate < 2 services 1-way LSP223.67 LSR_3->LSR_1: 189.69; Blocking in return way Bi-LSP0.118-<150ms accepted

31 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Dynamic setting up of LSP Service periodClient node 100s ~ 200 sClient_1 220s ~ 320 sClient_4 340s ~ 440 sClient_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

32 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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 “Bottom up” approach – what do we have? Modelling Identification of level of dynamicity Conclusions

33 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed What to do? What to expect? To do! A lot! Continue the specification of the interface API Resource triggering Implementation of a light functionality interface Supporting simple API for few applications –First iteration: Multicast videoconferencing Dissemination/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

34 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed 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

35 Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Limit for content Do not exceed Questions ? Contact details: Henrik Wessing +45 45253804 hw@com.dtu.dk

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

Similar presentations

Network Resource Broker for IPTV in Cloud Computing Lei Liang, Dan He University of Surrey, UK OGF 27, G2C Workshop 15 Oct 2009 Banff,

Network Resource Broker for IPTV in Cloud Computing Lei Liang, Dan He University of Surrey, UK OGF 27, G2C Workshop 15 Oct 2009 Banff,
Generalized Multiprotocol Label Switching: An Overview of Signaling Enhancements and Recovery Techniques IEEE Communications Magazine July 2001.

Generalized Multiprotocol Label Switching: An Overview of Signaling Enhancements and Recovery Techniques IEEE Communications Magazine July 2001.
1 Chapter 11: Data Centre Administration Objectives Data Centre Structure Data Centre Structure Data Centre Administration Data Centre Administration Data.

1 Chapter 11: Data Centre Administration Objectives Data Centre Structure Data Centre Structure Data Centre Administration Data Centre Administration Data.
H. 323 Chapter 4.

H. 323 Chapter 4.
TCP/IP Protocol Suite 1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 25 Multimedia.

TCP/IP Protocol Suite 1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 25 Multimedia.
CS 414 - Spring 2012 CS 414 – Multimedia Systems Design Lecture 15 –QoS Admission, QoS Negotiation, and Establishment of AV Connections Klara Nahrstedt.

CS Spring 2012 CS 414 – Multimedia Systems Design Lecture 15 –QoS Admission, QoS Negotiation, and Establishment of AV Connections Klara Nahrstedt.
Ashish Gupta Under Guidance of Prof. B.N. Jain Department of Computer Science and Engineering Advanced Networking Laboratory.

Ashish Gupta Under Guidance of Prof. B.N. Jain Department of Computer Science and Engineering Advanced Networking Laboratory.
Application layer (continued) Week 4 – Lecture 2.

Application layer (continued) Week 4 – Lecture 2.
Restoration Routing in MPLS Networks Zartash Afzal Uzmi Computer Science and Engineering Lahore University of Management Sciences.

Restoration Routing in MPLS Networks Zartash Afzal Uzmi Computer Science and Engineering Lahore University of Management Sciences.
Multiple constraints QoS Routing Given: - a (real time) connection request with specified QoS requirements (e.g., Bdw, Delay, Jitter, packet loss, path.

Multiple constraints QoS Routing Given: - a (real time) connection request with specified QoS requirements (e.g., Bdw, Delay, Jitter, packet loss, path.
Shadow Configurations: A Network Management Primitive Richard Alimi, Ye Wang, Y. Richard Yang Laboratory of Networked Systems Yale University.

Shadow Configurations: A Network Management Primitive Richard Alimi, Ye Wang, Y. Richard Yang Laboratory of Networked Systems Yale University.
Path Protection in MPLS Networks Ashish Gupta Design and Evaluation of Fault Tolerance Algorithms with Performance Constraints.

Path Protection in MPLS Networks Ashish Gupta Design and Evaluation of Fault Tolerance Algorithms with Performance Constraints.
December 20, 2004MPLS: TE and Restoration1 MPLS: Traffic Engineering and Restoration Routing Zartash Afzal Uzmi Computer Science and Engineering Lahore.

December 20, 2004MPLS: TE and Restoration1 MPLS: Traffic Engineering and Restoration Routing Zartash Afzal Uzmi Computer Science and Engineering Lahore.
Restoration Routing in MPLS Networks Zartash Afzal Uzmi Computer Science and Engineering Lahore University of Management Sciences.

Restoration Routing in MPLS Networks Zartash Afzal Uzmi Computer Science and Engineering Lahore University of Management Sciences.
A General approach to MPLS Path Protection using Segments Ashish Gupta Ashish Gupta.

A General approach to MPLS Path Protection using Segments Ashish Gupta Ashish Gupta.
In-Band Flow Establishment for End-to-End QoS in RDRN Saravanan Radhakrishnan.

In-Band Flow Establishment for End-to-End QoS in RDRN Saravanan Radhakrishnan.
An Overlay Multicast Infrastructure for Live/Stored Video Streaming Visual Communication Laboratory Department of Computer Science National Tsing Hua University.

An Overlay Multicast Infrastructure for Live/Stored Video Streaming Visual Communication Laboratory Department of Computer Science National Tsing Hua University.
RATES: A Server for MPLS Traffic Engineering (Routing And Traffic Engineering Server) Zlatokrilov Haim Advanced Topics in IP Networks5/1/2001 Tel-Aviv.

RATES: A Server for MPLS Traffic Engineering (Routing And Traffic Engineering Server) Zlatokrilov Haim Advanced Topics in IP Networks5/1/2001 Tel-Aviv.
School of Information Technologies IP Quality of Service NETS3303/3603 Weeks 10-11.

School of Information Technologies IP Quality of Service NETS3303/3603 Weeks
1© Copyright 2015 EMC Corporation. All rights reserved. SDN INTELLIGENT NETWORKING IMPLICATIONS FOR END-TO-END INTERNETWORKING Simone Mangiante Senior.

1© Copyright 2015 EMC Corporation. All rights reserved. SDN INTELLIGENT NETWORKING IMPLICATIONS FOR END-TO-END INTERNETWORKING Simone Mangiante Senior.

Similar presentations

Ads by Google