http:// multi-partner european test beds for research networking mupbed/nobel workshop torino,...
TRANSCRIPT
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 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
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
Video-conference partner-2
Video-conference partner-3
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
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
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
Class specificfunction
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
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
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
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
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