Optical networking for e science applications
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Optical networking for e-Science applications PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

Optical networking for e-Science applications. Freek Dijkstra System and Network Engineering Group Universiteit van Amsterdam. Introduction. System- and Network Engineering group, Universiteit van Amsterdam Five research tracks Authentication, authorization and accounting (AAA)

Download Presentation

Optical networking for e-Science applications

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Optical networking for e science applications

Optical networking fore-Science applications

Freek Dijkstra

System and Network Engineering Group

Universiteit van Amsterdam


Introduction

Introduction

  • System- and Network Engineering group, Universiteit van Amsterdam

  • Five research tracks

    • Authentication, authorization and accounting (AAA)

    • Optical networking (circuit-switched networks)

    • Grid information management

    • Grid workflow management

    • Security (since this year)

  • Mostly funded by third parties: Dutch (BSIK), EU-projects. For example GigaPort project (SURFnet).


Glif community

GLIF community

A collaboration of national research & education networks (NRENs), promoting the paradigm of “lambda networking”

http://www.glif.is/


Lamda networking

Lamda Networking

Also known as:

  • Optical Networking

  • Hybrid Networking

  • Transport Networks

  • Optical Private Networks (OPN)

Providing circuit switched network connections to those applications/users that require so, while providing regular (routed) IP to most other applications/users.

A LightPath can be a dedicated Ethernet connection from Amsterdam to Chicago


User classes

User Classes

  • Lightweight users, browsing, mailing, home use

    Need full Internet routing, one to many

  • Business apps, multicast, streaming, VPNs, mostly LAN

    Need VPN services and full Internet routing, several to several + uplink

  • Scientific applications, distributed data processing, grids

    Need very fat pipes, limited virtual organizations, few to few, OPN

ΣC ≈ 100 Gb/s to 1 Tb/s

number of

users

ΣB ≈ 300 Gb/s

ΣA ≈ 160 Gb/s

A

C

B

1-10 GigE

ADSL

Bandwidth requirements

Source: Cees de Laat, UvA


Example applications

Example Applications

Physics

  • Nuclear Physics (LHC)

  • Astrophysics (mostly radio astronomy, e.g. e-VLBI, SCARI)

    Visualization

  • Remote Visualization (Dead Cat demo, UvA)

  • Remote Instrumentation (Electron Microscope)

  • High definition video streams (EVL, Cal-IT2)

  • Distribution of movies (CineGrid)

  • Analysis of video data (e.g. MultimediaN)

    Large file transfers

  • User-driven file transfers

  • Nightly backups

  • Transfer of medical data files (e.g. MRI)

  • Magneto encephalography (MEG) modeling;

    Current demand in SURFnet

  • Optical Private Networks (e.g. Hogescholen)


Example lightpath

Example LightPath

Landspeed record

Single Stream TCP:

Tokyo – Chicago – Amsterdam –

– NY – Chicago – Tokyo


Getting a lightpath in practice

2 days

5 days

5 days

3 days

2 days

+

A few weeks

Getting a Lightpath in practice

  • Manual: e-mail your network provider or NREN (e.g. SURFnet)

    • Applications often don’t know what network they need/want.

  • Path finding

    • Usually done manually, by contacting other NRENs. More complex than Internet routing (more constraints)

  • Automatic path setup

    • SURFnet orders SARA to manually configure the path.

  • Fault detection

    • End user sees a problem with the connection, but it is unclear in which domain(s) causes the problem(s)

  • End node configuration

    • Which IP range to use? How to tune TCP?


End node configuration

End Node Configuration

  • Problem: After a LightPath has been created, end-users struggle to manually configure their end nodes.

    • TCP does not perform well for high bandwidth • delay product.

    • IP addressing: DHCP will not work out-of-the-box, since it is not clear which domain should run it.

  • Automated Solution for IP addressing

    • Use Zero Configuration: Automatic configuration of network without a central authority

    • Solution: use self-assigned IP addresses

    • Use multicast DNS to link IP address and hostname and visa versa

    • Use DNS Service Discovery to find out the host name where services are running

Cluster domain 1

Cluster domain 2

LightPath


Zero configuration

Zero Configuration

  • Use Zero Configuration protocols

    • Automatic configuration of IP addresses

      • RFC3927 for IPv4 or RFC2462 for IPv6

    • Name lookup of hosts

      • Multicast DNS (mDNS) or Link-Local Multicast Name Resolution (LLMNR)

    • Discovery of services

      • DNS Service Discovery (DNS-SD), or Simple Service Discovery Protocol (SSDP, in UPnP), or Service Location Protocol (SLP) (or even UDDI, SDP, Salutation, or Jini)

  • Three software suites, used multiple implementations:

    • RFC3927: ZCIP and autoip for Linux, native in OS X and Windows

    • mDNS: mDNSResponder, tmdns, and Porchdog mDNS

    • hooking gethostby*() to use mDNS: tmdns and libnss_mdns


Igrid 2005 demonstration

iGrid 2005 Demonstration

  • Demonstrated auto-matic IP configuration

  • Used broadcast ping to discover all hosts

  • Used multicast DNS and gethostbyaddr() hook to discover hostnames

  • Tested IP collisions

  • Also demonstrated service discovery through DNS


Applicability

Applicability

Grid 2005 demonstration taken as sample applications


Path finding

Path Finding

Many constraints (more than regular Internet)Need not only topology information, but also scheduling, and policy. In addition, technology incompatibilities may block a certain path.

Network DescriptionNot as trivial as it seems (multi-domain, multi-layer). Due to changing technology, what you want to describe changes over time.

Network generation to test efficiency of path finding algorithmsReal-world networks don’t look like a simple Erdős-Rényi random graph, but have a logarithmic or polynomial degree-distribution. It is yet unclear what the properties of real-world multi-layer networks are.

Path finding algorithmMulti-domain GMPLS proposes a link state algorithm (OSPF-TE), but the only two successful multi-domain protocols (SS7 and BGP) use path vector algorithms.


Routing example

Routing: Example

GE is adapted in STS-24c

(SONET channel thru OC-192)

U. Calgary

CA*net

Canada

UvA

GE

OC-192

GE

OC-192

Star

Light

Chicago

MAN

LAN

New York

NetherLight

Amsterdam

OC-192

OC-192

GE is adapted in STS-3c-7v

(SONET channel thru OC-192)


Routing example1

Routing: Example

GE is adapted in STS-24c

(SONET channel thru OC-192)

U. Calgary

CA*net

Canada

UvA

GE

OC-192

GE is adapted in STS-24c

(SONET channel thru OC-192)

GE

OC-192

Star

Light

Chicago

MAN

LAN

New York

NetherLight

Amsterdam

OC-192

OC-192

GE is adapted in STS-3c-7v

(SONET channel thru OC-192)

GE is adapted in STS-3c-7v

(SONET channel thru OC-192)


Capability announcement

Capability Announcement

Does only understand GE

U. Calgary

CA*net

Canada

UvA

GE

Can only adapt GE in STS-24c

OC-192

Does only understand GE

GE

OC-192

Star

Light

Chicago

MAN

LAN

New York

NetherLight

Amsterdam

OC-192

OC-192

Does only understand SONET/SDH

Can only adapt GE in both STS-24c and STS-3c-7v

Can only adapt GE in STS-3c-7v


Degree distribution of actual networks

Websites

Autonomous Systems

Internet

World-Wide Web

degree

out-degree

Fraction of words

Film Actors

Word co-occurance

Collaborations of film actors

degree

degree

Degree Distribution of Actual Networks

Source: Mark Newman


Network description

Network Description

We need network descriptions for:

  • Network advertisementA user can use the information to formulate a lightpath reservation request

  • Path findingA resource broker can use the information to handle a reservation request

  • VisualizationCreate maps of a topology, and correlate these maps across domains


Why network descriptions

Why Network Descriptions?

iGrid 2005


Existing languages

Existing Languages

Only few standards!

  • ITU-T recommendation G.805Only describes network connections, not networks.Excellent notion of layering

  • DMTF standard CIM (Common Information Model)Very geared towards hardware, not towards networks and network device capabilities (hardly a notion of layering)

  • GMPLS (OSPF-TE)Has concept of layering. Can’t describe all details (e.g. WAN PHY or LAN PHY is decided during signaling phase). Not easily human-readable.

See also: http://www.science.uva.nl/research/sne/ndl/


Using rdf

Using RDF

Our idea: Use Resource Description Framework (RDF, a

W3C standard) and Semantic Web

  • Everyone publishes their own network descriptions

  • Correlations between domains are made by pointing from one repository to another, much like a URL can point to another web page.

  • Readable by computers and humans

predicate

Subject

Object

(property)

hasInterface

Device TDM1

Interface 12/1


Ndl basics

NDL Basics

  • Network Description Language (NDL) basics, version 1

  • Classes and properties defined in the NDL schema

  • This version is layer independent. We recently created a version with specific interworking between layers (adaptation and termination functions)

Location

Device

Interface

Link

name

description

locatedAt

hasInterface

connectedTo

capacity

encodingType

encodingLabel


Ndl example

NDL Example

<ndl:Devicerdf:about="#tdm1">

<ndl:name>tdm1</ndl:name>

<ndl:locatedAtrdf:resource="#NetherLight"/>

<ndl:hasInterfacerdf:resource="#tdm1:12/1"/>

<ndl:hasInterfacerdf:resource="#tdm1:6/1"/>

</ndl:Device>

<ndl:Interfacerdf:about="#tdm1:12/1">

<ndl:name>12/1</ndl:name>

<ndl:connectedTordf:resource="#tdm3:501/2"/>

<ndl:capacityrdf:resource="1250000"/>

</ndl:Interface>

<ndl:Locationrdf:about="#NetherLight">

<ndl:name>NetherLight</ndl:name>

<geo:lat>52.3561</geo:lat>

<geo:long>4.9527</geo:long>

</ndl:Location>

  • Device, Interface and Location described in NDL. RDF allows to easily integrate other schemas, such as the geo schema.

tdm1

tdm3

501/2

12/1


Vizualisation 1 netherlight

Vizualisation 1: NetherLight

NetherLight is an Optical Exchange (called GOLE in the GLIF community), created by SURFnet.

This picture was created from an NDL file, converted to a .dot file, opened with GraphViz.


Vizualisation 2 surfnet 6

Vizualisation 2: SURFnet 6

This picture shows all SDH devices in SURFnet.

Source: SARA


Vizualisation 3 google maps

Vizualisation 3: Google Maps

Source: Jeroen van der Ham


Ndl multilayer extension

CA*net

Canada

U. Calgary

UvA

GE

OC-192

GE

OC-192

Star

Light

Chicago

MAN

LAN

New York

NetherLight

Amsterdam

OC-192

OC-192

NDL Multilayer Extension

  • ITU-T G.805 describes functional elements (e.g. adaptation, termination functions, link connections, etc.) to describe network connections.

  • We extended these function elements (e.g. with potential adaptation functions) to describes networks.

  • We created a model to map actual network elements to functional elements.

  • Defined a simple algebra to define correctness of a connection

  • We created a NDL extension to describe these functional elements.

Simplified model to map network elements to functional elements


  • Login