Deliverable D3.1 Test Bed Overview - Nobel 2

Instrument type: Integrated Project 

Proposal No. IST-511780 

MUPPET 

Multi-Partner European Test Beds for Research Networks 

Priority name: Information Society Technologies 

Deliverable D3.1 

Test Bed Overview 

Due date of deliverable: September 30, 2004 

Actual submission date: October 01, 2004 

Start date of project: July 1, 2004 Duration: 36 months 

Lead contractor for this deliverable: 

T-Systems/Deutsche Telekom 

Revision 1 

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006) 

Dissemination Level 

PU Public X 

PP Restricted to other programme participants (including the Commission Services) 

RE Restricted to a group specified by the consortium (including the Commission Services) 

CO Confidential, only for members of the consortium (including the Commission Services)

IST – Integrated Project MUPPET 

Multi-Partner European Test Beds for Research Networking 

Abstract 

Page 2 of 68 

File: 

MUPPET_D31_TestBedOverview_Sep04 

In this deliverable the overall design, the actual status, the functions provided to the MUPPET project 

and the interfaces/functions for the inter-test bed connections of the Southern-, Central-, Northern-, 

Western- and Eastern European local test beds are preliminary described. Furthermore a description of 

the network functions, interface functions and local PoPs of the involved NRENs are included. Last 

but not least, the MUPPET partners, who will provide applications and are located remotely from the 

five local test beds, have added their requirements to the transport network and a description of the 

local NREN PoPs to be used in MUPPET. With this information, including the views of all 

networking participants, a first picture of the local test beds and their interconnections is completed. 

Additionally to these strictly to the MUPPET project related topics, this deliverable includes a 

summary of the participation of three MUPPET partners (Marconi ONDATA and Marconi SpA, 

TILAB, T-Systems/Deutsche Telekom) at the OIF World Interoperability Tests and Demonstrations 

at SuperComm 2004, as a pre-project work, which was an excellent starting point for project 

MUPPET. 

In the following a short summary of the five tests bed descriptions and their interconnections is given: 

Local test beds summary: 

1. Southern Europe test bed: Is composed of ASON/GMPLS transport networks domains, optical 

transparent and SDH based, and an IP/MPLS domain interconnected by control plane interfaces 

E-NNI and UNI, respectively. Additional E-NNI connections will be established to the 

TILAB/NOBEL network domain. To all these network domains the following application labs 

will be connected: Grid Node, SAN Lab and Video Communication Lab 

2. Central Europe test bed: Is an ASON/GMPLS network domain, interconnected to the 

GSN+Demonstrator domains via UNI and E-NNI control plane interfaces. Broadband 

video/HDTV applications are used for visualising the network functions 

3. Northern Europe test bed: The Acreo National Broadband Test bed is build according to the 

GMPLS architecture, including control of multiple layers (IP/Ethernet/Optical Layer) by means of 

one common control plane 

4. Western Europe test bed: The TID test bed is an IP/MPLS network, which is composed of Layer- 

2 switches and IP routers. 

5. Eastern Europe test bed: The PSNC test bed is a broadband Ethernet network (GE and 10GE 

links) over a WDM transport infrastructure, following a low-overhead architecture for multigigabit 

networks. 

Test bed interconnections summary: 

1. Southern Europe test bed - GARR: Short-term interconnection via ATM link possible, the final 

goal is a dark fibre interconnection. Furthermore there is a control plane E-NNI interconnection 

based on an IPSEC tunnel between Southern Europe – Central Europe test bed up running since 

April 2004, the OIF World Interoperability Tests and Demonstration were performed 

2. Central Europe test bed - DFN: Short-term interconnection via Ethernet link (fixed data volume). 

A dark fibre interconnection is currently under investigation. Today the E-NNI control plane 

connection to the Southern Europe test bed is the only test bed interconnection being in use 

3. Northern Europe test bed - NORDUNet: The connectivity through the Nordic NRENs 

(SUNET/NORDUNET) to GEANT is still an issue to be solved. 

4. Western Europe test bed - RedIRIS: Already interconnected via an ATM link (PVC 34 Mbit/s) 

5. Eastern Europe test bed - PIONIER: This interconnection will be set up using a dedicated 

Ethernet link or VLAN with guaranteed bandwidth



Page 3 of 68 

File: 


6. NRENs – GEANT: All the four NREN hosting the links to the MUPPET test bed, i.e. RedIRIS in 

Spain, GARR in Italy, DFN in Germany, PSNC in Poland, NORDUNet for the Nordic countries, 

are connected at 10 Gbit/s to GÉANT, ensuring that testing at high speed can be planned in a near 

future. The successor of GÉANT will offer even greater link speed and richer services, in 

particular in term of provisioning time and level of automatism. 

This first resume shows clearly, that the integration of these different kinds of test beds over different 

NREN networks and GEANT to an overall European test bed will need considerable efforts, close 

cooperation and pragmatic solutions.



Document Information 

Page 4 of 68 

File: 


Status and Version: Version 1.00, final 

Date of Issue: 01.10.2004 

Dissemination level: Public 

Author(s): 

Main author Hans-Martin Foisel T-Systems 

Labs Loa Andersson ACREO 

Javier Hurtado TID 

Isidro Cabello Medina TID 

Jesus Felipe Lobo Poyo TID 

Giovanni Carones TILAB 

Carlo Cavazzoni TILAB 

Marco Vitale TILAB 

Pino Castrogiovanni TILAB 

Marzio Alessi TILAB 

Giovanni Carones TILAB 

Roberto Morro TILAB 

Michal Przybylski PSNC 

Christoph Gerlach T-Systems 

Fritz Joachim Westphal T-Systems 

NRENs Juergen Rauschenbach DFN 

Mauro.Campanella GARR 

Miguel Angel Sotos RedIRIS 

Vendor Jan Spaeth ONDATA 

Piergiorgio Sessarego MCSPA 

Appl. provider Lars Dittmann DTU 

Henrik Wessing DTU 

Rodolfo Baroso CSP 

Valentina Bruno CSP 

Peter Holleczek FAU 

Susanne Naegele-Jackson FAU 

Approved by: Jan Spaeth Project co-ordinator



Table of Contents 

Page 5 of 68 

File: 


Abstract..................................................................................................................................................1 

Document Information .........................................................................................................................4 

Table of Contents ..................................................................................................................................5 

1 Introduction.....................................................................................................................................7 

1.1 Purpose and Scope.................................................................................................................7 

1.2 Reference Material.................................................................................................................7 

1.2.1 Reference Documents.......................................................................................................7 

1.2.2 Acronyms and Abbreviations ...........................................................................................8 

1.3 Document History................................................................................................................10 

1.4 Document overview.............................................................................................................10 

2 Optical Internetworking Forum: World Interoperability Tests and Demonstration at 

SuperComm 2004 –Participation of MUPPET partners.................................................................11 

2.1 Introduction..........................................................................................................................11 

2.2 Overall test description ........................................................................................................11 

2.3 Ethernet over SDH/SONET adaptation interoperability tests..............................................15 

2.4 Example of local lab tests ....................................................................................................16 

2.5 Configuration of Test bed Environments at TILAB and DT's labs .....................................16 

3 MUPPET test bed descriptions....................................................................................................18 

3.1 Southern Europe test bed .....................................................................................................19 

3.1.1 The TILAB Networking Test Bed..................................................................................19 

3.1.1.1 IP/MPLS layer ........................................................................................................19 

3.1.1.2 ASON/GMPLS layer ..............................................................................................20 

3.1.1.3 NOBEL Domain (IP/MPLS and ASON/GMPLS Layers)......................................23 

3.1.2 The TILAB Grid Node ...................................................................................................24 

3.1.3 The TILAB Video Communication Lab.........................................................................28 

3.1.4 The TILAB SAN Lab .....................................................................................................30 

3.1.4.1 Physical Location and Connection to the Project’s resources ................................30 

3.1.4.2 Architecture ............................................................................................................30 

3.1.4.3 CDN Architecture...................................................................................................31 

3.1.4.4 TILAB SAN Lab Components ...............................................................................31 

3.1.4.5 SAN LAB Developments .......................................................................................33 

3.1.5 CSP .................................................................................................................................33 

3.2 Central Europe test bed........................................................................................................35 

3.2.1 FAU ................................................................................................................................37 

3.3 Northern Europe test bed .....................................................................................................41 

3.3.1 Background.....................................................................................................................41 

3.3.2 Test bed description........................................................................................................41 

3.3.3 Architecture ....................................................................................................................42 

3.3.4 Networking technologies................................................................................................42 

3.3.5 Control plane ..................................................................................................................43 

3.3.6 Data plane.......................................................................................................................43 

3.3.7 Context............................................................................................................................44



Page 6 of 68 

File: 


3.3.8 Interconnections..............................................................................................................44 

3.3.8.1 Local NRENs..........................................................................................................44 

3.3.8.2 Control Plane ..........................................................................................................44 

3.3.8.3 Data plane ...............................................................................................................44 

3.3.9 Possible test/demos.........................................................................................................44 

3.4 

3.3.10 Future..............................................................................................................................45 

3.3.11 DTU................................................................................................................................45 

Western Europe test bed ......................................................................................................46 

3.5 Eastern Europe test bed........................................................................................................49 

3.5.1 Eastern Europe test bed phase 1 .....................................................................................49 

3.5.2 Eastern Europe test bed phase 2 .....................................................................................50 

4 Test bed interconnections.............................................................................................................51 

4.1 Southern Europe test bed - GARR.......................................................................................52 

4.1.1 Southern Europe test bed access points ..........................................................................52 

4.1.2 GARR .............................................................................................................................53 

4.2 Central Europe test bed - DFN.............................................................................................55 

4.2.1 Central Europe test bed access points.............................................................................55 

4.2.2 DFN ................................................................................................................................56 

4.3 Northern Europe test bed - NORDUnet...............................................................................58 

4.3.1 Northern Europe test bed access points ..........................................................................58 

4.3.2 NORDUnet .....................................................................................................................59 

4.4 Western Europe test bed - RedIRIS .....................................................................................59 

4.4.1 Western Europe test bed access points ...........................................................................61 

4.4.2 RedIRIS ..........................................................................................................................61 

4.4.2.1 Capabilities available for MUPPET........................................................................63 

4.4.2.2 Description of the POP to be used by TID test bed ................................................63 

4.5 Eastern Europe test bed - PIONIER.....................................................................................65 

4.6 GEANT................................................................................................................................66 

4.6.1 The GÉANT network .....................................................................................................66 

4.6.2 Capability of transport network functions available for MUPPET ................................67 

5 Conclusion .....................................................................................................................................68



1 Introduction 

1.1 Purpose and Scope 

Page 7 of 68 

File: 


There are two objectives this deliverable is aiming at: 

• Giving a first comprehensive description of the overall design, the actual status and the functions 

provided to the MUPPET project and the interfaces/functions for the inter-test bed connections of 

the Southern-, Central-, Northern-, Western- and Eastern European local test beds 

• Giving a first description of the potential test bed interconnections (and the application sites 

related to these), including the network functions provided by the NRENs and GEANT 

Therefore this deliverable will build the bases for the next activities concerning the integration of the 

local test beds to the European scale MUPPET test bed, for the architectural investigations and for the 

practical implementation of the test bed interconnections and integration. 

1.2 Reference Material 

1.2.1 Reference Documents 

[1] ITU-T/ASON: www.itu.int/ITU-T 

[2] IETF/GMPLS: www.ietf.org 

[3] OIF: www.oiforum.com 

[4] H.-M. Foisel, ECOC2004, “Optical Internetworking Forum: World Interoperability Tests 

and Demonstrations”, post deadline paper Th4.5.2 

[5] OIF-UNI 1.0 Release 2, “OIF-UNI-01.0-R2-Common - User Network Interface (UNI) 1.0 

Signalling Specification, Release 2: Common Part” and “OIF-UNI-01.0-R2-RSVP - RSVP 

Extensions for User Network Interface (UNI) 1.0 Signalling, Release 2” 

[6] OIF E-NNI 1.0 Signalling, “OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI Signalling 

Specification” 

[7] ITU-T G.8080/Y.1304, “Architecture for the Automatically Switched Optical Network 

(ASON)” 

[8] ITU-T G.7713, “Distributed Call And Connection Management (DCM)”. 

ITU-T G.7713.1, “Distributed Call and Connection Management (DCM) based on PNNI”. 

ITU-T G.7713.2, “Distributed Call and Connection Management: Signalling mechanism 

using GMPLS RSVP-TE”. 

ITU-T G.7713.3, “Distributed Call and Connection Management: Signalling mechanism 

using GMPLS CR-LDP” 

[9] ITU-T G.7715, “Architecture and Requirements for Routing in the Automatic Switched 

Optical Networks”. 

ITU-T G.7715.1, “ASON Routing Architecture and Requirements for Link State Protocols” 

[10] ITU-T G.7041, “Generic Framing Procedure (GFP)” 

[11] ITU-T G.806, “Characteristics of Transport Equipment – Description Methodology and 

Generic Functionality” 

[12] ITU-T G.707, “Network Node Interface for the Synchronous Digital Hierarchy (SDH)” 

[13] ITU-T G.783, “Characteristics of Synchronous Digital Hierarchy (SDH) Equipment 

Functional Blocks” 

[14] ITU-T G.7042, “Link Capacity Adjustment Scheme (LCAS)” 

[15] ITU-T G.709, “Interfaces for the Optical Transport Network (OTN)” 

[16] Clear Pond: www.clearpondtech.com



Page 8 of 68 

File: 


[17] VIOLA, a German national scale test network: www.viola-testbed.de 

[18] NorthernLight, a Nordic lambda network facility: 

www.nordu.net/development/northernlight.html. 

[19] DANTE network: http://www.dante.net 

1.2.2 Acronyms and Abbreviations 

ACL Access List 

ASON Automatic Switched Optical Network 

ASTN Automatic Switched Transport Network 

ATM Asynchronous Transfer Mode 

AToM Any Transport over MPLS 

BGP Border Gateway Protocol 

CDN Content Distribution Network 

CP Control Plane 

CPU Central Processing Unit 

CSPF Constrained Shortest Path First 

CWDM Coarse WDM 

dB Decibel 

DCN Data Communication Network 

Demux Demultiplexer 

DHCP Dynamic Host Configuration Protocol 

DSCP Differentiated Services Code Point 

DP Data Plane 

DWDM Dense WDM 

ELH Extended LH 

EMS Element Management Software 

E-NNI External Network Node Interface 

ETH Ethernet 

FC Fibre Channel 

FE Fast Ethernet 

FEC Forward Error Correction 

Gbps Gigabit per second 

GE Gigabit Ethernet 

GE / GbE Gigabit Ethernet 

GFP Generic Framing Procedure 

GMPLS Generalized Multi Protocol Label Switching 

GUI Graphical User Interface 

HD(D) Hard Disk (Drive) 

HDTV High Definition Television 

HW Hardware 

IA Implementation Agreement 

IDE Integrated Drive Electronics 

IEEE Institute of Electrical and Electronics Engineers 

IETF Internet Engineering Task Force 

IGMP Internet Group Messaging Protocol 

I-NNI Internal Network Node Interface 

IP Internet Protocol 

iSCSI SCSI over IP 

ITU-T International Telecommunication Union-Telecommunication Standardization Sector 

JBOD Just a Bunch Of Disks 

KB/MB/GB/TB Kilo/Mega/Giga/Tera-Byte



Page 9 of 68 

File: 


LAN PHY Local Area Network Physical Layer (Interface) 

LCAS Link Capacity Adjustment Scheme 

LH Long Haul 

LION Label Interworking in Optical Networks (former IST Project) 

LMP Link Management Protocol 

LSP Label Switched Path 

MAC Media Access Control 

MAN Metropolitan Area Network 

MPEG Moving Pictures Experts Group 

MPLS Multi-Protocol Label-Switching 

MUPPET Multi-Partner European Test Beds for Research Networking 

NE Network Element 

NMS Network Management Software 

NNI Network Network Interface (aka Network Node Interface) 

NOBEL Next generation Optical network for Broadband in Europe 

NREN National Research Network 

O/E Optical / Electrical 

OADM Optical Add-Drop Multiplexer 

OIF Optical Internetworking Forum 

OSPF Open Shortest Path First 

OXC Optical Cross Connect 

PDU Protocol Data Unit 

PoP Point of Presence 

PVC Permanent VC 

QoS Quality of Service 

RAID Redundant Array of Independent Disks 

RFC Request for Comments 

RSVP-TE Resource Reservation Protocol – Traffic Engineering extension 

RTP Real Time Protocol 

SAN Storage Area Network 

SCSI Small Computer Systems Interface 

SDH Synchronous Digital Hierarchy 

SNMP Simple Network Management Protocol 

SONET Synchronous Optical Network 

STM Synchronous Transport Module 

SW Software 

TCP Transmission Control Protocol 

TLS Transparent LAN Service 

TOS Type Of Service 

UDP User Datagram Protocol 

ULH Ultra LH 

UNI User Network Interface 

URL Uniform Resource Locator 

VC Virtual Container 

VCAT Virtual Concatenation 

VLAN Virtual LAN 

VPLS Virtual Private LAN Services 

VPN Virtual Private Network 

W3C WWW Consortium 

WDM Wavelength Division Multiplex 

WDM Wavelength Division Multiplexing 

WRED Weighted Random Early Detection 

WWW World Wide Web



XC Cross Connect 

1.3 Document History 

Page 10 of 68 

File: 


Version Date Authors Comment 

0.01 22/07/2004 H.-M. Foisel Initial document 

structure 

0.02 09/08/2004 H.-M. Foisel Update doc structure 

based on comments by 

WP3 participants and 

new MUPPET 

template 

0.03 15/09/2004 MUPPET partners First draft document 

0.04 27/09/2004 MUPPET partners Second draft document 

1.00 01/10/2004 MUPPET partners, 

Hans-Martin Foisel, 

Christoph Gerlach, 

Ronald Müller 

1.4 Document overview 

Final version of the 

document 

This document is structured into three main parts: 

Section 2 contains a short summary of the participation of three MUPPET partners (Marconi, TILAB, 

T-Systems/Deutsche Telekom) at the OIF World Interoperability Tests and Demonstrations at 

SuperComm 2004, which fosters and supports the ongoing activities within MUPPET. 

Section 3 is dealing with the description of the overall design, the actual status and the functions 

provided to the MUPPET project and the interfaces/functions for the inter-test bed connections of the 

Southern-, Central-, Northern-, Western- and Eastern European local test beds. Additionally, the 

MUPPET partners, who will provide applications and are located remotely from the five local test 

beds, have added their requirements to the transport network and a description of the local NREN 

PoPs to be used in MUPPET. 

In section 4 the network functions, interface functions and local PoPs descriptions of the involved 

NRENs and the local test beds are included, building the bases for the next activities related to the 

practical implementation of the test bed interconnections.



Page 11 of 68 

File: 


2 Optical Internetworking Forum: World Interoperability Tests 

and Demonstration at SuperComm 2004 –Participation of 

MUPPET partners 

2.1 Introduction 

The evolution of high bandwidth data applications and optical technologies has posed challenging 

deployment issues for today’s carriers embedded with legacy management and operations systems. As 

data and optical network convergence issues came to light, carriers began to evaluate and introduce 

intelligent control plane (CP) mechanisms and enhanced data stream mappings that deliver 

operational benefits in a multi-vendor environment. However, lack of standardization on previous 

implementations poses a different set of challenges in addressing multi-vendor and multi-domain 

interoperability. 

A number of standardisation bodies [1-3] and forums, among them ITU-T (Automatic Switched 

Optical Networks/ASON), IETF (Generalized Multi-Protocol Label Switching/GMPLS) and the 

Optical Internetworking Forum/OIF (Control plane interfaces: User-Network-Interface/UNI and 

External Network-Network-Interface/E-NNI), are aiming at making this interoperability happen in a 

standard compliant way. The OIF perform additionally the next step of paramount importance for 

future deployments: Interoperability tests of new network functions. This chapter reports on the first 

world wide distributed interoperability test as a joint effort of vendors and carriers in the first half of 

this year 2004, particularly the role of the MUPPET partners: Marconi ONDATA (Germany) and 

Marconi SpA (Italy), TILAB/Telecom Italia and T-Systems/Deutsche Telekom [4]. This participation 

was seen as a pre-MUPPET activity, which is well aligned with the planned work in MUPPET and 

was taken as a great opportunity to preliminary implement interoperable solutions on a worldwide 

scale, which serve as a basis and strongly supports the now ongoing work within MUPPET. 

2.2 Overall test description 

These interoperability tests, while based on a multi-domain network scenario, were covering two main 

areas. 

• CP interfaces: UNI (Client network – transport network domain) and E-NNI (between 

transport network domains), based on OIF specifications [5-6], which are aligned with the 

corresponding ITU-T standards [7 - 9] 

• Most efficient Ethernet over SDH/SONET adaptation, based on ITU-T Recommendations 

related to GFP-F, VCAT, LCAS [10 - 15] 

The tests have been designed on a global stage with seven carrier labs across three continents, 

interworking through intelligent control plane mechanisms created by a multi-vendor environment of 

fifteen vendor participants (Table 1 and 2). 

Table 2.2-1: Carrier participants 

Asia China Telecom, KDDI, NTT 

Europe Deutsche Telekom, Telecom Italia 

USA AT&T, Verizon



Table 2.2-2: Vendor participants 

Alcatel Marconi ONDATA and 

Marconi SpA 

Page 12 of 68 

File: 


Fujitsu 

ADVA Optical Networking NEC Lucent Technologies 

Avici Systems Nortel Networks Mahi Networks 

CIENA Corporation Siemens AG Tellabs 

Cisco Systems Sycamore Networks Turin Networks 

All seven carrier labs were interconnected by CP connections based on IPSEC tunnels over the public 

Internet (Figure 2.2-1). Additionally three labs, Verizon, AT&T and Deutsche Telekom, were 

interconnected by a data connection of VC-4/STS-3c. 

NTT 

CT 

Asia USA Europe 

KDDI 

AT&T 

All others are CP 

interconnections 

CP & DP 

Verizon 

CP & DP 

Figure 2.2-1: Topology overview of the worldwide test bed 

CP: Control Plane; DP: Data Plane 

At the carrier labs, CP and DP complete tests for UNI, E-NNI and Ethernet over SDH/SONET 

adaptation were performed, in which CP-only tests could be accomplished between the labs (virtual 

connections), excepting the inter-lab tests between Verizon, AT&T and Deutsche Telekom. 

For actively monitoring the connection configurations in this multi-domain environment, locally in 

the labs but even more globally, despite the fact that no central monitoring instance could provide this 

function, a de-centralised approach was chosen based on a topology display software from Clear Pond 

DT 

TI



Page 13 of 68 

File: 


[16]. In such a way the actual global topology could be monitored online and additionally used for 

presentations and demos in the carrier labs and finally at the SuperComm 2004. 

Control plane interface interoperability tests 

These interoperability tests were based on OIF specifications (Implementation Agreements/IA) [3, 5, 

6], which are aligned with the corresponding ITU-T standards [7-9]: 

• IA: UNI 1.0 Signalling Specification, Release 2 

• IA: E-NNI-01.0 (Signalling) 

• Draft: E-NNI-01.0 (Routing) 

These CP interfaces allow requests of connections, from the client side (Switched Connections) or by 

EMS/NMS (Soft Permanent Connections) of a domain, over multiple ASON/GMPLS domains by 

using the CP functionality only (Figure 2.2-2). As such, multi-domain connections can be set up 

without involvement of the EMS/NMS of the intermediate domains (assuming this action is covered 

by Service Level Agreements). These new functions will significantly ease connection configuration 

of such multi-domain networks. 

Client 

network 

D 

Client 

network 

C 

UNI 

UNI 

Optical network A 

I-NNI 

Carrier domain 

Figure 2.2-2: Reference network for control plane interfaces (UNI, E-NNI) interoperability tests 

In Table 2.2-3 the performed interoperability tests are listed. The tests were carried out first locally in 

each carrier lab, then per continent and finally at global scale. 

Table 2.2-3: Control plane interface tests performed 

E-NNI 

Optical networkB 

I-NNI 

Test Test case UNI-C UNI-N E-NNI 

1 Basic routing functionality - - X 

2 Routing functionality for virtual links - - X 

3 Connection initiated by UNI X X - 

4 Dual-domain connection initiated by EMS - - X 

UNI 

UNI 

UNI 

Client 

network 

A 

Client 

network 

B



Page 14 of 68 

File: 


5 Dual-domain connection initiated by UNI X X X 

6 Multi-domain connection initiated by UNI X X X



Page 15 of 68 

File: 


2.3 Ethernet over SDH/SONET adaptation interoperability tests 

Most efficient mapping 

of Ethernet over 

SDH/ SONET 

ASON/ GMPLS network 

based on SDH/ SONET 

Payload only is 

transmitted 

Figure 2.3-1: Reference network for Ethernet over SDH/SONET adaptation interoperability 

tests 

These tests (Table 2.3-1) were based on ITU-T Rec.: G.7041/GFP-F, G.707/VCAT, G.7042/LCAS, 

etc. [10 - 15] and carried out locally at the labs of Telecom Italia, Verizon, AT&T and Deutsche 

Telekom, in which the latter three have additionally accomplished inter-lab tests (Figure 2.3-1). They 

show clearly that actual, standard compliant implementations of this most efficient Ethernet over 

SDH/SONET adaptation are really interoperable, even on global scale. 

Table 2.3-1: Ethernet over SDH/SONET tests performed 

Test Test cases 

1 Partial bandwidth (B), FE over STS-1/VC-3 

2 Full B, FE over STS-1-2v/VC-3-2v 

3 Full B, GE over STS-1-21v/VC-3-21v 

4 Partial B, GE over STS-1-3v/VC-3-3v 

5 Partial B, FE over STS-1-Xv/VC-3-Xv, LCAS 

6 Partial B, GE over STS-1-Xv/VC-3-Xv, LCAS 

7 Full B, FE over STS-3c/VC-4 

8 Full B, GE over STS-3c-7v/VC-4-7v 

9 Partial B, GE over STS-3c-1v/VC-4-1v 

10 Partial B, GE over STS-3c-Xv/VC-4-Xv, LCAS



2.4 Example of local lab tests 

Page 16 of 68 

File: 


Based on previous ASON/GMPLS demonstrator activities, TILAB and Deutsche Telekom, have 

participated in these OIF tests, completing the areas of the carriers involvement in the work of the 

OIF, contributions to specifications and participation at interoperability tests and demos. This shows 

the carriers’ interest and support and sets the bar for future work in this field. Table 2.4-1 shows an 

example of the network functionalities available and tested at DT’s lab. 

Table 2.4-1: Network functions tested in DT’s lab 

Vendor Network functions 

Ciena Corporation UNI(N) 1.0R2, E-NNI, GFP-F/VCAT/LCAS 

Marconi Corporation UNI(N) 1.0R2, E-NNI, GFP-F/VCAT/LCAS 

Tellabs UNI(N) 1.0R2, E-NNI, GFP-F/VCAT/LCAS 

Cisco Systems UNI(C) 1.0R2 

Alcatel GFP-F/VCAT 

Lucent Technologies GFP-F/VCAT/LCAS 

ADVA Optical Networking GFP-F/VCAT 

2.5 Configuration of Test bed Environments at TILAB and DT's labs 

GFP 

VCAT 

w/ o LCAS 

GFP 

VCAT 

w/ o LCAS 

ADVA 

FSP1500 

Alcatel 

1660 

VC-4 XC 

E-NNI to AT&T 

Marconi 

UNI 

Ciena 

MSH E-NNI 

CD 

VC-4 XC VC-3/ 4 XC 

Cisco 

GFP 

VCAT 

LCAS 

VC-4 chan. 

GSR12406 

E-NNI 

Internet 

Router 

Hub 

E-NNI 

GFP 

VCAT 

LCAS 

Tellabs 

6350 

VC-12 XC 

UNI to Cisco 

UNI 

VC-4 chan. 

Cisco 

GSR12406 

Lucent 

λ Unite 

VC-3/4 

E-NNI to TILAB 

E-NNI to NTT 

Adva 

FSP1500 

Tellabs 

6345 

VC-12 XC 

Figure 2.5-1: Test network configuration at Deutsche Telekom / Berlin 

GFP 

VCAT 

LCAS 

GFP 

VCAT 

w/ o LCAS 

This chapter's purpose is to describe the networks established in the respective labs during the OIF 

interoperability tests (Figure 2.5-1 and Figure 2.5-2). 

Both local test networks are composed of a core area of network elements (NE) interconnected by E- 

NNI interfaces, enabling therefore control plane based connection configuration crossing multiple 

network domains. User network domains are attached to these core NEs via UNI interfaces, 

supporting the configuration of switched connections over multiple domains. Furthermore NE with 

GFP 

VCAT 

LCAS



Page 17 of 68 

File: 


Ethernet over SDH adaptation functions are also connected to the core NE, which provides the needed 

any-to-any interconnectivity for the interoperability tests. 

UNI and E-NNI signalling was transmitted out-of-band, based on a separate Ethernet network. E-NNI 

information between distant nodes, for inter-lab multi-domain connections, was exchanged via IPSec 

tunnels using the public Internet. In this way multi-domain interoperability could be tested per 

continent and on a global scale. 

Figure 2.5-2: Test network configuration at TILAB / Torino

3 MUPPET test bed descriptions 

This chapter contains the detailed description of the five local tests beds, their architecture and the 

functions provided to the MUPPET project. 

Telefonica I+D 

ACREO 

DTU 

Western Europe 

test bed 

RedIRIS 

Northern Europe 

test bed 

SUNET 

NORDUnet 

DARENET 

TILAB 

GEANT 

GARR 

DFN 

Southern Europe 

test bed 

PIONIER 

FAU 

Figure 2.5-1: Planned MUPPET test bed configuration 

Central Europe 

test bed 

Eastern Europe 

test bed 

T-Systems 

PSNC 

All five tests beds will be connected to the respective national NRENs and via these to GEANT, 

insuring in this way interconnectivity at European scale. These five tests beds and their 

interconnectivities are building the basis of the MUPPET European scale ASON/GMPLS test bed, 

which will be used for network technology evaluations and investigations of high-end applications.

3.1 Southern Europe test bed 

3.1.1 The TILAB Networking Test Bed 

The TILAB test bed represents the advanced networking infrastructure of the Southern Europe 

MUPPET test bed. Located in TILAB premises in Torino, the networking test bed leverages the 

resources of the “Optical Networking” Lab: space, cablings, measurement instruments, traffic 

generators, etc. The TILAB test bed is connected to the following TILAB application laboratories: 

• TILAB Grid Node 

• TILAB SAN Lab 

• TILAB Video Communication Lab 

It will be connected by means of IP links and leased lines to other Partner’s sites and other MUPPET 

test beds in Europe. 

The networking test bed, whose structure is represented in Figure 3.1-1, is based on an IP/MPLS layer 

over an optical layer with ASON/GMPLS capabilities. The interworking between the two layers will 

be realised by means of Optical UNI (User to Network Interface). 

Leased Lines 

GARR (GEANT) 

RESEAU 

UNI 

TILAB 

Grid Node 

Optical/Digital 

domain 

• Marconi optical/digital 

cross-connects 

TILAB 

SAN lab 

IP/MPLS Network 

TILAB 

VideoCom 

Photonic 

domain 

E-NNI 

NOBEL 

domain 

• Equipment provided by TILAB 

• Equipment from NOBEL Project 

IP/MPLS network 

(NOBEL DOMAIN) 

Figure 3.1-1: Structure of the TILAB test bed 

IP/MPLS layer 

• TILAB transparent 

OXCs 

ASON/GMPLS 

layer 

3.1.1.1 IP/MPLS layer 

The IP/MPLS layer is realised with commercial routers provided by TILAB and will be enhanced 

with integration of IP equipment from the test bed of the IST Project NOBEL. 

The commercial routers to be used within the project are on order and have the following 

characteristics: 

• Packet Over Sonet/SDH (POS) interfaces at 155 Mbit/s line speed, having UNI-C 1.0 r2 as 

signalling interface 

• Gigabit Ethernet (GbE) interfaces, suitable to house the UNI 2.0 when available.



Page 20 of 68 

File: 


3.1.1.2 ASON/GMPLS layer 

The ASON/GMPLS layer contains three different domains: 

• The “Photonic” domain is a network of transparent optical cross-connects controlled by a 

distributed GMPLS control plane developed by TILAB. This domain is actually the evolution 

of the IST Project LION test bed, some of the future functionalities will be developed by the 

NOBEL project 

• The “Optical/digital” domain will be deployed during the MUPPET Project by integrating 

Marconi optical cross-connects with SDH VC-4 switching capability and a distributed control 

plane 

• Finally, the test bed will be completed by integrating a third domain (“Nobel” domain) fully 

developed by the NOBEL Project. This domain will be mainly based on optical/crossconnects. 

3.1.1.2.1 Photonic Domain 

The photonic domain derives directly from the test bed developed during the IST LION project even 

if some parts of it (like the Tellium equipment) are no longer available. The current configuration 

consists of six optical network elements (OXCs) provided by TILAB. The photonic domain has 

ASON capabilities supporting both soft-permanent and switched connections. 

The transport plane of the photonic domain is composed by FSC (Fibre Switching Capable) devices; 

for the time being, no transponders, amplifiers or multiplexers/demultiplexers are available, but it’s 

planned to enhance the test bed with some optical devices in order to simulate impairments on some 

links. The logical architecture of the transport plane is shown in Figure 3.1-2: six optical cross 

connects (OXC) are implemented using three different switching fabrics. Two of them are 16x16 

electro-mechanical matrices and are used to implement OXC1 and OXC4, while the third is a 32x32 

matrix (adopting MEMs technology) with power detectors on input and output ports and is subdivided 

into four 8x8 elements to implement the remaining OXCs. 

OXC 1 

OXC 2 

OXC 3 

OXC 4 

OXC 5 

OXC 6 

Figure 3.1-2: Transport plane of the photonic domain 

The links interconnecting the OXCs (consisting of a pair of optical fibres) are grouped in bundles: for 

example, the connection between OXC2 and OXC4 is realized by a bundle of three pairs of fibres, 

while the connection between OXC1 and OXC3 is realized by two bundles of two pairs each; this is 

the way chosen to reduce the amount of information that must be flooded by the routing protocol.



Page 21 of 68 

File: 


All nodes (apart from OXC3) have some free I/O ports that can be allocated, by means of control 

plane configuration, for interconnecting client devices or devices that are part of other domains, 

realizing therefore different network scenarios. 

The control plane of the photonic domain is implemented using a distributed approach where every 

node has its own instance of the processes needed to manage the resources and the setup/tear-down of 

connections. In particular, the architecture of the control plane is in line with Rec. ITU-T G.8080 in 

terms of components used to manipulate transport network resources in order to provide the requested 

functionalities. The implemented components (as shown in Figure 3.1-3) are the Connection 

Controller (CC), the Routing Controller (RC), the Link Resource Manager (LRM) and the related 

Protocol Controller. 

Control Plane 

RC 

CC 

LRM 

OSPF RSVP LMP CCI 

Ethernet 

port 

Ethernet 

port 

To neighbor nodes 

Ethernet 

port 

Figure 3.1-3: Control plane architecture 

Ethernet 

port 

Every node runs control plane processes on a PC running the Linux operating system. Each node has 

point-to-point Fast Ethernet control channels towards neighbour nodes, in order to simulate a network 

scenario where Optical Supervisory Channels (OSC) are used as control channels; nevertheless all 

nodes have separate connections to a Data Communication Network (DCN) for management and 

configuration. The signalling protocol adopted within the domain (I-NNI) is RSVP-TE with GMPLS 

extensions while the routing protocol is OSPF-TE, again with GMPLS extensions and some 

proprietary adaptation in order to re-use standard messages to advertise parameters of a FSC network. 

The nodes have also neighbour discovery capabilities according to control channel management and 

link property correlation procedures of the LMP protocol. By means of this protocol, each node 

exchanges its local configuration information for control channels and TE-links with its neighbours, 

in order to check its consistency before advertising it using the routing protocol. In this way the link 

state database maintained at every node by the routing protocol has reliable information for path 

calculation. Moreover, the routing protocol advertises resource utilization and availability so that path 

calculation can take care of busy TE-links choosing an alternative (compared to the one with 

minimum cost) path. 

The signalling interface towards client devices (UNI) is compliant with OIF UNI1.0 and adopts 

RSVP-TE protocol; it is implemented trough out-of-fibre Fast Ethernet links.



3.1.1.2.2 Optical/digital Domain 

Page 22 of 68 

File: 


The optical/digital domain of the test bed, consisting of at least three optical/digital cross-connects 

provided by Marconi Spa, is not yet available and will be deployed during the project lifetime. 

In order to reach the required capability and flexibility foreseen by the project objectives, a minimum 

set of requirements has been defined: 

• SDH VC-4 switching capability 

• Distributed control plane with signalling provided by UNI-N 1.0 interfaces towards the client 

devices (UNI-N 2.0 for GbE interfaces when available) and I/E-NNI towards the other nodes 

of the network 

• One STM-1 optical module with 16 ports for each network element 

• One STM-16 module with 4 ports for each network element 

• Initially two GbE modules with GFP/VCAT/LCAS capabilities to allow the immediate 

realization of bidirectional GbE connections between two network elements; 

• A third GbE card with UNI-N 2.0 (and the replacement or upgrade to UNI-N 2.0 for the other 

two GbE cards) as soon as the UNI 2.0 support will be available. 

A possible layout for the optical/digital domain is presented in Figure 3.1-4. 

16 * STM1 

Marconi 

OXC 

(1) 

4 * STM16 

16 * STM1 opt. 

a a’ 

c 

4 * GbE 16 * STM1 4 * GbE 

c’ 

Marconi 

OXC 

(2) 

16 * STM1 

Figure 3.1-4: Layout of the optical/digital domain. 

4 * GbE 

Marconi 

OXC 

(3) 

In order to emulate long distance links a-a’, b-b’ and c-c’ between network nodes, the adoption of a 

WDM system (see Figure 3.1-5) has been planned as a future upgrade of the optical/digital domain. 

b’ 

b



100 km 

Page 23 of 68 

File: 


a a’ 

b b’ 

c 

c’ 

Figure 3.1-5: WDM System to emulate long distance links 

With reference to Figure 3.1-6, this WDM system will be implemented by integrating some already 

existing components in the TILAB premises (mainly the MUX-DEMUX, the line amplifiers and the 

G.655 optical fibre) with other components (mainly the transponders) to be provided within 

MUPPET. 

Figure 3.1-6: WDM System Components. 

3.1.1.3 NOBEL Domain (IP/MPLS and ASON/GMPLS Layers) 

This section contains a brief description of the equipments and functionalities that have been or will 

be implemented within the IST-NOBEL project activities, and will also be exploited within the scope 

and objectives of the MUPPET project. For more details please refer to the related documentation 

(Deliverable D7) issued by the IST-NOBEL project.



Page 24 of 68 

File: 


The IP/MPLS layer will contain (when completed) a certain number of Gigabit Switch Routers 

equipped with Fast Ethernet, Gigabit Ethernet and POS interfaces at 155 Mbit/s and 2.5 Gbit/s. Some 

routers will support the UNI-C 1.0 R2 on the POS interfaces ate 155 Mbit/s and, when available, the 

UNI 2.0 on the GbE interfaces 

The ASON/GMPLS will contain a 160 Gbit/s Multi-service SDH network element, equipped with 

interfaces ranging from 2 Mbit/s to 10 Gbit/s and Ethernet mapping capabilities. The Control Plane 

will have advanced GMPLS functionalities like the E-NNI and UNI ones. 

3.1.2 The TILAB Grid Node 

The TILAB Grid Node will be based on the experimental Grid platform existing at TILAB premises. 

The proposed scenario is described in Figure 3.1-7 and it is composed of some POP sites, connected 

through an IP/MPLS backbone. Data transmission will be than realized using the ASON/GMPLS test 

bed. This infrastructure is equipped with generic PCs hardware and Grid software such as Globes 

Toolkit v3. Technology will be based on SOAP/XML to meet high flexibility. 

New Services demonstrations will be based on the dynamic interaction of the Grid platform and the 

Network. Goals will be achieved by performing interaction between Grid nodes and Network Control 

Servers such as QoS and VPN servers. 

Final 

User 

Grid 

Node 

Site 1 

Site 2 

Service 

Web 

Portal 

HTTP 

Interaction 

QoS VPN CDN 

Control Framework 

Optical Optical 

Network 

Network 

IP/MPLS 

Figure 3.1-7: TILAB Grid Node. 

SOAP/XML 

(Grid Service) 

Interaction 

Site 3 

Grid 

Node 

MUPPET MUPPET MUPPET MUPPET MUPPET MUPPET MUPPET MUPPET Network Network Network Network Network Network Network Network 

Virtual 

Organization 

Let see in more detail, the different sites and the IP/MPLS backbone as in Figure 3.1-8. The 

infrastructure uses a set of routers equipped with Ethernet, Fast Ethernet (FE) and Serial interfaces. 

Such a network permits the access of a generic client through a portal, to a set of applications (e.g.: 

file zip, digital mark) installed on remote servers. Moreover, the network connects servers to share the 

available applications, CPU and memory resources.



Eth 

Eth 

PoP 

Server X2 

G 

C 

CISCO 

4500 

PoP 

CISCO 

1721 

Se 

Pitagora 

CE 

Eth 

FE 

Se 

Inv-2 

CE 

FE 

Se 

G I 

Web Server X1 

Internet 

Eth 

CISCO 

7204 

FE 

Socrate 

PE 

Client 

FE 

FE 

CISCO 

3640 

FE 

FE 

Epicuro 

CISCO 

2621 

Eth 

Platone 

FE 

Se 

Page 25 of 68 

File: 


Eth 

Aristotele 

PE 

Eth 

Se 

CISCO 

7204 

Se 

PoP 

C Custom grid-services 

Se 

Eth 

Fiab1 

CE 

Ethernet interface (Eth) 

Fast Ethernet interface (FE) 

Serial interface (Se) 

I Index Service 

(grid-services available register) 

G Globus Toolkit 3.2 

(container + basic grid-services) 

Figure 3.1-8: TILAB test bed for the Grid Node. 

In a first phase, the test bed uses only a couple of servers located into two different POP sites. These 

boxes are Linux equipped, with generic PCs hardware and Grid software such as Globus Toolkit v3.2. 

Table 3.1-1 describes the operative system installed, the HW and SW technical features of the used 

servers. 

Server features 

Operative System Linux - Redhat 9.0A 

Hardware 

Pentium IV 2.4 GHz 

RAM 904 MByte 

HD 80GB 

Level2 cache 512kbyte 

Software Apache 2.0 (installed only on the Web Server) 

Table 3.1-1: Server features. 

The test bed integrates different models of routers from Cisco Systems. Detailed technical 

specifications of each device can be found in Table 3.1-2 . 

CISCO 

2500 

Eth

Aristotele 

Epicuro 

(cisco 2621) 

Platone 

(cisco 3640) 

Socrate 

(cisco 7204) 

Inv-2 

(cisco 1721) 

Pitagora 

(cisco 4500) 

Router Features Fiab1 

(cisco 2500) 

7200 Software (C7200- 

P-M), Version 12.3(1a), 

RELEASE SOFTWARE 

(fc1) 

C2600 Software 

(C2600-TELCO-M), 

Version 12.2(2)T, 


(fc1) 


TELCO-M), Version 

12.3(1a), RELEASE 

SOFTWARE (fc1) 


JS-M), Version 



C1700 Software 

(C1700-SY-M), Version 

12.2(11)T8, RELEASE 



IS-M), Version 



IOS (tm) 2500 Software (C2500- 

I-L), Version 12.1(20), 


(fc2) 

System Bootstrap, 

Version 12.2(1r) [dchih 

1r], RELEASE 



Version 11.3(2)XA4, 


(fc1) 


Version 11.1(20)AA2, 

EARLY DEPLOYMENT 


(fc1) 


Version 12.2(1r) [dchih 

1r], RELEASE 



Version 12.2(7r)XM1, 


(fc1) 


Version 5.1(1) [daveu 

1], RELEASE 


ROM System Bootstrap, 

Version 11.0(10c), 

SOFTWARE 


BOOT-M), Version 

12.0(13)S, EARLY 

DEPLOYMENT 


(fc1) 

- C2600 Software 

(C2600-TELCO-M), 

Version 12.2(2)T, 


(fc1) 

- 7200 Software (C7200- 

BOOT-M), Version 

12.0(13)S, EARLY 

DEPLOYMENT 


(fc1) 

4500-XBOOT 

Bootstrap Software, 

Version 10.1(1), 


(fc1) 

BOOTLDR 3000 Bootstrap 

Software (IGS-BOOT- 

R), Version 11.0(10c), 


(fc1) 

Uptime 22 hours, 36 minutes 21 hours, 53 minutes 21 hours, 55 minutes 21 hours, 57 minutes 22 hours, 0 minutes 22 hours, 0 minutes 22 hours, 3 minutes 

cisco 7204VXR 

(NPE225) processor 

(revision A) 

cisco 2621 (MPC860) 

processor (revision 

0x102) 

cisco 3640 (R4700) 

(revision 0x00) 

Processor cisco 2500 (68030) cisco 4500 (R4K) cisco 1721 (MPC860P) cisco 7204VXR 

(NPE225) (revision A) 

14336K/2048K 32768K/16384K 29492K/3276K 114688K/16384K 59392K/6144K 27648K/5120K 114688K/16384K 

Processor memory 

[bytes] 

ID 25856777 

ID JAB035101C4 

(1042591346) 

ID 25860188, 

ID FOC07120AWP 

(633392346), with 

hardware revision 

0000, 

ID 01325035, R4600 

CPU at 100Mhz, 

Implementation 32, Rev 

2.0 

Processor board ID 06018704, with 

hardware revision 

00000001 

R527x CPU at 262Mhz, 


10.0, 2048KB L2 

Cache 

M860 processor: part 

number 0, mask 49 

ID 26429838, R4700 

CPU at 100Mhz, 


1.0 

R527x CPU at 262Mhz, 


10.0, 

MICA-6DM Firmware: 

CP ver 2940 - 

7/24/2002, SP ver 2940 

- 7/24/2002. 

2048KB L2 Cache, 4 

slot VXR midplane, 

Version 2.5 

MPC860P processor: 

part number 5, mask 2 

4 slot VXR midplane, 

Version 2.5

File: 




- Bridging software 






Software - Bridging software 

- X.25 software, 

Version 3.0.0 


Version 3.0.0 


Version 3.0.0 

- X.25 software Version 

3.0.0, 


3.0.0 


Version 3.0.0 


3.0.0, 

- SuperLAT software 

(copyright 1990 by 

Meridian Technology 

Corp) 




Corp) 




Corp), 

- G.703/E1 software, 

Version 1.0 

- Basic Rate ISDN 

software Version 1.1 

- Basic Rate ISDN 

software, Version 1.1 

- TN3270 Emulation 

software 

1 2 2 4 - 4 4 

Ethernet/IEEE 802.3 

interface(s) 

- - 1 3 3 2 1 

FastEthernet/IEEE 

802.3 interface(s) 

4 

2 2 - 4 2 - 1 Serial network 

interface(s) 

- 2 Serial(sync/async) 

network interface(s) 

Serial network 

interface(s) 

1 - - - 4 - - 

ISDN Basic Rate 

interface(s) 

- 1 - - - - 1 

ATM network 

interface(s) 

32K bytes 128K bytes 32K bytes 125K 125K 32K 125K 

non-volatile 

configuration 

memory [bytes] 

46976K bytes of ATA 

PCMCIA card at slot 0 

(Sector size 512 bytes) 

16384K 

(Read/Write) 

8192K bytes 

(Read/Write) 

46976K bytes of ATA 

PCMCIA card at slot 0 

(Sector size 512 bytes) 

16384K bytes 

(Read/Write) 

8192K bytes 

(Read/Write) 

8192K bytes (Read 

ONLY) 

Processor board 

System flash [bytes] 

- 4096K bytes of Flash 

internal SIMM (Sector 

size 256K) 

16384K bytes of 

processor board 

PCMCIA Slot1 flash 

(Read/Write) 

- 4096K bytes of Flash 

internal SIMM (Sector 

size 256K) 

- 4096K bytes 

(Read/Write) 

Processor board 

Boot flash [bytes] 

0x2102 0x2102 0x2102 0x2102 0x2102 0x2102 0x2102 

Configuration 

register 

Table 3.1-2: Router features. 

Page 27 of 68

3.1.3 The TILAB Video Communication Lab 

The activities related to the high quality videoconference experiments will be held utilizing the 

equipment and the infrastructure available at the TILAB Video Communication laboratory. This 

laboratory consists of generic PCs hardware, audio/video acquisition peripherals and a 

videoconference software platform developed by TILAB. In the proposed scenario this HW and SW 

infrastructure will be used for point-to-point and multipoint video communication experiments in the 

ASON/GMPLS test bed. 

TILAB videoconference platform consists of multiple distributed client-server components; current 

version of client software is a PC Windows application that offers the following functionalities: 

• call setup: signalling component for point-to-point communication is based on SIP protocol, while 

multipoint communication currently uses a proprietary signalling protocol transported over TCP 

• audio/video streams acquisition with different configurable video format (CIF, QCIF) and frame 

rate 

• audio/video encoding with configurable bandwidth values; currently supported CODEC are: 

o Audio: ITU.T G.723.1, AMR 

o Video: ITU.T H263, MPEG4 ASP 

• audio/video streams transmission using RTP protocol 

• receipt and visualization of other participant audio/video streams 

TILAB videoconference platform server environment consists of the following functional elements: 

• A/V Cross Connector: this element is responsible for the optimized replication of all audio/video 

streams, so that each participant can see/listen everyone else; Figure 3.1-9 shows a single server 

configuration, but multiple servers are supported for performance and scalability (a Resource 

Manager Server is responsible of RTP audio/video traffic load balancing between multiple 

Reflector Servers) 

• Application Server: consists of a Presence and Signalling Server module, that includes presence 

handling and call setup functionalities (through a SIP Proxy for point-to-point communication), 

and a Web Application module, that offers web-based conference management functions; all these 

modules can coexist on a single server, as illustrated in Figure 3.1-9, or can be distributed on 

multiple servers for performance and scalability 

At the laboratory an internal 100 Mbps Ethernet communication infrastructure is available; Figure 

3.1-9 shows current laboratory configuration, with network interconnections and protocols involved 

between different modules of TILAB videoconference platform. Peer-to-peer RTP media streams 

between clients are used for point-to-point communication, while in multipoint scenarios all RTP 

streams are sent to the Reflector Server(s) for replication towards other conference participants. 

In a first phase the test bed will use only two servers, whose HW and SW technical features are 

described in Table 3.1-3; client workstations for test bed experiments will be equipped with the 

following peripherals: 

- Pan/Tilt/Zoom control web-cams with auto tracking capabilities 

- Video acquisition boards and DV cameras 

- 20” LCD or larger widescreen monitor 

By the end of the year is planned to have two such client workstations, tuned for high quality point-topoint 

video communication: the target for first experiments is to have a bandwidth usage of more than 

1 Mbps for each audio/video stream.



Page 29 of 68 

File: 


Figure 3.1-9: TILAB Video Communication Lab. 

Server 1 (A/V Cross Connector) 

Operative System Windows Server 2003 

Hardware 

Pentium IV 2 GHz 

RAM 1024 MB 

HD 60GB 

512kbyte cache 

Software - TILAB videoconference platform modules: 

Reflector, Resource Manager 

Server 2 (Application Server) 

Operative System Windows Server 2000 

Hardware 

Dual processor Pentium III EB 933 MHz 

RAM 1024 MB 

HD 2x30GB 

256kbyte cache 

Software - Apache 2.0 

- Jakarta Tomcat 4.1 

- MySql 4.0 

- TILAB videoconference platform modules: 

Presence & Signalling Server, Web Application 

Table 3.1-3: Servers features.



3.1.4 The TILAB SAN Lab 

Page 30 of 68 

File: 


3.1.4.1 Physical Location and Connection to the Project’s resources 

The TILAB SAN Lab Laboratory provides support to the Project’s experiments with content and 

storage applications and its networking solutions. The TILAB SAN Lab is physically located at the 

TILAB premises in Turin and is connected to the other MUPPET Lab and network resources by 

means of the following connections: 

Internal Lab connections: Fibre Channel, Ethernet and Gigabit Ethernet. Switch Ethernet Cisco 

Systems Catalyst 1900 e 2900, Multilayer switch 3550 with Fast Ethernet e Gigabit Ethernet 

Interfaces. The Ethernet Cisco Catalyst switch family provides intelligent network services (QoS , 

rate-limiting, security filtering), multicast management, besides its traditional LAN switching 

capabilities. Furthermore a multilayer switch Cisco Catalyst 3550 12T 10/100/1000 and a 

multilayer switch Cisco Catalyst 3550-24 with 24 10/100 ports and 2 GbE ports provide GbE 

networking capabilities in order to connect the application servers to the storage infrastructure 

servers. 

RESEAU Network: via GbE direct access 

ASON/GMPLS test bed: via dark fibre 

Other TILAB Labs (GRID Node, Tele-Presence Lab): via the FE Connection to the TILAB LAN. The 

Cisco 3550-24 multilayer switch is also connected through its GbE F.O. interface towards the 

Reseau Network Router. 

3.1.4.2 Architecture 

The TILAB SAN Lab provides test bed for both Content Networking and Storage Networking test 

scenarios and also includes server applications architecture. 

The Storage Lab offers complete multi-vendor storage architecture based on FC and IP Connectivity 

consisting of: 

2 Independent FC SANs: 

SAN1-Row storage: 584 GB. The SAN Storage is the Chaparral JBOD RIO RAID SRF116 with 

its external controller RIO RAID connected via Fibre Channel to the storage array. The 

controller’s management Web graphical software provides the user with the configurations 

tools. The internal SAN connections are in FC technology. Specifically there is a FC link 

between the JBOD RIO RAID and the external controller and another one between the 

Controller and the Cisco SN5428. In fact the Storage Router, besides its iSCSI gateway 

function, works as FC switch. 

SAN2-Row Storage 1.2 TB. The SAN storage is the Brownie Axus BR-1600 in Integrated Drive 

Electronics (IDE), (or ATA) technology with its internal integrated controller RIO RAID. The 

controller’s management graphical RAIDCare Storage Manager Software provides the user 

with the configurations and monitoring tools. The Brownie AXUS BR-1600 is connected via 

Fibre Channel to the Storage Router CISCO SN5428. 

There is also a third SAN (SAN3-Row storage: ~80 GB), which can be added and included (with its 

storage resources) in one of the existent SAN architectures. The Storage Array is the JBOD Compaq 

StorageWorks RAID Array 4RA100. There are also available for the Project tests some 18 GB HD. 

Its internal connections are also in FC technology. Specifically the Compaq Storage can be connected 

via FC to the StorageWorks FC-AL switch 8. The switch is also connected via FC towards the 

Compaq DL 380 server cluster. The FC-AL switch can also be connected via FC to the Cisco SN5428 

Storage Router. 

The Cisco SN5428 is also connected via FE/GbE in optical fibre to the multilayer switch Ethernet 

Catalyst 3550 12T, itself being connected to the Catalyst 3550-24, Catalyst 2900 and Catalyst 1900



Page 31 of 68 

File: 


network apparatuses. The terminal client and the monitoring systems are connected to these 

apparatuses. 

The Application servers are connected to the storage servers (Clustered servers) via Fibre Channel and 

they are connected via FE/GbE to the Ethernet switch. The storage servers (IP connected via FE/GbE 

between it selves) are connected to the SANs via FC The network Impairment server is connected via 

GbE to the storage servers through the Ethernet Catalyst 3550multilayer switch. 

The following figure describes a possible SAN LAB Architecture scheme. 

Storage 

Fiber 

Copper 

FE: FastEthernet 

GbE: Gigabit Ethernet 

FC: Fibre Channel 

Infrastructure 

Servers 

Controller 

SAN 2 

(FC) 

Monitoring 

FC Switch + iSCSI 

Gateway 

(GbE) 

Reseau 

Network 

Client 

(FE) 

(GbE) 

Workstations (FE) 

(FC) 

(FE) 

(FE) 

ASON/GMPLS 

test bed 

TILAB 

LAN 

FE/GbE 

switched/routed 

network 

(FC) SAN 1 

FC switch 

Storage 

(GbE) 

1 MUPPET 

Confidential 

(FE) 

Application 

Servers 

(FE) 

(FC) 

Network 

Impairment 

Emulator 

Clustered 

Servers 

Figure 3.1-10: Potential SAN LAB Architecture scheme 

3.1.4.3 CDN Architecture 

Two independent Content Distribution Networks are also available for the Project content networking 

applications scenarios. The CDNs are: 

• Cisco ICDN 2.1 

• Cisco ACNS 5.0 release 5.1.5.b.2 (March 2004) 

3.1.4.4 TILAB SAN Lab Components 

3.1.4.4.1 Hardware 

Storage Array: Chaparral JBOD RIO RAID SRF116 with 8 72 GB HD FC Dual port 10000 rpm, total 

storage size 584 GB. This Storage Array is designed to support a 1,16 TB over a 3U rack and to 

be scalable to 8 TB. 

Storage Array: JBOD Compaq StorageWorks RAID Array 4RA100, 1 GBit/s Fibre Channel for SAN 

FC. There are also available for the Project tests some 18 GB HD. 

Storage Array: Integrated System Brownie Axus BR-1600 in Integrated Drive Electronics Technology 

(IDE), also known as ATA. This Storage Array provides a different technological solution than 

the SCSI RIO RAID one. The AXUS BR-1600 System is managed by an integrated chassisinternal 

controller. The storage unit is composed by 6 200 GB HD IDE 7200 rpm, total storage



Page 32 of 68 

File: 


size: 1,2 TB. The system uses the RAIDCare Storage Manager GUI Software for set-up and 

monitoring functions. 

External Controller: RIO RAID, Fibre Channel-connected to the Storage Array System with a web 

Graphical management software for user configuration and set-up. 

Switch Fibre Channel: Compaq StorageWorks FC-AL switch 8, connected to the Storage Array 

RA4100. It supports 8 1 Gbit/s ports FC plus an external module with other 3 ones. The switch is 

able to manage a cluster of 2 Proliant DL 380server. 

Storage Router: The Cisco SN5428 provides the SAN with iSCSI (and then also IP networking) 

capabilities. It is a multi-protocol platform for networking storage, which integrates the iSCSI/IP 

and Fibre Channel technologies, and, as iSCSI gateway, it allows the SAN to use the whole IP 

networking functions towards the external network resources. Cisco SN5428 also implements 

Fibre Channel switching capabilities. Therefore, the servers join storage resource through the 

iSCSI ports. The Cisco SN5428 Router also offers 2 Gigabit Ethernet Ports in order to connect to 

TCP/IP networks and 8 standard 1 or 2 Gigabit Fibre Channel ports. These FC ports support 

fabric switch functions or they are usable as simple direct interfaces to the storage devices 

connected. The Cisco Storage Router also provides management capabilities for storage 

networking with IP-networking tools, as SNMP management, IPSec and offers services like 

VLAN and Quality of Service (QoS). Furthermore, it supports SAN typical security capabilities, 

as LUN Mapping, LUN Masking and zoning Fibre Channel. 

Application Servers: 2 Compaq Proliant DL 360 Servers, OS Windows 2000 Server SP3, 1,13 GHz 

Intel Pentium III processor, 1,28 GB RAM and 18 GB HD. The applications implementing the 

capabilities requested by the end users in order to request storage resources are installed on these 

DL 360 servers. On these two servers is also installed an Intel PRO/1000T Server Adapter 

network card in order to be connected via GE to the other network devices. 

Storage Software Support (Infrastructure Server): 2 Proliant DL 360 Server. They have the same 

hardware requirements as the application servers, but instead with OS Linux Red Hut 8.0. On 

these servers, there is a TCP Offload Engine (TOE) Alacritech 1x1000 Copper single-port card 

which implements TCP directly in hardware and a Host Bus Adapter (HBA) card for the FC link 

to the Cisco SN5428 and to the SAN SCSI resources. 

Network Impairment (Emulation of IP Network) Support: 1 Compaq Proliant DL 360 server, OS 

Windows 2000 Server SP3, 1.13 GHz Intel Pentium III processor, 1,28 GB RAM, and 18 GB HD. 

Client: On client devices accessing servers there is an Intel PRO/1000T Desktop Network Card. This 

card provides the bandwidth the high performance desktop PCs need, in order to connect at 

10/100/1000 Mbit/s. 

Monitoring Support: 1 Compaq Proliant DL 360 server, OS Windows 2000 Server SP3, 1.13 GHz 

Intel Pentium III processor, 1,28 GB RAM, and 18 GB HD. 

3.1.4.4.2 Software 

Storage software: the Muppet Project tests need to deploy storage software: The choice about what 

software to deploy depends on both the application involved and the kind of experiments 

scheduled. This software typically provides a storage services suite. Services include mirroring, 

replication and snapshot, backup and restore, business continuity, disaster recovery capabilities. 

Monitoring Software: The SNMP pollers are SNMPc and SNMP Traffic Grapher. SNMPc is a 

Windows application. Its GUI is able to automate the configuration file management and to 

provide users with additional data about the monitored devices. SNMPc is able to draw more 

parameters on the same charts. SNMP Traffic Grapher is a freeware poller, simpler than SNMPc 

and with a few basic functionalities. It allows a continuous polling of a huge number of device 

and automatically stores data, creating daily text files. PerfMon (Performance Monitor) is native 

Win2000 e WIN NT software. It is able to monitor server/workstation parameters, both on its



Page 33 of 68 

File: 


device and on external connected server. These are both hardware parameters (as network 

interfaces, disks, RAM, cache, processor) and software. 

Network Impairment Software: DummyNet allows the management of intelligent traffic introducing 

bandwidth limitations and controlled packet loss between servers and workstations. DummyNet 

captures Ethernet packets and redirect them towards one or more pipes. These pipes simulate the 

limitations effects, introducing them with custom policies (as protocol, addresses ports, 

interfaces). By configuring the pipes (sequentially or separately) and by managing the queuing 

mechanism, it is possible to create even very complex real network conditions simulations 

(asymmetrical traffic, classes of services, multiples links). 

Measure software: IOMeter is Intel Software now available in freeware version with C language 

Source Code. IOMeter is a benchmark software for the server I/O operations performance access 

Its configuration includes: 

1) The agent (Dynamo), both on the tested server and on the client terminals. Every agent 

defines the disk quota on which to make the I/O operations, creating at the same time the 

IOBW.TST file. For every test, Dynamo creates I/O Operations as block component on 

IOBW.TST file and it makes this both locally (from agents installed on servers) and through the 

network (from agent installed on client terminals). Every agent monitors system performance, 

keeping useful parameters and periodically sending them to the Controller (IOMeter). 

2) The Controller (IOMeter) installed on the test server (also installable on the file server), while 

handling the Dynamo agent configuration, gathers, aggregates and elapses the data received. The 

controller therefore reports the outcomes from the measurements. 

3.1.4.5 SAN LAB Developments 

Depending on the Project storage application scenarios, it would be possible to improve the SAN 

LAB existent architecture with some Storage software and with more storage resources. This would 

easily be accomplished by scaling the existent heavy flexible SAN architecture. 

3.1.5 CSP 

“CSP – Innovazione nelle ICT” is a non-profit Information-and-Communication- 

Technology Research Centre, recognised by the Italian Ministry of Education, University and 

Scientific Research. Shareholders include: local government (CSI-Piemonte, City of Turin), 

University (Turin Polytechnic, University of Turin) and industrial organisations (Unione Industriale, 

Federpiemonte). CSP is a World Wide Web Consortium (W3C) affiliate member. 

CSP contribution will focus on the integration of grid computing middleware and storage technologies 

to demonstrate the usage of network and storage resources as elementary building blocks to assemble 

a new class of services, to exploit dynamically configurable networking and storage resources in grid 

computing environments and to develop a new paradigm for storage on–demand service provisioning. 

The CSP test bed will be composed of: 

- A grid enabled Linux cluster, providing applications and services accessible both interactively 

and through a portal; 

- Grid client nodes; 

- A storage area network (SAN) providing FC/iSCSI access to storage. 

This infrastructure is actually connected and accessible through the Italian academic network GARR 

and to the Telecom Italia’s network RESEAU. 

The Small Computer Systems Interface (SCSI) enables host computer systems to perform block data 

input/output (I/O) operations to a variety of peripheral devices. Target devices may include disk and 

tape devices, optical storage devices, as well as printers and scanners. The traditional SCSI connection 

between a host system and peripheral devices is based on parallel cabling. 

Parallel SCSI cabling has inherent distance and device support limitations. For storage applications, 

these limitations have fostered the development of new technologies based on networking 

architectures such as Fibre Channel and Gigabit Ethernet. Storage area networks (SANs) based on



Page 34 of 68 

File: 


serial gigabit transports overcome the distance, performance, scalability and availability restrictions of 

parallel SCSI implementations. By leveraging SCSI protocols over networked infrastructures, storage 

networking enables flexible high-speed block data transfers for a variety of applications, including 

tape backup, server clustering, storage consolidation, and disaster recovery. The Internet SCSI 

(iSCSI) protocol defines a means to enable block storage applications over TCP/IP networks. 

The SCSI protocol demands stability, data integrity and, in current implementations, expects high 

bandwidth on demand. IP networks, by contrast, are inherently unreliable, may drop packets under 

congested conditions, and have highly variable bandwidth. The TCP layer is meant to deal with the 

instability and packet loss that may accompany IP transport, while higher speed wide area connections 

can alleviate bandwidth issues for block storage data. In addition, the internal mechanisms of the 

iSCSI protocol provide additional monitoring of TCP connections and for recovering from lost or 

corrupted command and data PDUs. 

For high performance storage networking applications, the iSCSI protocol is dependent on several 

other technologies to make it a viable partner to Fibre Channel SANs. Imposing TCP overhead on 

servers, for example, is unacceptable for storage applications where server CPU cycles are at a 

premium. For optimum performance, iSCSI adapters require TCP/IP off-load engines (TOEs) to 

minimize processing overhead. TCP off-load engines will greatly assist iSCSI’s ability to provide 

enterprise-class solutions that run at or near wire speeds. 

Storage applications using iSCSI will also benefit greatly from the introduction of 10 Gigabit 

Ethernet. Ten gigabit and faster speed Ethernet enables scalable IP SANs that support higher 

populations of servers and storage devices and a variety of storage applications that can be run 

concurrently over the same network infrastructure. With TCP off-load engines on servers and large 

data pipes in the network, iSCSI solutions can achieve an enterprise-ready status for IP-based SANs.



3.2 Central Europe test bed 

Page 35 of 68 

File: 


The Central European test bed is based on an ASON/GMPLS enabled transport network 

demonstrator, which was part of the OIF World Interoperability Tests and Demonstration at the 

SuperComm 2004 (see Chapter 2) and will be significantly extended/enhanced during the MUPPET 

project. 

The test bed network architecture is fully compliant to the ITU-T G.8080 [7] ASON and the 

architecture the OIF is following (Figure 3.2-1), composed of well separated network domains, linked 

together at the control plane and date plane level by User-Network-Interfaces (UNI) with the different 

types of client networks and via External Network-Network-Interfaces (E-NNI) to other transport 

network domains. All control plane interfaces were tested during the OIF World Interoperability Tests 

and could therefore interoperate globally. 

User 

signalling 

Clients 

e.g. IP, 

ATM, 

Ethernet 

OCC 

I-NNI 

I-NNI 

UNI 

CCI 

CCI CCI E-NNI ON 

CCI 

CCI CCI E-NNI ON 

XC 

ASON control plane 

XC XC 

Transport plane 

NMS 

NMI-A 

OCC OCC 

NMI-T 

OCC: Optical Connection Controller NMI-A: Network Management Interface for the 

CCI: Connection Control Interface ASON Control Plane 

NNI: Network Network Interface NMI-T: Network Management Interface for the 

NMS: Network Management System 

UNI: User Network Interface 

Transport Plane 

Figure 3.2-1 ITU-T ASON architecture (G.8080) and OIF architecture, the Central Europe Test 

Bed is compliant with 

Corresponding to this network architecture, Figure 3.2-2 gives an overview of the ASON/GMPLS 

test network at T-Systems/Deutsche Telekom, highlighting the Marconi network domain, which will 

be included in the European MUPPET test bed. Beside the local interconnections to other transport 

and client network domains via UNI and E-NNI control plane interfaces and Ethernet over SDH 

adaptation functions towards Ethernet based metro networks, a first attempt was made to depict the 

external interfaces to the other local test beds and application locations within the MUPPET 

consortium. Furthermore the interconnection to the German national VIOLA project [17] is shown, 

which is planned for a future cooperation. 

Figure 3.2-3 shows the detailed topology of the MUPPET test bed in Berlin. This ASON GMPLS 

domain will be composed of three XCs, interconnected by I-NNI, STM-64 interfaces. The distributed 

control plane enables the following network functions within the network domain: 

• Fast connection provisioning, modification and tear down



Page 36 of 68 

File: 


• Multiple resilience functions: 1+1 protection, shared protection, restoration 

• Auto-discovery functions, e.g. neighbour discovery 

Access 

GE 

ASON/GMPLS 

TN#1 

E-NNI 

E-NNI 

ASON/GMPLS 

TN#2 

UNI 

IP-Client #1 

MAN 

E-NNI 

GE 

UNI 

IP-Client #2 

ASON/GMPLS 

transport network 

Video 

application 

Video 

application 

Figure 3.2-2 ASON/GMPLS test network configuration at Deutsche Telekom 

E-NNI 

= GE/SX 

= GE/LX 

Access 

ASON/GMPLS 

TN#1 

ASON/GMPLS 

TN#2 

UNI 

IP - Client #1 

GE 

E-NNI 

= STM-16 

= STM-64 

MAN 

S11- P1 

S11- P2 

S11- P3 

S11- P4 

E-NNI 

GE 

S10-P1 

S10-P2 

S10 -P3 

S10 -P4 

S13-P1 S13-P1 

UNI 

Marconi 

OXC 

VC-4 XC 

All LR 

S13-P2 S13-P2 

S13-P3 

S13-P4 S13-P4 

IP - Client #2 

= STM-1 

Video 

application 

I-NNI 

I-NNI 

Figure 3.2-3 Detailed topology of the MUPPET Central Europe Test Bed 

S1 

S3 

S3 

S2 

S4 

Video 

application 

S11-P1 

S11- P2 

S11- P3 

Marconi 

OXC 

VC-4 XC 

All LR 

S5 

I-NNI 

S1- P1 

S1-P2 

S1-P3 

S1-P4 

Marconi 

OXC 

VC-4 XC 

All LR 

S10-P1 

S10-P2 

S11-P16 

S1-P1 

S1- P2 

S1- P3 

S1- P4 

E-NNI 

E-NNI 

S10-P3 

S10-P4 

E-NNI 

GE 

GE 

GE 

ACREO 

TILAB 

VIOLA 

PSNC 

FAU 

E-NNI 

E-NNI 

E-NNI 

GE 

ACREO 

TILAB 

VIOLA 

PSNC 

FAU



Page 37 of 68 

File: 


Domain internal data plane functions are: 

• Interfaces: STM-16/STM-64 (LR) and Gigabit-Ethernet (GE) with SX/LX reach 

• VC-4 switching granularity 

• Ethernet mapping over SDH compliant to GFP-F/T, VCAT, LCAS 

o Optional: FC mapping over SDH (GFP-T, VCAT, LCAS) 

EMS connection and port configuration functions: 

• SDH ports: traditional, I-NNI, E-NNI, UNI-N 

• GE: GFP-F, GFP-T mapping configuration over VC-4 VCAT/LCAS enabled connections 

MUPPET central Europe test bed will have the following external interface functionalities: 

Control plane functions: 

• UNI-N 1.0 R2 (future options: UNI2.0 Ethernet) 

• OIF E-NNI with external signalling/routing 

• Support of switched connection (initiated by UNI-C) configurations over multiple network 

domains 

• Support of soft permanent connection (initiated by EMS) configurations over multiple network 

domains 

Data plane functions: 

• Interfaces: STM-1/16 (LR) and GE (LX) 







domains 

Furthermore broadband video applications (video, TV, HDTV) are available to visualize the network 

functionalities and performance, but also to serve as data traffic source beside SDH and Ethernet 

traffic generators/test equipment. All these applications will be Ethernet based (GE interface). 

3.2.1 FAU 

Although video transmissions over the Internet are becoming increasingly popular, there are still 

application areas that have not been able to use the Internet for their video and audio processing. As 

the Internet only offers best-effort transmissions and does not provide Quality-of-Service (QoS) 

guarantees, applications based on high-resolution video with interactive services that rely on short 

latencies have so far been forced to use Asynchronous Transfer Mode (ATM) networks. 

The contribution of the Friedrich-Alexander University of Erlangen-Nuremberg (FAU) to the 

MUPPET project focuses on such bi-directional high quality applications in the areas of tele-medicine



Page 38 of 68 

File: 


and professional broadcasting and relies on the MUPPET network to provide very low latency 

transmissions with end-to-end delays well below 150ms for high volumes of data. 

The SDI-over-x technologies employed by the FAU typically map uncompressed Serial Digital 

Interface (SDI) signals to network transport units within a few microseconds and can be applied to 

both Ethernet (SDI-over-IP) and optical networks (SDI-over-lambda). The application is currently 

based on ATM technology. As far as the MUPPET application scenario is concerned, the 

interconnection could be provided over dark fibre, Gigabit Ethernet (end-to-end) or Synchronous 

Digital Hierarchy (SDH) technology (end-to-end). The test bed applications of the FAU involve 1-3 

SDI sources; each source requires a minimum of 300 Mbps of bandwidth. To ensure sufficient QoS, 

the bandwidth demands may have to be increased to 600 Mbps to allow for Forward Error Correction 

(FEC) mechanisms. The minimum network requirements specified for the interconnection to the 

MUPPET infrastructure will be refined and detailed during the project and will be investigated for 

different levels of QoS. 

The FAU could be interconnected to the MUPPET test bed in several different ways: One possibility 

would be to connect the FAU over IP (Figure 3.2-4); this could only be a temporary solution, 

however, as the application scenario of the FAU would have to scale down to a bandwidth of 50 Mbps 

per video source. 

Figure 3.2-4 Connecting the FAU to the MUPPET test bed over IP 

Another option could be to connect the FAU to the current G-WiN and GEANT networks via a GE 

over MPLS connection (Figure 3.2–5): 

Figure 3.2-5 Connecting the FAU to the MUPPET test bed via GE over MPLS and G-WiN



Page 39 of 68 

File: 


Depending on the developments of the national and international networks, there could also be other 

options in the near future for connecting the FAU to the MUPPET test bed: One possibility could be a 

connection of the FAU via VIOLA and GEANT2 (GN2) using Gigabit Ethernet and SDH (Figure 

3.2–4): 

Figure 3.2-6 Connecting the FAU to the MUPPET test bed via VIOLA 

As the GEANT2 (GN2) and X-WiN implementations become available, there could also be an option 

to either connect the FAU based on a dedicated SDH link between GEANT and the FAU (Figure 3.2- 

7) or to link the FAU to MUPPET using an X-WiN lambda connection (Figure 3.2-8). 

Figure 3.2-7 Connecting the FAU to the MUPPET test bed via GEANT with a dedicated SDH 

link



Page 40 of 68 

File: 


Figure 3.2-8 Connecting the FAU to the MUPPET test bed via lambda and X-WiN



3.3 Northern Europe test bed 

3.3.1 Background 

Page 41 of 68 

File: 


The Acreo National Broadband Test bed is build primarily to support Swedish and International 

research and industry. 

The test bed consist of three major parts: 

• Advanced service testing in Hudiksvall 1 , including TV, telephony and Internet connectivity, and 

with a planned extension to HDTV. 

• Transmission tests on a link between Hudiksvall and Stockholm 

• GMPLS test in Stockholm 

3.3.2 Test bed description 

Figure 3.3-1: ACREO National Broadband Test Bed 

The description of the Acreo National Broadband Test bed is focusing on the MUPPET related 

aspects, e.g. are the experiences of the Test Pilot customers in Hudiksvall not addressed. 

1 Hudiksvall is a Swedish town about 450 km north of Stockholm.



3.3.3 Architecture 

Page 42 of 68 

File: 


The Acreo National Broadband Test bed is build according to the GMPLS architecture described in 

“Generalized Multi-Protocol Label Switching Architecture” (draft-ietf-ccamp-gmpls-architecture- 

07.txt). Although this document is still an Internet Draft, it is approved by the IESG as a Standards 

track RFC and waiting for publication in the RFC editors queue. 

The GMPLS architecture is a multi-layer-architecture, meaning that a common control plane 

potentially controls several data planes. 

3.3.4 Networking technologies 

The test bed is built to primarily test transparent optical networking technologies, including control of 

multiple layers (IP/ETH/WDM) by means of GMPLS. This is done in a network where all nodes run a 

common control plane and it is possible to establish connectivity over several layers, e.g. an Ethernet 

VLAN between two switches that are interconnected through an OXC. The common control plane 

controls routers, switches and OXCs and the connectivity (VLAN) from the router to the switch and 

from the switch (VLAN/WDM) to the OXC that switches on the lambda-level. 

CPE 

CPE 

STB CPE 

STB CPE 

VoIP STB CPE 

VoIP STB CPE 

VoIP STB 

VoIP STB 

VoIP 

VoIP 

Ericsson Lab Network 

Hudiksvall 

City 

Network 

Sånglärkan 

L2 

L2 Eth 

L2 

Eth 

Vallvägen 

Protected WDM 

transmission link, 

380 km 

Services Services 

Eth 

Eth 

Edge 

Router 

Knösta 

L3 

L3 

Eth 

L2 

Management 

Main Node 

Eth 

Hudiksvall 

L3 

Lab node 

Edge 

L3 

Router 

Management 

Services Services 

Acreo 

Kista 

L2 

Lab node 

Mo 

L3 L3 

Eth 

CWDM 

Figure 3.3-2: Test bed Hudiksvall: Focus on Access 

Sollentuna 

Energi 

L2 Network



Intra Kista 

SCINT 

Juniper 

M5 

SCINT 

Acreo 

Juniper 

M5 

DTM 

OXC 

Extreme 

Black 

Diamond 

3.3.5 Control plane 

V 

H 

K 

DTM 

Juniper 

M5 

DTM 

OXC 

DTM 

S 

H 

DTM 

Page 43 of 68 

File: 


Extreme 

Black 

Diamond 

Extreme 

Black 

Diamond 

Figure 3.3-3: The Stockholm Network 

K 

Free Lambda 

DTM 

GbEthernet 

GbE SCINT 

Lumentis 

GMPLS enabled 

DWDM Metro 

OXC 

AMT 

Juniper 

M5 

SCINT 

The Acreo Test bed control plane is based on the extensions of IETF routing protocols (OSPF and 

BGP) and the IETF signalling protocol for GMPLS; RSVP-TE. This is a multi-layer control plane, 

meaning that both L3, L2 and L1 connectivity is set up through the same control plane. 

3.3.6 Data plane 

The data plane is currently built on WDM, Ethernet and IP in the core network, towards the customers 

(test pilots) Acreo run single channel wavelengths and Ethernet.



3.3.7 Context 

Page 44 of 68 

File: 


The choice of technology is not accidental, but very much modelled on existing metro networks and 

broadband islands in Sweden. The idea here is to meet some key requirements from the Swedish 

networking industry. 

3.3.8 Interconnections 

3.3.8.1 Local NRENs 

The connectivity through the Nordic (NORDUNET) and Swedish NREN (SUNET) to GEANT is still 

an issue to solve. Acreo will request a GE from our lab to GEANT (and settle for a FE or lower if 

necessary). 

3.3.8.2 Control Plane 

Our interfaces to other networks are through Juniper routers, the Juniper router will terminate the 

control and switch the data plane. 

There are also issues around control plane incompatibility due several standardisation efforts. It is 

possible, but not very likely to find a control plane converter. It is not currently seen as possible for 

Acreo to take on such an effort. 

The Juniper router currently has support for the following GMPLS functions/protocols: 

- RSVP-TE for GMPLS: RFC 3473 

- OSPF-TE for GMPLS: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt 

- SONET-SDH extensions: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt 

- Signalling for non-adjacent RSVP: draft-ietf-mpls-lsp-hierarchy-08.txt 

- GMPLS overlay: draft-ietf-ccamp-gmpls-overlay-04.txt 

- Others: RFC 3471, draft-ietf-ccamp-gmpls-routing-09.txt 

3.3.8.3 Data plane 

The data plane as described in this section is still very much an open issue, our first take is that Acreo 

will try to find connectivity “the obvious way”- through SUNET and NORDUNET to GEANT. Today 

Acreo is unsure what type of connectivity that will give. There is a risk that it will be on the level IP 

only. Acreo is looking for points of presence of GEANT to see if there are other options. 

One possible solution will be to look at tunnelling Ethernet through an IPSEC or GRE tunnel if only 

IP is available. This has been done before but will nevertheless take some implementation effort. 

With extreme luck Acreo will be able to meet an October deadline for data plane connectivity to the 

MUPPET partners, realistically Acreo can do this before end of year. 

3.3.9 Possible test/demos 

Acreo has several goals that would be possible to implement in the MUPPET project, e.g.: 

• To establish a control plane that can establish connectivity from a point in our network, across 

nodes in our network, across one or several other networks to a remote termination point. It is 

obvious that this needs to be implemented in several steps.



Page 45 of 68 

File: 


• Given that the data plane is Ethernet, try to set up a VLAN across to a site in another test bed, 

preferably using a third test bed as intermediary. 

3.3.10 Future 

In the future Acreo sees a network where control of all or several layers are integrated, sometimes this 

is called IP / Optical Integration. There might be several different paths to such a network. This is for 

further discussion. 

3.3.11 DTU 

DTU 

The Technical University of Denmark (DTU) is one of Northern Europe's leading universities, and the 

operator of the Danish Research Network, DAREnet, is located at the university’s premises. Hence, 

the connections to the Nordic countries through NORDUnet, an international collaboration between 

the Nordic national networks for research and education, are terminated at DTU. 

For experimental activities NORDUnet offers the NorthernLight network [18], which is a Lambda 

network facility connecting Stockholm with Copenhagen, Oslo, Amsterdam and Helsinki. Figure 

3.3-4 shows the NorthernLight experimental network. 

Figure 3.3-4: NorthernLight Lambda network for connecting DTU with GÉANT. Source: 

http://www.nordunet.net/development/northernlight.html] 

In each POP a Cisco ONS 15454 is equipped with a number of GbE ports configured to allow GbE 

channels between any two nodes in the network. Thus, DTU is connected to Stockholm through a 

GbE connection, terminating in Stockholm at the same physical premises as DANTE and SUNET. 

The ASON UNI is obtained by tunnelling the signalling through the GbE layer 2 network. 

There are at the moment no specific application requirements except from GRID computing, which is 

a significant activity at DTU and some the institutes in its surroundings.



3.4 Western Europe test bed 

Page 46 of 68 

File: 


The TID test bed for Muppet (Western Europe Test bed) is an IP/MPLS network with the architecture 

shown in Figure 3.4-1. It is composed of Layer-2 switches and GigaSwitchRouters GSR, with a 

specific MPLS area, supporting FE and GBE interfaces for internal connections and an STM1 

155Mbps ATM interface for the external interconnection to RedIRIS, with a PVC 34 Mbps defined 

for Muppet traffic forwarding. 

In the near future this ATM connection will probably be changed to a connection based on VLANs 

using Gigabit Ethernet link. With the collaboration of RedIRIS, it will be possible to provide a GBE 

link between TID test bed and RedIRIS, so the Ethernet frames will go directly across the link, 

increasing the efficiency in the transport of IP traffic between TID test bed and other Muppet's 

partners via RedIRIS-Geant. 

The TID Test bed offers the following functionalities: 

• Layer-2 and layer-3 connectivity based on Ethernet, using standard protocols to optimise the paths 

of data: STP for layer-2 and OSPF for unicast routing at layer-3. Other functions like IP-policies 

and routing-policies are supported, greatly increasing the routing capabilities in the test bed. 

• MPLS support, using different signalling protocols like LDP and RSVP and allowing the 

definition of different types of tunnels LSP: 

o Static-LSP, configuring node-by-node the path of the LSP. 

o Dynamic-LSP, including “explicit-LSP” and “CSPF-based LSP”, in which different 

conditions and limitations can be imposed to create the path of the LSP (nodes, 

bandwidth, type of interfaces, hops, colour and so on). Other issues like secondary-path 

and fast-reroute are also supported, enhancing the MPLS functionality of the test bed. 

• Layer-3 VPN based on MPLS. This functionality allows service providers to offer to their 

customers VPN services with an IP backbone, using MPLS for forwarding VPN traffic and using 

BGP for distributing VPN routes. This mechanism allows: 

o Service providers to increase scalability and flexibility. 

o Customers to remove the need to build their own IP backbone and also to get free of 

inter-site connection issues. 

o Customers to use private IPv4 addresses, removing the restriction for the customers to use 

globally unique addresses range. 

• Layer-2 VPN based on MPLS. This functionality allows the encapsulation and transport of layer- 

2 (Ethernet) frames across the network according to Martini Draft. Three specific functions are 

supported in the test bed: 

o Point-to-point LSPs for Virtual Leased Line services (VLL). This allows transport of 

Ethernet frames between two end points, so these points keep connected at layer-2 in a 

transparent way.



Page 47 of 68 

File: 


o Point-to-multipoint LSPs for Transparent LAN services (TLS). This function allows 

transport of Ethernet and VLAN traffic for multiple sites that belong to the same layer-2 

broadcast domain. Static and dynamic label assignment is allowed for the virtual circuits 

labels. 

o Virtual Private LAN Services (VPLS), which use TLS functions to interconnect the layer- 

2 traffic of different customers into the MPLS network, creating LSP tunnels through the 

MPLS area for each client, which are provisioned for client-specific service. Thus, with 

VPLS the MPLS area appears as a logical layer-2 switch to each client site. 

• Multicast support, allowing the possibility to forward IP-packets to a group of receivers, which 

have explicitly expressed interest for a multicast content. Multicast routing is used to transmit 

traffic from a source to a group of receivers. Any host in TID test bed or in another Muppet 

partner’s test bed can be a source, and the receivers can also be in any test bed (TID’s one or 

another partner’s one) as long as they are members of the group to which the multicast packets are 

addressed, so only the members of a group can receive the multicast data stream. Multicast 

routing protocols are supported: PIM-SM, SSM, IGMP, IGMP-snooping allowing the optimal 

forwarding of the multicast frames and packets across the network, according to the changing 

location of sources and receivers so the distribution paths adapts to that. 

• Quality of Service support. Different mechanisms related to QoS are supported that allows 

implement the DiffServ functions in the test bed. These mechanisms are the following: 

o Traffic prioritisation, to differentiate between several types of traffic, segregating them 

into different priority queues. When the traffic has been identified and classified, it can be 

assigned to any of the priority queues to ensure the proper prioritisation. Priority can be 

allocated based on any combination of layer-2 (802.1p), layer-3 or layer-4 traffic. Strict 

priority and other mechanisms like Weighted-fair-queuing are also supported. 

o ToS rewrite, which provides access to the ToS field in an IP packet (or DHCP in 

DiffServ) in order to mark it with the desired value. In the access point to the network the 

packets are first of all classified to differentiate the traffic flows, rewriting (marking) the 

ToS/DHCP value, thus allowing the traffic prioritisation into the network according to the 

defined QoS scheme. 

o Rate limiting, which is a mechanism devised to control the bandwidth used by the 

incoming traffic to the network, on a per-flow basis. A flow meeting certain criteria can 

have its packets re-prioritised or dropped if its bandwidth usage exceeds a specified limit. 

This function can be applied, for example, to control the input traffic of users, according 

to their SLAs. 

o WRED. This mechanism is used to alleviate traffic congestion by randomly dropping 

packets once the traffic exceeds a defined limit but before the congestion thresholds. 

When applied to a port it can prevent the congestion in it, reducing latency on that port 

and greatly improving TCP protocol behaviour. 

• Security support and other. Security is based on the configuration of ACL (access lists) and filters 

that helps to control access and filter traffic going through the network. The ACLs allow to define 

traffic profiles in the access points of the network based on layer-3 and layer-4 parameters, in 

order to filter the traffic, to permit or deny it, dropping the undesired one. Layer-2 security filters 

are also supported, performing filtering based on MAC addresses. Other functions related to 

security like password authentication, Secure-Shell protocol and port-based authentication are 

also supported. Additionally functions like NAT are supported, which allows for the mapping of



Page 48 of 68 

File: 


IP addresses used within TID test bed, to different IP addresses used within another partner’s 

network. 

Figure 3.4-1: TID-Test bed Muppet



3.5 Eastern Europe test bed 

Page 49 of 68 

File: 


Eastern Europe test bed purpose is to reflect the simplified, low-overhead architecture of multi-gigabit 

networks that are being built by many NRENs. These networks are usually built on dark fibres with 

relatively cheap and simple transport (Gigabit Ethernet/10 Gigabit Ethernet over (D/C)WDM 

(optional). By their nature these networks are not equipped with strict QoS/BoD mechanisms, nor 

ASON/GMPLS features what makes them a bit difficult for integration with ASON/GMPLS 

technologies for end-to-end service. However even more sophisticated mechanisms included in 

Ethernet switching devices allows them to preserve some kind of QoS, by using traffic prioritisation 

and bandwidth reservation 

For the purpose of MUPPET project, PSNC will provide its test bed in two phases: 

Phase 1 – test bed comprised of data channel, data source/sink, control channel and domain controller 

Phase 2 – real GE switch-based test bed with all elements of Phase 1. 

The test bed in both phases 1 & 2 will be connected to MUPPET test bed via the following network 

domains: 

• POZMAN network (Gigabit Ethernet) 

• PIONIER network (10GE) 

• GEANT network (IP/MPLS currently) 

We discuss the test bed topology, functionality and interconnection below: 

3.5.1 Eastern Europe test bed phase 1 

EE test bed in phase 1 will use PC machines connected to the rest of MUPPET test bed. Two 

machines with different functionality will be directly connected to test bed. 

GE (UNI) domain controller will serve as control channel client (be it UNI or other protocol), 

allowing to process control messages incoming from and sent to MUPPET test bed. In result, 

domain controller will create internal commands configuring another PC. 

PC acting as a data source/sink will initially simulate future GE network. It will receive 

configuration commands and setup appropriate filters to simulate realistic data path behaviour. 

Such test bed construction will allow for implementation of following functionality: 

• topology exposure 

• data connection request 

• data connection teardown 

• data connection modification 

• status enquiry



MUPPET 

Control (UNI?) 

3.5.2 Eastern Europe test bed phase 2 

Page 50 of 68 

File: 


DATA PC acting as data source, sink, 

simulating future GE network 

Internal communication 

Figure 3.5-1: Test bed Phase 1 

GE (UNI) domain controller 

In the second phase the network simulator will be replaced by a real GE-switch based test bed, 

allowing to create real VLANs with required quality between other MUPPET clients and local EE 

test bed clients. This phase will require more complex functionality of domain controller, which 

will have to interface with vendor-specific management interface of GE switches. 

The test bed shall support the same set of control messages as phase 1. 

MUPPET 

DATA 

Control (UNI?) 

Internal communication 

GE (UNI) domain controller 

Figure 3.5-2: Test bed Phase 2 

Depending on the project evolution and requirements, additional devices can be connected as the 

client machines, including: traffic generators and analysers, audio/videoconferencing equipment, 

streaming servers and grid clients.

4 Test bed interconnections 

This chapter contains a first attempt to describe the planned or potential interconnections of the local 

test beds to the NRENs from both network domain perspectives and additionally a short description of 

the functionalities, which can be provided to the MUPPET test bed by the NRENs and GEANT. 

Figure 3.5-1 and Figure 3.5-2 are showing a first draft of the MUPPET test bed topology, including 

the characteristics of each local test bed and the planned interconnections. 

TILAB 

ASON/ GMPLS 

network 



test bed 


test bed 

IP/MPLS 

network 


test bed 

DT 

FAU 


test bed 

ASON/ GMPLS 

network 


test bed 

PSNC 

Ethernet 

network 

ACREO 

UNI 

DTU 

GMPLS 

network 

Figure 3.5-1: Proposed lab interconnections to build a MUPPET pan European test bed 



test bed 

ACREO 

DTU 

RedIRIS 


test bed 

GARR 

SUNET 

NORDUnet 

DARENET 

GEANT 

TILAB/ 

Telecom Italia 

DFN 


test bed 

PIONIER 

FAU 


test bed 


test bed 

PSNC 

T-Systems 

Deutsche Telekom 

Figure 3.5-2: Resulting interconnections for the MUPPET test bed



4.1 Southern Europe test bed - GARR 

Interconnection 

Page 52 of 68 

File: 


The interconnection between the TILAB test bed in Torino and the Italian NREN (GARR) is at the 

moment not yet in place and will be developed in the next months according to the project plan. 

For the time being a set of different options has been highlighted, also by matching the foreseen 

requirements of the experimental activities with the project roadmap in terms of gradually enhancing 

the interconnections of the five local test beds as described in the Technical Annex. 

Said that, the interconnection types that have been listed among the different options and could be 

available in the future are: 

• ATM interconnection (34 and/or 155Mbit/s) to the GARR POP in Torino. This could be a 

first and quick step to guarantee a good level of bandwidth in few months to start as soon as 

possible some experimental activity. 

• Ethernet interconnection to the GARR POP in Torino. This could be achieved in two ways: 

o by ordering a commercial Ethernet (Fast Ethernet and/or Gigabit Ethernet) service. 

o by having the availability of one or more dark fibre pairs that will physically link the 

GE interfaces on a switch/router in TILAB to the GE interfaces on a router at the 

GARR POP. 

The second way, although preferable from the point of view of the connection flexibility, 

could require much more effort and time than the first one. 

Finally it should be mentioned that the only interconnection today available to a local MUPPET test 

bed is the control plane (E-NNI) interconnection to DT (T-System labs in Berlin) based on an IPSec 

tunnel over the Internet. 

Interface & Network Functionalities 

For what concerns the external interface functionalities that will be available towards the other local 

test beds, these are in principle the same that will be implemented within the TILAB test bed: 

• UNI-N 1.0 R2 (UNI 2.0 for GE interfaces when available) 

• E-NNI as per OIF2002.476.21, OIF2003.179.08 and OIF2003.259.02. 

on the control plane, and: 

• STM-1, STM-16 and GE interfaces 

• Ethernet mapping over SDH, in compliance with GFP, VCAT, LCAS (G.7041, G.707, 

G.7042) 

on the data plane. 

Finally the network in TILAB will have two switching functionalities: 


• Fibre Switching Capability (FSC) 

4.1.1 Southern Europe test bed access points 

Two GARR Point of Presence are of interest for the MUPPET project, in the towns of Milano and 

Torino.



Page 53 of 68 

File: 


GARR network in Milano is based on three main PoPs (Caldera, Lancetti and Colombo) connected by 

dark fibres lit by coarse WDM equipments. The PoP located in Via Lancetti hosts the international 

connection to GÉANT and circuit to Rome and Bologna. The PoP thus provides very high speed 

switching between Italy and all the other three test beds in Europe. 

The Torino PoP is currently hosted in the Physics department of the university of Torino and is 

connected by a 2,5 Gb/s SDH circuit to Milano providing ample capacity. Local interconnections 

between the TILAB tested and the other institution can be accepted in various formats, with 

preference for Gigabit Ethernet. 

GARR provides also Gigabit/s connectivity to GRID computing centres in Italy, for example INFN- 

CNAF in Bologna, allowing seamless collaboration and integration if needed. 

4.1.2 GARR 

Consortium GARR (short name GARR) is an Association under the Italian law, established by the 

national Academic and Research Community. The aim of Consortium is to plan, manage, and operate 

the Italian National Research and Education data transmission Network by implementing the most 

advanced technical solutions and services. 

The GARR network connects all the research centres and institutes and all the universities in Italy, at 

present about 350 institutions. GARR has just started a new project to connect all Italian schools of all 

grades. 

The current version of the GARR network provides connectivity to world-wide research networks 

through a 10 Gb/s circuit to the GÉANT pan-European network and has separate connections in 

Milano and Rome to the general Internet at multiple of 2.5 Gb/s. 

Its core backbone is a mesh based on Wave Division Multiplexing and SDH leased circuits of up to 

2,5 Gb/s connected by state-of-the-art routing and switching equipment. Figure 4.1-1 depicts the 

backbone at September 2004. Users’ access link speed ranges from 2 Mb/s up to 1 Gb/s. It provides to 

its user base of about 2 million researcher and students transport of both IPv4 and IPv6 protocol and 

advanced services like multicast and quality of service. 

The network is evolving rapidly and it is increasing the amount meshing between its PoPs and the 

number of PoPs. 

Up to date information about GARR network topology can be found at: http://www.garr.it/ 

Capability of transport network functions available for MUPPET 

GARR can offer standard Best Effort IPv4 and IPv6 connectivity up to Gigabit speed. In addition the 

network can offer dedicated capacity in form of layer 2 or layer 3 MPLS links using a combination of 

AtoM and CCC technologies. Capacity assurances can be defined for the links using appropriate 

Quality of Service techniques, like Premium IP.



Figure 4.1-1 The GARR Network (Sep 2004) 

Page 54 of 68 

File: 

MUPPET_D31_TestBedOverview_Sep04



4.2 Central Europe test bed - DFN 

Page 55 of 68 

File: 


This chapter describes the interconnections to the DFN network in Berlin (DT lab location) and in 

Erlangen (location of application lab of FAU). 

4.2.1 Central Europe test bed access points 

MUPPET central Europe test bed will have the following external interface functionalities: 

Control plane functions: 

• UNI-N 1.0 R2 (future options: UNI2.0 Ethernet) 

• OIF E-NNI with external signalling/routing 

• Support of switched connection (initiated by UNI-C) configurations over multiple network 

domains 


domains 

Data plane functions: 

• Interfaces: STM-1/16 (LR) and GE (LX) 







domains 

The roadmap to continuously increasing the test bed interconnections from DT lab to the other 

MUPPET local test beds in terms of bandwidth but also related to the network functions is at a first 

approach as follows: 

Today available: 

• ·Control plane E-NNI interconnection to the Southern Europe Test Bed/TILAB based on an IPSec 

tunnel over the public Internet. This interconnection is up running since April 2004, when the OIF 

World Interoperability Tests and Demonstration were performed 

• Best effort IP interconnection up to 2 Mbit/s, fixed traffic volume per month, over the DFN 

network 

Beginning 2005 

• Potentially available up to STM-1 interconnection (BRAIN project, see chapter 4.2.2) 

For enabling a most flexible access to the DFN PoP in Berlin a dark fibre interconnection is currently 

under investigation.



4.2.2 DFN 

Page 56 of 68 

File: 


The Verein zur Förderung eines Deutschen Forschungsnetzes e.V. – known as DFN-Verein – is 

supporting the science and research in Germany with a high performance communications 

infrastructure. About 600 universities, research and scientific institutions are connected to this 

network. Access of up to 10 Gbit/s allows at present mainframe computers to be used for distributed 

applications for example in climatic research, in particle physics or in vehicle and aeroplane 

construction. High-performance links to the Internet2-initiative ABILENE and to the US-Internets (12 

Gbit/s in total), as well the connection to the European research network GÉANT (10 Gbit/s) enable 

science and research to overcome network barriers. 

The G-WiN is based on WDM and SDH technology. The meshed infrastructure is adopted to the 

traffic streams and optimised regularly. The dominant trunk capacity is 10 Gbit/s. Every of the 27 

core nodes has at least 2 links to other core nodes for reliability. The core nodes are equipped with 

high performance routers (GSR) and additional switching devices and workstations for service 

provisioning and statistic and measurement purposes.



Page 57 of 68 

File: 


Figure 4.2-1: Capability of transport network functions available for MUPPET 

The most important service today is the DFNInternet, it provides IP connectivity with an access speed 

of up to 2,5 Gbit/s. However, distributed computing - so-called Grid computing – promotes the 

continuous expansion of existing network services. In special cases Gigabit Ethernet links can be 

provided between Grid locations in Germany and also internationally. If no physical link is available 

the “Any Transport over MPLS” (AToM) encapsulation is used inside the G-WiN. For international 

links a combination with the CCC service in GÉANT was tested and used successfully. 

Description of the POP to be used by the Central Europe test bed



Page 58 of 68 

File: 


The G-WiN core node in Berlin is located at the Konrad-Zuse-Institut (ZIB) in Berlin-Dahlem. It 

provides 10 Gbit/s links to Hamburg and, more important in relation to MUPPET, to Frankfurt/Main 

(GÉANT access). TSI is connected to the G-WiN (34 Mbit/s contracted). This access link can 

certainly be used for the beginning providing just IP connectivity. The maximal speed available would 

be 155 Mbit/s at this access link, which belongs to the Berlin fibre network BRAIN. 

The G-WiN part of BRAIN is described at http://www.brain.de: 

Figure 4.2-2: G-WiN Network Topology 

The access of the German Telekom is marked as T-Nova. The node between the T-Nova and ZIB (TU 

Berlin) does not provide GE facilities at the moment. If no other (physical) link is available an IP 

connection is the only solution that can be offered for now. 

However, the tendering process for the successor network (X-WiN) is planned to be completed later 

this year and the X-WiN will be operational 1 st of January 2006 by latest. It is to be expected, that this 

will enable more options. 

4.3 Northern Europe test bed - NORDUnet 

4.3.1 Northern Europe test bed access points 

The Acreo interfaces to other networks are through Juniper routers, the Juniper router will terminate 

the control and switch the data plane.



Page 59 of 68 

File: 


There are also issues around control plane incompatibility due several standardisation efforts. It is 

possible, but not very likely to find a control plane converter. It is not currently seen as possible for 

Acreo to take on such an effort. 

The Juniper router currently has support for the following GMPLS functions/protocols: 

- RSVP-TE for GMPLS: RFC 3473 

- OSPF-TE for GMPLS: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt 

- SONET-SDH extensions: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt 

- Signalling for non-adjacent RSVP: draft-ietf-mpls-lsp-hierarchy-08.txt 

- GMPLS overlay: draft-ietf-ccamp-gmpls-overlay-04.txt 

- Others: RFC 3471, draft-ietf-ccamp-gmpls-routing-09.txt 

4.3.2 NORDUnet 

The connectivity through the Nordic NRENs (SUNET/NORDUNET) to GEANT is still an issue to 

solve. We will request a GE from our lab to GEANT (and settle for a FE or lower if necessary). 

4.4 Western Europe test bed - RedIRIS 

Right now, the interconnection between TID and RedIRIS is based on an STM1-155 Mbps ATM link. 

Specifically, to interconnect the Muppet test bed in TID and RedIRIS a 34 Mbps ATM permanent 

virtual circuit PVC is established between the corresponding nodes in these networks. This circuit is 

available to support traffic from/to the test bed in TID and other remote test bed interconnected via 

GEANT, specifically TILAB according to the proposed test bed interconnections included in the D3.1 

draft. 

The physical and logical interconnection schemes between TID and RedIRIS are shown in Figure 

4.4-1 and Figure 3.1-2. They are based on the following elements: 

TID test bed: 

• An ATM switch (N1) supporting the interface STM1-155Mbps/ATM with the distant node R1 in 

RedIRIS, using a single mode optical fibre. This switch connects to an internal router (N2) also 

with an STM1-155Mbps/ATM interface, forwarding layer-2 ATM cells directly. This link uses 

multimode fibre. 

• A router (N2) supporting an interface STM1-155Mbps/ATM interface with the ATM switch N1 

described above. This router also has a Fast Ethernet interface (100 Mpbs), which allows the 

connection to the rest of the test bed supporting Ethernet traffic, so this router (N2) implements 

the Ethernet-ATM adaptation according to RFC-1483. In this router (N2) an ATM PVC 34 Mbps 

is defined, connecting the N2 node with the distant R2 node in RedIRIS. 

RedIRIS network: 

• An ATM switch (R1) supporting the interface STM1-155Mbps/ATM with the distant node N1 in 

TID test bed, using a single mode optical fibre. This switch connects to an internal router (R2) 

also with an STM1-155Mbps/ATM interface, forwarding layer-2 ATM cells directly. This link 

uses multimode fibre.



Page 60 of 68 

File: 


• A router (R2) supporting an interface STM1-155Mbps/ATM interface with ATM switch R1 

described above. In this router R2 an ATM PVC 34 Mbps is defined, connecting the R2 node with 

the distant N2 node in TID test bed. 

• The internal connection of N2 node with the rest of the NREN network and the connection with 

Geant is to be defined by RedIRIS so the final objective is to forward the ATM traffic 

(corresponding to the PVC 34 Mbps originated in TID test bed) to Muppet partners in a 

transparent way. 

In the near future the ATM connection will probably be changed to a connection based on VLANs 

using Gigabit Ethernet links (GBE), but this point is still under discussion with RedIRIS staff. In a 

future stage the possibility to provide this GBE link between TID test bed and RedIRIS will be 

hopefully solved allowing the Ethernet frames to go directly across the link with VLANs, increasing 

the efficiency to transport IP traffic between TID test bed and other Muppet’s partners via RedIRIS- 

Geant. 

This new scenario has to be discussed with RedIRIS in order to detail the TID test bed interconnection 

and to specify and define the corresponding tests that could be implemented. 

Figure 4.4-1: fig2_RedIRIS-TID_Connect-Muppet_ATM_phy



Page 61 of 68 

File: 


Figure 4.4-2: fig3_RedIRIS-TID_Connect-Muppet_ATM_logic 

4.4.1 Western Europe test bed access points 

The interconnection between TID test bed (Western Europe test bed) and the Spanish NREN RedIRIS 

will be based on the STM1-155Mbps ATM link now installed and configured between them, so the 

traffic will be transported with a defined PVC 34Mbps. Nowadays, the interfaces STM1-155Mbps 

ATM in the access points of TID and RedIRIS are installed and running properly, so it is only 

necessary to configure the PVC between the corresponding nodes in both networks. 

4.4.2 RedIRIS 

RedIRIS is the Spanish Academic and Research Network. It connects more than 260 centres, 

mainly Universities and Research Centres. Now RedIRIS has a 10Gbps POS link to the research 

worldwide Community (link to GEANT, access to Abilene, ESNet, Canarie and all the European and 

American research Networks), with a 2.5 Gbps core inside Spain. It's a meshed network with a PoP in 

each one of the Autonomous Regions of Spain, 18 in total. The link access goes from 2 Mbps to 

GigaEthernet.



Figure 4.4-3: RedIRIS Network 

Page 62 of 68 

File: 


In order to promote Education and Research Global Connectivity, we participate in two 

important projects funded by the European Commission: ALICE, which main objective is to develop 

a network infrastructure between the Research Networks of South America and also with GEANT. 

The other project is EUMEDCONNECT with the same purpose but applied to the countries of the 

South side of the Mediterranean Sea. This will create the biggest Research and Academic community 

in the world, including GEANT, South America, North Africa and the close ties of Internet2. 

With the commercial world, RedIRIS have peerings with the Spanish commercial providers in the 

ESPANIX, the Spanish Internet Exchange Point, some of them IPv4 and IPv6, and direct peerings 

with Telia and Global Crossing, for the Commodity Internet.



Page 63 of 68 

File: 


Figure 4.4-4:RedIRIS connections to other networks 

4.4.2.1 Capabilities available for MUPPET 

RedIRIS provide connectivity to all the centres with IPv4 and IPv6 native access, with a 2.5 

Gbps core. GigaEthernet links can be provided to Universities and Research Centres. It offers 

advanced services like multicast, Quality of Service, and VPNs inside the network. LSPs using CCC 

has been tested successfully in projects like ATRIUM, through GEANT, and other internal projects; 

also, we are using L2 VPNs inside the network. With all these elements, the network can provide L2 

connectivity when necessary. 

4.4.2.2 Description of the POP to be used by TID test bed 

The POP is located in Madrid, in RedIRIS premises. It is the Madrid RedIRIS PoP; with the 

main advantage that is located in the same premises as the RedIRIS core POP of the network, with the 

links to GEANT. So The Madrid POP has a direct 2.5 and Gigabit Ethernet links to the routers in 

charge of the GEANT links. Between the Madrid POP and the TID test bed there is a 155 link, with a 

34 Mbps PVC to be used now. There are no GigaEthernet facilities at the moment, but there will be 

more options for interconnections in the near future.



Figure 4.4-5:The Madrid POP 

Page 64 of 68 

File: 

MUPPET_D31_TestBedOverview_Sep04

4.5 Eastern Europe test bed - PIONIER 

OXC 

NNI 

(IPSEC) 

Eth/SDH/MPLS 

or Eth/SDH 

or Eth 

OXC 

Other testbed 

GEANT2 

ETH 

Test PC 

NNI 

(IPSEC) 

Eth/MPLS 

or Eth/SDH 

or Eth 

PIONIER 

GEANT2 BORDER 

DEVICE 

GEANT2 BORDER 

DEVICE 

Figure 4.5-1: Test bed Interconnections 

POZMAN 

EE Testbed 

UNI 

Test PC 

The test bed interconnection has been shown on the picture above. Current connection plan bases on 

the following assumptions: 

• Data (traffic) sources and receivers (Test PCs) in all test beds will be connected using popular 

Ethernet (FE, GE) technology 

• All data transfer will be performed using IP over Ethernet technology 

• No routing shall be implied between Test PCs (LAN-like connection) 

EE Test bed - POZMAN 

This interconnection will be built using dedicated Ethernet link or Ethernet VLAN with bandwidth 

guarantee. 

POZMAN 

Connection within POZMAN network will be set up using dedicated Ethernet link or VLAN with 

bandwidth guarantee.



Page 66 of 68 

File: 


POZMAN-PIONIER 

This interconnection will be set up using dedicated Ethernet link or VLAN with bandwidth guarantee. 

PIONIER 

Connection within PIONIER network will be set up using VLAN on over-provisioned network or 

VLAN with bandwidth guarantee. 

PIONIER - GEANT 

This interconnection setup will depend on available GEANT interfaces and GEANT transport 

infrastructure. Currently we are able to connect to GEANT via VLAN on over-provisioned link 

between PIONIER 10GE switch and GEANT Juniper M160 router 10GE interface. There is also the 

possibility to implement a QoS policy for that interface. 

GEANT – other test beds 

The direct requirement for interconnection to other test bed clients is to have these clients connected 

via Ethernet interface, and use Ethernet transport (i.e. Ethernet over SDH encapsulation with 

transition to native Ethernet at GEANT border device) 

4.6 GEANT 

4.6.1 The GÉANT network 

The GÉANT project is a collaboration between 26 National Research and Education Networks across 

Europe, the European Commission, and DANTE. DANTE is the project's co-coordinating partner. 

The project began in November 2000 and was originally due to finish in October 2004; however, 

because of the project's success, and in order to permit a smooth transition to the next generation of 

the network (GÉANT-2), the project has now been extended until 30 June 2005. The GN2 project has 

started on September the 1 st 2004. 

GÉANT principal purpose has been to develop the GÉANT network - a multi-gigabit pan-European 

data communications network, reserved specifically for research and education use. The project also 

covers a number of other activities relating to research networking. These include network testing, 

development of new technologies and support for some research projects with specific networking 

requirements. 

The GÉANT network connects to each NREN via an access link. These access links are also being 

continually upgraded, helping to ensure that bottlenecks between NRENs and the European backbone 

do not reduce the benefit of the network. 

Each participating NREN has one access link to the GÉANT network at speed up to 10 Gb/s SDH. 

GÉANT offers IPv4 and IPv6 connections and offers various services. 

Up to date information about DANTE network topology can be found at [19]



Figure 4.6-1: The GÉANT Network 

Page 67 of 68 

File: 


4.6.2 Capability of transport network functions available for MUPPET 

GÉANT offers two services of interest to MUPPET: 

IPv4 packet Quality of Service in the form of two classes of Premium IP and Less than Best Effort. 

Premium IP is implemented according to the DiffServ expedited forwarding per hop behaviour and 

guarantees the equivalent of a leased line; 

Layer 2 Virtual Private Networks, in the form of MPLS label switched paths. 

These two services can be combined with the equivalent services offered by the NRENs hosting the 

links to main MUPPET test bed sites to offer a test bed to test bed interconnection with QoS 

guarantees at layer 3 or Layer 2. 

The high speed of the GÉANT network allows these links to grow up to Gigabit speed. 

All the four NREN hosting the links to the MUPPET test bed, i.e. RedIRIS in Spain, GARR in Italy, 

DFN in Germany, PSNC in Poland, NORDUNet for the Nordic countries, are connected at 10 Gbit/s 

to GÉANT, ensuring that testing at high speed can be planned in a near future. 

The successor of GÉANT will offer even greater link speed and richer services, in particular in term 

of provisioning time and level of automatism.



5 Conclusion 

Page 68 of 68 

File: 


This deliverable “Test Bed Overview” represents a first step towards an integration of the five local 

test beds to a European scale network, by providing 

• A description of the overall design, the actual status and the functions provided to the MUPPET 

project and the interfaces/functions for the inter-test bed connections of the Southern-, Central-, 

Northern-, Western- and Eastern European local test beds, and 

• A first description of the potential test bed interconnections (and the application sites related to 

these), including the network functions provided by the NRENs and GEANT 

Therefore this deliverable builds the bases for the next activities, for the architectural investigations 

and for the practical implementation of the test bed interconnections and integration.

Deliverable D3.1 Test Bed Overview - Nobel 2

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?