research network infrastructure project “mupbed”: …research network infrastructure project...
TRANSCRIPT
http://www.ist-mupbed.org/
Multi-Partner European Test Beds for Research Networking
Research Network Infrastructure Project “MUPBED”: Overview, Interworking Issues, Relevance for GN2 and NRENs
Jan Späth, Hans-Martin Foisel
With support from MUPBED partners
19th TF-NGN MeetingNovember 3 – 4, Athens
10/11/2005 - 2
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerationsMUPBED network realisationMUPBED / standardisationQuestions to NRENsSummary
10/11/2005 - 3
MUPBED Goals and Objectives
integrate and validate “telecommunication operator’s concepts” within research networking infrastructure
on-demand circuit switching techniquesin particular ASON/GMPLS control plane technologies
consider a multi-domain, multi-layer “real world” environmentidentify service/network requirements of high-end applications for European research environments and develop appropriate solutionscreate a European scale experimental environment to assess and prove the developed solutionsdevelop guidelines for the introduction of ASON/GMPLS technologies and ultra-broadband services in future European networks (including research networks)
(note: here the term “ASON” covers multiple transport technologies, such as WDM, OTH, SDHalso frequently used is the term “ASTN” in this context; acronyms: see last slide)
10/11/2005 - 4
Key Project Data
Planned duration:3 years; begin: 1st July, 2004
Consortium: 16 partners from 8 countriesDenmarkGermanyHungaryIrelandItalySpainSwedenPoland
Available Test-beds:2 ASON/GMPLS focussed test-beds (Italy, Germany)1 GMPLS focussed test-bed with broad-band end-users (Sweden)1 IP/MPLS focussed test-beds (Spain)1 Ethernet based test-bed (Poland)a variety of ultra-broadband users and applications “User Community”
10/11/2005 - 5
MUPBED ConsortiumEquipment Manufacturers
Marconi ONDATA (Germany); Project Co-ordinatorMarconi SpA (Italy)Juniper Networks (Ireland)
Network OperatorsTelecom Italia – TILAB (Italy)Deutsche Telekom - T-Systems (Germany)Telefonica I+D (Spain)Magyar Telekom (Hungary)
Research CentresACREO (Sweden)TU Denmark (Denmark)CSP - Innovazione nelle ICT s.c. a r.l. (Italy)CoreCom (Italy)University of Erlangen-Nuremberg (Germany)DFN-Verein (Germany)GARR (Italy)RedIRIS/Red.es (Spain)PSNC (Poland)
10/11/2005 - 6
GÉANT
RESEAU
GARR
TID TB
RedIRIS
DFN
DTU
user community
TID
FAU
CSP
TILAB
T-Systems
xyz Academic
xyz Private R&D
Acreo
CoreComSouthern Europe
test bed
Central Europetest bed
Northern Europetest bed
Western Europetest bed
NORDUnet
PIONIER
Eastern Europetest bed
Acreo TB
IP + ASON/GMPLS
IP + WDM
IP + WDM + 10GE
IP + 10GE
PSNC
Labs
Networks
user community
user community
UPC
IP/MPLS
user community
T-Systems TB
TILAB TB
Layout of planned MUPBED NetworkLayout of planned MUPBED Network
10/11/2005 - 7
MUPBED Architecture Framework
Data Plane
IP/MPLS
SDH OTH Lambda Fibre
EthernetEthernet
IP/MPLSPacketlayer
Circuitlayer
MUPBED multi-service transport network
Application Plane
HQvideo
videoconf
content/storage GRID
Control Plane
GMPLS Peer-to-Peer ApproachOverlay approach Packet Layer CPCircuit Layer CP
ControlPlane
Mngmnt
DataPlane
Mngmnt
MngmntPlane
Application-Network Interface
10/11/2005 - 8
Interoperability Areas within the MUPBED Network
ASON/GMPLS
IP/MPLS
Interaction betweenApplications and
Network
Interoperability between Network Domains
Network Domain 1
ASON
IP/MPLS
Network Domain 2
GMPLS
IP/MPLS
Network Domain N
Applicationplatforms
End-users/Applications
MultiserviceNetwork
Interworking between IP/MPLS
and ASON/GMPLS
10/11/2005 - 9
Relevance of MUPBED for NRENs
convergence of “telecom operator” and NREN solutionsnetwork architecture work, selected theoretical investigationsleading edge control plane solutions:
focus on ASON approach, including multi-domain inter-working driving standardisation
work on “application – network” inter-working (details: see back-up):dedicated MUPBED Work Package (WP 2)applications (requirements, selected trials in test bed)user groups (within and outside the MUPBED consortium)modelling and simulationsapplication network interface (translation of requirements to network parameters, triggering of resource allocations, …)
extended field trials for selected solutions: set-up and operation of European scale test bed
10/11/2005 - 10
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerations
data plane, control plane, and their integrationmulti-domain, multi-layer inter-working
MUPBED network realisationMUPBED / standardisationQuestions to NRENsSummary
10/11/2005 - 11
GEANT2 – NREN / IST-Projects Network Scenario
NREN #3
NREN #2
NREN #1
NREN #4
GEANT 2NREN # x
GEANT 2: Support of IP and lower layer transport services requested by customers (NRENs, IST Projects)
Project # z
Project #1
Project # x
Project # y
10/11/2005 - 12
Architecture: Options for Data Transport (1) Interface NREN - GEANT2
IP/MPLSIP
IP/VPN
Native Ethernet
NG – SDH
OTN
Data plane functions – scenario 1
GEANT 2NREN
10/11/2005 - 13
Architecture: Options for Data Transport (2) Interface NREN - GEANT2
IP/MPLS
Ethernet Native Ethernet
NG – SDH
OTN
Data plane functions – scenario 2
GEANT 2NREN
10/11/2005 - 14
Architecture: Options for Data Transport (3) Interface NREN - GEANT2
IP/MPLS
SDH
Native Ethernet
NG – SDH
OTN
Data plane functions – scenario 3
GEANT 2NREN
10/11/2005 - 15
GEANT2 – NREN/ IST-Projects Network Scenario
Potential next step: Getting these network domain to interwork automatically,but maintaining the independent control of each domain
Integration of data and control plane functions
NREN #3
NREN #2
NREN #1
NREN #4
GEANT 2NREN # x
Project # z
Project #1
Project # x
Project # y
10/11/2005 - 16
ASON Network Architecture #1
Client domain #1
Backbonedomain #1a
Backbonedomain #1
Client domain #2
Backbonedomain #1b
UNI UNI
E-NNI
I-NNIUNI: User Network InterfaceE-NNI: External Network Network InterfaceI-NNI: Internal NNI (vendor specific)
10/11/2005 - 17
ASON Network Architecture #2
Control Plane based network functionsIntra-domain functions based on distributed signaling and routing:
Auto discovery and self inventoryTraffic engineering based on different parametersCombination of protection and restoration schemes
Inter-domain functions based on control plane interfaces:Seamless interworking with client networks via User Network Interface (UNI)Automatic interworking among transport network domains via External Network-Network Interface (E-NNI)
10/11/2005 - 18
ASON Network Architecture #3
New control plane based servicesIntra-domain
New resilience schemes based on protection and restorationFast provisioning of Soft Permanent Connections (SPC) initiated by EMS
Inter-domain Fast provisioning of Switched Connections (SC) over multiple transport network (TN) domains initiated by clients via UNI
Client controlled dynamic SDH leased line Client controlled dynamic Ethernet private line
Fast provisioning of SPC over multiple TN domains initiated by EMSDynamic SDH leased lineDynamic Ethernet private line
Auto discovery between client and TN edge nodes via UNI
10/11/2005 - 19
GEANT2 – NREN/ IST-Projects Interworking Scenarios
The following slides show several interworking scenarios, focusing on lower layer transport capabilities of Geant2
IP transport:IP transport of Geant 2 (and corresponding “IP – IP” interworkingbetween NREN and Geant2) is maintained as of todayenhanced IP services (e.g. IP VPNs) could use / benefit from GMPLS functionalities and/or schemes shown in the following
10/11/2005 - 20
GEANT2 – NREN/ IST-Projects Interworking Scenarios #1
NREN #2IPNREN #1
IP
GEANT 2
SDH or OTN NREN #3Ethernet
NREN #4Ethernet
UNI UNI
UNI UNI
STM-xx STM-xx
GE/10GE GE/10GE
E-NNISTM-xx
To other network domains
Functions: UNI1.0R2/SDH, UNI2.0 Ethernet, E-NNI/SDH
10/11/2005 - 21
GEANT2 – NREN/ IST-Projects interworking scenarios #2
NREN #2SDHNREN #1
SDH
GEANT 2
SDH or OTN NREN #3Ethernet
NREN #4Ethernet
E-NNI
UNI
UNI UNI
STM-xx STM-xx
GE/10GE GE/10GE
E-NNISTM-xx
To other network domains
Appl.
GE/10GEE-NNI
UNI
Appl.GE/10GE
Functions: UNI1.0R2/SDH, UNI2.0 Ethernet, E-NNI/SDH
10/11/2005 - 22
GEANT2 – NREN/ IST-Projects interworking scenarios #3
NREN #2SDHNREN #1
SDH
GEANT 2
SDH or OTN NREN #3Ethernet
NREN #4Ethernet
E-NNI
UNI
E-NNI E-NNI
STM-xx STM-xx
GE/10GE GE/10GE
E-NNISTM-xx
To other network domains
Appl.
GE/10GEE-NNI
UNI
Appl.GE/10GE
UNI
Appl.GE/10GE UNI
Appl.
GE/10GE
Functions: UNI1.0R2/SDH, UNI2.0 Ethernet, E-NNI/SDH + Ethernet(note: Ethernet E-NNI planned as future OIF activity)
10/11/2005 - 23
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerationsMUPBED network realisation
overview and principlesdetails: see back-up slides
MUPBED / standardisationQuestions to NRENsSummary
10/11/2005 - 24
MUPBED Test Bed – Planned Implementation NREN/GEANT2 model covered by this network architecture
GEANT2TILAB
GEANT2DT
E-NNI SDH
NREN#1TID (IP)
NREN#3Acreo (IP)
NREN#2PSNC (Eth.)
UNI2.0 Ethernet
GEGEGEUNI2.0
Ethernet
XC XC
Requirement: (Commercial) availability of UNI-C interface
10/11/2005 - 25
MUPBED Test Bed (Virtual) Inter-domain interconnection based on E-NNI
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
PIONIERNORDUnet
RedIRIS
GARR
DTU
FAU
CSP
GEANT
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
Control plane
E-NNI
10/11/2005 - 26
MUPBED Test Bed – Planned Implementation Real UNI2.0 Ethernet link
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
PIONIERNORDUnet
RedIRIS
GARR
DTU
FAU
CSP
GEANT
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
DP
Control Plane
UNI 2.0 Ethernet
10/11/2005 - 27
Project starting point: Five local test beds, 5 NREN partners, GEANT
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
ACREO
TILAB
Telefonica I+D
T-SystemsDT
PSNC
GEANT
DFN
PIONIER
NORDUnet
RedIRIS
GARR
DTU
FAU
CSP
ASON/GMPLS
ASON/GMPLS
IP/MPLSEthernet
GMPLS
10/11/2005 - 28
Test Bed – Logical Configuration Target
target: full mesh between test bedscurrently: all links are Ethernet point-to-point(with GigE interfaces on both ends)some of them might become in future Layer 1 links
all switching done INSIDE local test beds
DTU
FAU
CSP
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
Marconi MSH64cVC-4 XC
All LR
S1
S3
S13
-P1
S11
-P4
S13
-P2
VC-4 XCAll IO
S1-P
1
S1- P2
S1-P
3
S3
S13
S2
S4 VC-4 XCAll IO
S1-
P1
S1- P2
S1-P
3S1
-P4
S13
-P3
Marconi MSH64c
Marconi MSH2K
10/11/2005 - 29
Marconi MSH64c
= STM-64= GE/SX
VC-4 XC
S10-P
1S1
0-P2
S10 -P
3
S10 -P
4
All LR
S11-P1S11-P2S11-P3
S13 -P4
= STM-16
S13-P
1
S11-
P4
S13-P
2
Marconi MSH64cVC-4 XC
All LR
S1-P3S1-P2
S1-P4
S5
S10-P
1
S10-P
2
S10-P3
S10-P4
S2
Video
= GE/LX
GE
Videoapplication
FAU
PSNCMarconi MSH2k
VC-4 XCAll LR
S1-P
1
S1-P
3
S1-P
4
S11-P
1
S11-P
2
S11-P
3
S11-P
16= STM-1
M2MSH64c
UNI–IP (Client#2)
= STM-64= GE/SX
10.131.12.9
S10-P
1S1
0-P2
S10 -P
3
S10 -P
4
All LR
S11-P1S11-P2S11-P3
-P4
S1
S3
= STM-16
S13-
S13-P3- -
M3 MSH64c
-10.131.12.7All LR
S1-S1-
S1-P2
S1-P4S3
S5
S10-P
1
STM64 ring: Col.1, tem 200 for each LKSTM-16 ring: Col 2, tem 100 for each LK
-P2
S10-P3
S10-P4
S2
S4
E-NNI(TN#1)
I-NNI
VideoE-NNI(TN#2)
= GE/LX
GE
Videoapplication
E-NNI TILAB (only signaling)
FAU
E-NNI ACREO
PSNC
E-NNI VIOLA
M1 MSH2k
All LRS1
-P1
S1-
S1-P
4
S1-P
1
10.131.12.8
Test Bed – Detailed View of Berlin Network
10/11/2005 - 30
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerationsMUPBED network realisationMUPBED / standardisationQuestions to NRENsSummary
10/11/2005 - 31
Multi-layer, integrated DP & CP Solution Mandates cooperation among SDOs and forums
data and control plane functions integration mandatesintegration of function from different SDOs / forums therefore their close cooperation is importante.g. for UNI2.0 Ethernet:
OIF UNI2.0 Ethernet specificationITU-T set of ASON Rec.ITU-T set of NG-SDH Rec. ITU-T set of Ethernet service Rec.MEF Ethernet service specificationsIEEE set of Ethernet standardsIETF signaling standards
10/11/2005 - 32
OIF World Interoperability Tests 2005
UNI: User Network InterfaceI-NNI: Internal Network to Network InterfaceE-NNI: External Network to Network InterfaceMSPP: Multi-Service-Provisioning-Platform
Client network
A
Client network
C
Client network
D
Client network
B
UNI
Carrierdomain
E-NNII-NNI
I-NNI
UNI2.0 Ethernet
UNI2.0 Ethernet
Opticalnetwork
B
Opticalnetwork
A
Client network
F
Client network
E
MSPP
MSPP
Test network architecture
www.oiforum.com/public/supercomm_2005v1.html
10/11/2005 - 33
2005 OIF Demonstration: Control Plane
Carrier CDomain
OIF UNI OIF E-NNI OIF UNI
Carrier ADomain
Carrier BDomain
OIF E-NNINE NE NE NE
EthernetClient
EthernetClient
Ethernet Layer Call/Connection Flow
SONET/SDH Layer Call/Connection Flow
UNI-N UNI-N UNI-CUNI-C
Ethernet Ethernet
SDH
Combining Optical Control Plane with Ethernet Services
Major innovations demonstrated:OIF UNI 2.0 support for Ethernet clientsOIF UNI 2.0 call control based on ASON
UNI-N devices integrate multi-layer functions of the control plane
The clients and the remainder of the carrier network are not impacted, since they are only concerned with one layer
NE NE
www.oiforum.com/public/supercomm_2005v1.html
10/11/2005 - 34
2005 OIF Demonstration: Global Topology
USA Europe Asia
NTT
Verizon
DeutscheTelekom
AT&T
AviciFujitsu
Sycamore
CienaHuawei
AviciMarconi
Sycamore
AviciCisco
MarconiHuawei
Lambda OS
AlcatelCienaCisco
MarconiLucent
AviciCienaCisco
AlcatelCienaCisco
FujitsuLucentMahi
NortelSycamore
Tellabs
FranceTelecom
TelecomItalia
ChinaTelecom
www.oiforum.com/public/supercomm_2005v1.html
10/11/2005 - 35
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerationsMUPBED network realisationMUPBED / standardisationQuestions to NRENsSummary
10/11/2005 - 36
Questions to NRENs / Interest of MUPBED
roles / issues of NRENs and Geant2:feedback to described scenarios in this presentationextensions / further issues / …
further information on state of today AND future evolution:traffic (e.g. volume, distribution, behaviour)services (e.g. types, requirements, relevance, penetration)technology (circuit layer, packet layer, network control)
currently on-going update on network information:NRENs / Geant2status today and migration plansone target: classification of network types and interworking issuesrequest: cross-check and completion of gathered information
10/11/2005 - 37
NREN Information Gathering for MUPBED
Problem: many parameters, many different “flavours”Approach: simplifying classification proposalDistinction between “circuit layer” and “packet/data layer”Categories:
Each layer has a ‘type’ and a ‘level’ associated with itType is:
Level:
Combine these to categorise circuit and packet layers
Categories: Type 1 Type 2 Type 3circuit WDM + ethernWDM + TDM + ethernet TDM + ethernetdata / packet ethernet ethernet + L2VPN / VLAN ethernet + L2VPN/VLAN
Level A Level B Level CStatic Dynamic Centrally Dynamic DistributedOSPF OSPF + i/eBGP
10/11/2005 - 38
End User Connectivity Offered QoS Offered Services Dynamic bandwidth Service Control Plane Management Plane
No direct end user connectivity offered at this layer N/A None None now, planned GMPLS Static Manual10/100/1000 ethernet MPLS, diffserv VLAN Access Perhaps implied by MPLS use OSPF, iMBGP, eMBGP Unknown
Category Name
MUPBED Architecture
PlaneOverall Architecture type Topology Type
1A Ceznet2 Circuit Ethernet over Optical Ring / hub / star3B Packet MPLS TE + VPN's
Categorising an NREN
Example CZnet:
Categories: Type 1 Type 2 Type 3circuit WDM + ethernWDM + TDM + ethernet TDM + ethernetdata / packet ethernet ethernet + L2VPN / VLAN ethernet + L2VPN/VLAN
Level A Level B Level CStatic Dynamic Centrally Dynamic DistributedOSPF OSPF + i/eBGP
10/11/2005 - 39
OverviewResearch Network Infrastructure Project MUPBED
IST project MUPBED: overviewArchitectural considerationsMUPBED network realisationMUPBED / standardisationQuestions to NRENsSummary and conclusions
10/11/2005 - 40
Summary and Conclusions
IST project MUPBED:reflects the current and assumed future heterogeneous (research)network environment in Europe and worldwideis a European scale test network, based on multiple network domains with different architectures, technologies and functionsassesses the main ‘horizontal’ and ‘vertical’ interworking areasaims at pragmatic solutions for inter-working
Progress in standardisation on-going
MUPBED continuously aims at establishing and maintaininga close co-operation to NRENs / GN2
mutual exchange of achievements / issues / work plansopen for further discussions
10/11/2005 - 41
Further Information: www.ist-mupbed.org
Marconi Communications GmbH
Gerberstraße 33D-71522 Backnang
Germany
www.marconi.de
Phone +49 (0) 7191 13-2427Mobile +49 (0) 171 379 6503Fax +49 (0) 7191 13-62427E-Mail [email protected]
Jan SpäthDirector Network Evolution
10/11/2005 - 42
BACKUP Slides – Overview
MUPBED network realisation detailsMUPBED application related activities (Work Package 2)Further inter-working issues
10/11/2005 - 43
Test Bed Interconnection – Approach
MUPBED follows a step-wise approach:initial step: connectivity on IP layercurrent step: full mesh of test beds on layer 2 (Ethernet VLANs)
achieved by LSPs within NRENs and DANTE networksthis step required the solution of technical and political issues
last mile interconnection between test beds and NREN PoPslegal issues for using fibres for such a “permanent, non-commercial” activitylegal issues for accessing NRENs from “private bodies”technical issues for LSP stitching, VLAN realisation
future step: selected interconnections on layer 1realistic technology: SDH VC-4 interconnectionpotentially only between selected test beds and/or temporarily
10/11/2005 - 44
Test Bed Interconnections – “Transparent Layer 2 Tunnels”
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
PIONIERNORDUnet
RedIRIS
GARR
DTU
FAU
CSP
GEANT
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
10/11/2005 - 45
Test Bed Interconnections: LSPs and VLANs
Example for realisation in one test bed:
TB #1
GE
LSPs inGEANT
TB #2
TB #3
TB #4 ASP #x
Test bed #5
LSPs in NRENsnetwork
VLANsaccess
link
TB: Test bedASP: Application service provider
LSP VLAN
router router router switch
LSPEthernet flow
10/11/2005 - 46
MUPBED Test Bed Interconnections
TB #1
Layer2 connections
TB #2
TB #3
TB #4
ASP #x
Test bed #5
VLAN portswitching structure
ASON/GMPLS network
TB #1
TB #2
TB #3
TB #4
ASP #x Marconi MSH64cVC-4 XC
All LR
S1
S3
S13
-P1
S11
-P4
S13
-P2
VC-4 XCAll IO
S1-P
1
S1- P2
S1-P
3
S3
S13
S2
S4 VC-4 XCAll IO
S1-
P1
S1- P2
S1-P
3S1
-P4
S13
-P3
Marconi MSH64c
Marconi MSH2K
TB #1
TB #2
TB #3
TB #4
ASP #x
GE
VLAN
VLAN resolution
VLAN translation
switch
Dynamic VLAN cross connection
any-to-any
10/11/2005 - 47
BACKUP Slides – Overview
MUPBED network realisation detailsMUPBED application related activities (Work Package 2)Further inter-working issues
http://www.ist-mupbed.org/
Multi-Partner European Test Beds for Research Networking
MUPBED – WP 2 Overview
Henrik Wessing (DTU)
Work Package 2 – Application and information technology platform integration
10/11/2005 - 49
Outline
Work Package 2Partners within WP2Objectives of WP2Activities of WP2
ApplicationsApplication requirementsPreparation of lab facilities
ModellingIdentification of level of dynamicity
Application network interface discussionReceiving resource requestsTranslation of requestsAdvance reservation emulation
10/11/2005 - 50
WP2 partners (with MM in WP2)
Equipment ManufacturersJuniper Networks (Ireland)
Network OperatorsTelecom Italia – TILAB (Italy)Telefonica I+D (Spain)
Research CentresAcreo (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)
10/11/2005 - 51
Original WP2 objectives
To define for the MUPBED applications how the resource requests are translated to network understandable QoS parameters.To define the required level of dynamics of the resource allocation with respect to performance, stability and other network administrative issues.To determine the scalability of the MUPBED concept for differentapplication groupsTo verify the advantages and drawbacks of a dynamic infrastructure To strengthen and enhance the contact and collaboration with user communities.To increase a common understanding from user groups, through NREN to service providers of what layer is responsible for what.
10/11/2005 - 52
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 groupsProfessional user groups and sub contractorsResearch and development user groupsGroups within and outside the MUPBED consortium
ModellingSimulations to identify the minimum application burst time where an LSP setup is beneficial.
Application network interfaceAPI based interfaceTranslation of application requirements to network parametersTriggering of resource allocationsInterfacing to packet and circuit layer.
10/11/2005 - 53
HQ uncompressed video transmission – Requirements
For remote studio with online editingDelay < 150 msEach camera:
BW: 300-600 Mbit/sJitter should be low (< 1ms)
10/11/2005 - 54
HQ uncompressed video transmission – lab setup
ConnectivityEquipmentJitter measurements
Uncompressed VLC MPEG-2
10/11/2005 - 55
Grid computing and VO - Requirements
Grid computing – generic requirements
From Kbit/s to Tbit/sDiverse delay requirements
Virtual OrganisationsRemote signature and compression functionsBW and QoS dependent on user patienceRequire exact provisioning to take advantage of dynamicitySecurity 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 NetworkOptical Network
MUPBEDNetwork
10/11/2005 - 56
Grid computing and VO – Lab scenarios
Lab. L_040 (I484)Content e Storage Networking
Lab. L_037 (CM2)GRID Networking
Centro Stella Pal. I (I0445)
CAT3750L009-1(cis17165)
172.16.220.6
CAT3750L009-1(cis17165)
172.16.220.6
CAT3750L009-2(cis17164)
172.16.220.7
CAT3750L009-2(cis17164)
172.16.220.7
CAT 6500VAJOLET(cis7842)
CAT 6500VAJOLET(cis7842)
CAT2924CSI(cis8483)
172.16.220.4
CAT2924CSI(cis8483)
172.16.220.4
OADM OADM
OADMOADM
Lab. L_xxx (XXX)Videocomunicazione
Centro Stella V. Borgaro
OPTERA Metro
Cat3524Borgaro
(cis12490)172.16.220.8
Cat3524Borgaro
(cis12490)172.16.220.8
OPTERAMetro
Lab. L_009 Reti ottiche
B2022 B2023 B2024/5
IP/MPLS
ASON/GMPLS
VLAN 222 VLAN 221
VLAN 134
VLAN 221 VLAN 222
TILAB LAN(cis9431)
(6506-CORE-A)
L40_3550Gb(cis15358)
163.162.61.4
L40_3550Gb(cis15358)
163.162.61.4
VLAN 221
VLAN 222
L40_3550 (cis15359)
163.162.61.3 L40_3550 (cis15359)
163.162.61.3
Multi mode fiber or i/fSingle mode fiber or i/fUTP cable or i/f Fiber/UTP converter i/f slot / port xx/yy
Multi mode fiber or i/fSingle mode fiber or i/fUTP cable or i/f Fiber/UTP converter i/f slot / port xx/yy
CAT3508CSI(cis8480)
172.16.220.5
CAT3508CSI(cis8480)
172.16.220.5
0/27
ServerZIP
WEB/Portal Server
ServerMD5
VLAN 222
VLAN 221
Client
10/11/2005 - 57
Video conferencing - Requirements
Point to point HQ video conferencingPerson to person communicationHigh qualityAudio: 1.5 Mbit/sVideo: 20 Mbit/s (depending on codecs)
Multipoint conferencingLatency less than 40-50 msMax skew of 80 msVideo pr. client: 11 Mbit/sAudio pr. client: 1.4 Mbit/sClients across MUPBED infrastructure
10/11/2005 - 58
Point to point video conferencing setup
Demonstrated internally at Torino meeting
10/11/2005 - 59
Multipoint video conferencing setup1. 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
Streaming m
(1)
Sign
alli n
g m
(4)
m(3
)m
(1)
Signalling m
(4)m(2)
m(3)
Stre
ami n
g m
( 2)
Signalling m(4)
Streaming m
(3)m
(2)m
(1)
Shared-treeSource-tree
10/11/2005 - 60
Content – and storage - Requirements
Backup and restore serviceDistance from data center 50-100 kmBackup time of 1-5 min for 1 TB dataBandwidth:
120 Mbit/s for backup600 Mbit/s for restore
Dynamic BW requiredSecurity as data sensitive
VoD streamingCDN and E2E investigatedCDN: 100 Mbit/sE2E: 50 Mbit/sRequirements for latency, jitter and packet loss
10/11/2005 - 61
Content – and storage – Lab setup
Backup and restore logical scenario
ClientSite
Optical NetworkOptical Network
MPLS/IP
Control Framework
QoS
IP/ OpticalBackbone
CDNCache
CDNCache
ServerSite
VoD logical scenario
ClientSite
Optical NetworkOptical Network
MPLS/IP
Control Framework
QoS
Storage Area Network
Fibre Channel/iSCSI
applicationservers
storage
LAN
Server Site
IP/ OpticalBackbone
10/11/2005 - 62
Open Media StreamingEvaluating Free OMSP distribution
Server: FenicePlayer: NemesiWeb based scheduling: Palinsesto
BW from 128 Kbit/s to 1 Mbit/sAllows up to 70 clients in MUPBED setup: 490 Mbit/s in total
10/11/2005 - 63
Peer to peer communication problemProblem of peer to peer communication when:
Peer are on same LANThey wish to use different ISP
In collaboration with KTH in StockholmProblems discovered in typical network architectures
VLAN ring architectureVLAN Policy based routing and a control stationPure IP layer 3 equipment
Solution to investigate: MPLS-IX to interconnect several MANsAllows local traffic to stay localUser can choose ISP of their choiceEasy adaptable solution
10/11/2005 - 64
Modelling – Objectives and scenarios
Objective:Support analysis of the experimental findingsInvestigate application and dynamic scalabilityHelp setting up fruitful experiments
Scenarios:Reference IP scenario for aligning results with experimental data and for application modellingStatic LSP implementation to identify potential performance gainInterface performance evaluation
Static LSP scenario
10/11/2005 - 65
Modelling – Implementation and preliminary findings
Preliminary implementation in OPNETRSVP signalling for LSP setup and for application quite differentReflecting the common way of thinking!
Telcos transporting bitsUG: Don’t care about networksThis is a challenge!
First simulation objective:How long should a burst be before a path setup is beneficial for specific applications
10/11/2005 - 66
Communicating with the network control (I)
10/11/2005 - 67
Communicating with the network control (II)
Mapping applications into service classes with similar network requirements
GRID middleware considered as an application
Application interfaceAPIBased on web service and SOAP for platform independent communication
Translation of requirements From fuzzy application requirements to hard network parametersComplete decoupling between the resource request and the applicationSee example figure for grid applications
10/11/2005 - 68
Communicating with the network control (II)
Resource allocation Advance reservations not supported
A path is established only at the beginning of the reservation timeNo acknowledge before then
Algorithm for registering and reservationReceiving resource requestIf resources in packet layer available register reservation If resources not available allocate resources in the circuit layerIntelligent over provisioning and local control to emulate advance reservation
Network interfaceRSVP interface at the packet layerOIF UNI interface at the circuit layer
10/11/2005 - 69
BACKUP Slides – Overview
MUPBED network realisation detailsMUPBED application related activities (Work Package 2)Further inter-working issues
10/11/2005 - 70
Interoperability Areas within the MUPBED Network
ASON/GMPLS
IP/MPLS
Interaction betweenApplications and
Network
Interoperability between Network Domains
Network Domain 1
ASON
IP/MPLS
Network Domain 2
GMPLS
IP/MPLS
Network Domain N
Applicationplatforms
End-users/Applications
MultiserviceNetwork
Interworking between IP/MPLS
and ASON/GMPLS
10/11/2005 - 71
MUPBED Test Bed Inter-domain interfaces: Current implementations
MUPBED is based on five different test bed domains, which will be integrated to a European scale test bed To realize interworking functions among these local test beds,inter-domain signaling/routing interfaces are strongly neededFirst inter-test bed / inter-domain interface implementation:
Virtual E-NNI between Torino/TILAB – Berlin/DTNext step: Real UNI2.0 Ethernet implementation
Torino/TILAB – Berlin/DTData plane: MUPBED’s Layer 2 connectionControl plane: IPSEC tunnel over public Internet
10/11/2005 - 72
MUPBED Test Bed (Virtual) Inter-domain interconnection based on E-NNI
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
PIONIERNORDUnet
RedIRIS
GARR
DTU
FAU
CSP
GEANT
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
CP
E-NNI
10/11/2005 - 73
MUPBED Test Bed – Planned Implementation Real UNI2.0 Ethernet link
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
PIONIERNORDUnet
RedIRIS
GARR
DTU
FAU
CSP
GEANT
ACREO
TelefonicaI+D
TITILAB
T-SystemsDT
PSNC
DP
CP
UNI 2.0 Ethernet
10/11/2005 - 74
MUPBED Test Bed – Planned ImplementationInter-domain interfaces
Northern Europetest bed
Central Europetest bed
Western Europetest bed
Southern Europetest bed
Eastern Europetest bed
DFN
GEANT
ACREO
TelefonicaI+D
TILAB
DT
PSNC
GE
GE
GE
GE
GE
E-NNI (SDH)
CP
UNI 2.0 Ethernet
UNI 2.0 Ethernet
CP
UNI-C
UNI-C
UNI-N
UNI-N
UNI-NCP CP
DP
UNI 2.0 Ethernet
router
router
UNI-C
XC
XC
Switch
Appl.
DTU
UNI-C
UNI 2.0 Ethernet
10/11/2005 - 75
MUPBED Test Bed – Planned Implementation NREN/GEANT2 model covered by this network architecture
GEANT2TILAB
GEANT2DTE-NNI
SDH
NREN#1TID (IP)
NREN#3Acreo (IP)
NREN#2PSNC (Eth.)
UNI2.0 Ethernet GEGE
GEUNI2.0 Ethernet
XC XC
Requirement: (Commercial) availability of UNI-C interface
10/11/2005 - 76
MUPBED Test Bed Inter-domain interworking: Requirements
UNI-C 2.0 Ethernet interface availability:easy availability and access of this UNI-C function is mandatory for accelerating the deployment of customer controlled Ethernet services over SDH networksrequirements for broad acceptance:
(publicly) available and easy to implement easy to use for those envisaged (network) clients, for which thecomplexity of network operation shall be hidden
Interworking between ASON-GMPLS network domainsseamless interworking between domains following different architectures required by network operatorspragmatic solutions neededfirst implementations reportedstandardisation progress needed
10/11/2005 - 77
Interoperability Areas within the MUPBED Network
ASON/GMPLS
IP/MPLS
Interaction betweenApplications and
Network
Interoperability between Network Domains
Network Domain 1
ASON
IP/MPLS
Network Domain 2
GMPLS
IP/MPLS
Network Domain N
Applicationplatforms
End-users/Applications
MultiserviceNetwork
Interworking between IP/MPLS
and ASON/GMPLS
10/11/2005 - 78
Interworking IP/MPLS – GMPLSBasic questions:
is a common framework / protocol set reasonable for completely different technologies (“optical circuits” and “electronic packets”) for core/metro networks?
overall optimisation versus sub-optimal solution for each areamight be much more complex than two different solutionsconsider also the different “time domains” in the different layers
do all operators want to combine these “worlds”?operational / structural / technical reasons for “separate worlds”
Other issues:new features of GMPLS (compared to MPLS), such as:bi-directional LSPs, label suggestion, label restriction, graceful restart, gracefulteardown, forwarding adjacenciesdifferences between MPLS and GMPLS for several features:local protection, routing, signallingGMPLS has separation of data and control plane, MPLS does not
Potential solution(s):UNI or a kind of E-NNI between the layersMPLS could also learn some things from GMPLS (e.g. bi-directional paths)
10/11/2005 - 79
Management AspectsMPLS has a management plane – driven by operator actions, as well as a control plane – driven by signalling
Still relatively immature, e.g. in terms of planning tools and OAM featuresEasier therefore to deploy MPLS in core networks rather than edge, where scalability and feature richness become issues
GMPLS management plane is likely to stay separate for a while –operators demand high stability in their optical backbone
Optical Transport Network (OTN) emerging for carrier’s carrier and other payload-independent transport applications
Today carry up to 10 Gbit/s in SDH or Ethernet formatMonitor digital quality of wavelengths at handover between operators
Increasingly integrated with SDH at both hardware and managementlevels
10/11/2005 - 80
Interoperability Areas within the MUPBED Network
ASON/GMPLS
IP/MPLS
Interaction betweenApplications and
Network
Interoperability between Network Domains
Network Domain 1
ASON
IP/MPLS
Network Domain 2
GMPLS
IP/MPLS
Network Domain N
Applicationplatforms
End-users/Applications
MultiserviceNetwork
Interworking between IP/MPLS
and ASON/GMPLS
10/11/2005 - 81
Application-Network Interface
Options for the application-network interfaceAPIUCLPBandwidth Management PointParlay/OSAWeb Services…
Example solution (based on Web Services):Client Network nodeApplication-network-interface
Application
Network Service Requester
(WebServices)
Network Service Provider
(WebServices)
UNI-C
UNI-N
RSVP-TERequirements translation
Standard interface
NMS
10/11/2005 - 82
Application RequirementsExamples investigated within MUPBED
Video conferencingPoint to point and multipoint conferencing consideredLatencies less than 40-50 msVideo: ~20 Mbit/s depending on codecAudio: 1.5 Mbit/s
High Quality video transmissionRemote studios with online and real-time editingDelay < 150 ms with jitter < 1 ms300-600 Mbit/s for each camera (~1.5 Gbit/s for HDTV)
Content and storage applicationsAssuming data center within 50 to 100 km.Backup bandwidth: 120 Mbit/sRestore bandwidth: 600 Mbit/s
GridRequirements range from Kbit/s to Tbit/sDiverse delay requirementsVirtual Organisation chosen as representativeSecurity, high bandwidth and fast provisioning essential
10/11/2005 - 83
Application-Network Interface – Specification
Mapping of application into service classesGroups are treated similarly with respect to bandwidth, delay, protection etc.
Translation of “fuzzy” application parameters to network parametersNetwork Service Requester:
Request resources through RSVP signalling, API, UNI or web services
Network Service ProviderRespond to NSR request
Example Spec see next slide
10/11/2005 - 84
Application-Network Interface – Spec Example
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
10/11/2005 - 85
Application Network Interface – Ongoing Work
Two working streams within MUPBED:1. Specification of interface
Overall specification of application side of interfaceSurveying technologiesDefinition of the communication channel between the applications and the network control
2. Implementation of light versionSpecification of a minimum functionality interfaceImplementation as web services, API, ...Used for demonstration purposes