MUPBED/NOBEL Workshop Torino, November 2005

1. MUPBED/NOBEL WorkshopTorino, November 2005 Interfacing applications with network control plane Based on the work of MUPBED Work Package 2Henrik Wessing Technical University of Denmark (DTU)Department of Communications, Optics and Materials (COM)

2. 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. 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. 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. 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. 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. 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. 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. 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 (I)

10. HQ uncompressed video production (II) • Connectivity • Equipment • Jitter measurements • Uncompressed • VLC MPEG-2

11. 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. 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. Multipoint video conferencing setup • Static provisioning for specific hardware • Mechanisms for dynamic service provisioning • 3 partner scenario established with client on different MANs • Scenario includes link failure and switchover

14. 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. Content – and storage – Lab setup Backup and restore logical scenario VoD logical scenario

16. 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. 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. Summarising application

19. 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 MUPBED Service classes

20. 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. Adaptation function • Adaptation function defined in WP1 • API model

22. Components of adaptation function

23. 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. 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. 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. Resource triggering algorithms (I) Resource registration Resource triggering Request confirmation

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

31. Dynamic setting up of LSP • 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. 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. 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. 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. Questions ? Contact details: Henrik Wessing +45 45253804 hw@com.dtu.dk