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)

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

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

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

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)

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.

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

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

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: Mbit/s Jitter should be low (< 1ms)

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

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

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 ms Max skew of 80 ms Video pr. client: 11 Mbit/s Audio pr. client: 1.4 Mbit/s Clients across MUPBED infrastructure

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

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 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

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

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

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

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 High MbpsUnicast Accelerated VoD streaming High to very high MbpsUnicast Uncompressed video production High to very high Mbps 150 ms / 1 msMulticast P2P conferencing High 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

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

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

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

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

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?

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

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

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

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

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

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?

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: LSR_3->LSR_1: ; link rate < 2 services 1-way LSP LSR_3->LSR_1: ; Blocking in return way Bi-LSP0.118-<150ms accepted

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

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

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

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

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