Research Network Infrastructure Project “MUPBED”: …Research Network Infrastructure Project...

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


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


IP/MPLS

Ethernet Native Ethernet

NG – SDH

OTN


GEANT 2NREN

10/11/2005 - 14


IP/MPLS

SDH

Native Ethernet

NG – SDH

OTN


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


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


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


NREN #4Ethernet

E-NNI

UNI

UNI UNI

STM-xx STM-xx

GE/10GE GE/10GE

E-NNISTM-xx


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


NREN #4Ethernet

E-NNI

UNI

E-NNI E-NNI

STM-xx STM-xx

GE/10GE GE/10GE

E-NNISTM-xx


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


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




Southern 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






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






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



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


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


10/11/2005 - 35



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


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”






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



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



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


MPLS/IP

Control Framework

QoS

IP/ OpticalBackbone

CDNCache

CDNCache

ServerSite

VoD logical scenario

ClientSite


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



10/11/2005 - 70


ASON/GMPLS

IP/MPLS


Network


Network Domain 1

ASON

IP/MPLS

Network Domain 2

GMPLS

IP/MPLS

Network Domain N



MultiserviceNetwork


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






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






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






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


ASON/GMPLS

IP/MPLS


Network


Network Domain 1

ASON

IP/MPLS

Network Domain 2

GMPLS

IP/MPLS

Network Domain N



MultiserviceNetwork


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


ASON/GMPLS

IP/MPLS


Network


Network Domain 1

ASON

IP/MPLS

Network Domain 2

GMPLS

IP/MPLS

Network Domain N



MultiserviceNetwork


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

Research Network Infrastructure Project “MUPBED”: …Research Network Infrastructure Project...

Documents

Transcript of Research Network Infrastructure Project “MUPBED”: …Research Network Infrastructure Project...