Why is optical networking
interesting?
www.science.uva.nl/~delaat
Cees de Laat
Why is optical networking
interesting?
www.science.uva.nl/~delaat
www.science.uva.nl/~deaat
Cees de Laat
aat
EU
SURFnet
University of
Amsterdam
SARA
NIKHEF
serena
What is this buzz about optical
networking
• Networks are already optical for ages
• Users won’t see the light
• Almost all current projects are about SONET
circuits and Ethernet (old wine in new bags?)
• Are we going back to the telecom world, do
NRN’s want to become telco’s
• Does it scale
• Is it all about speed or is it integrated services
Current technology + (re)definition
• Current (to me) available technology consists of SONET/SDH
switches
• Changing very soon!
• DWDM+switching coming up
• Starlight uses for the time being VLAN’s on Ethernet switches to
connect [exactly] two ports
• So redefine a  as:
“a  is a pipe where you can inspect packets as they enter and
when they exit, but principally not when in transit. In transit one
only deals with the parameters of the pipe: number, color,
bandwidth”
VLBI
Know the user
(3 of 12)
# of users
A
B
ADSL
C
GigE LAN
F(t)
BW requirements
A -> Lightweight users, browsing, mailing, home use
B -> Business applications, multicast, streaming, VPN’s, mostly LAN
C -> Special scientific applications, computing, data grids, virtual-presence
What the user
(4 of 12)
Total BW
A
B
ADSL
C
GigE LAN
BW requirements
A -> Need full Internet routing, one to many
B -> Need VPN services on/and full Internet routing, several to several
C -> Need very fat pipes, limited multiple Virtual Organizations, few to few
So what are the facts
(5 of 12)
• Costs of fat pipes (fibers) are one/third of equipment to
light them up
– Is what Lambda salesmen tell me
• Costs of optical equipment 10% of switching 10 % of
full routing equipment for same throughput
– 100 Byte packet @ 10 Gb/s -> 80 ns to look up in 100 Mbyte
routing table (light speed from me to you on the back row!)
• Big sciences need fat pipes
• Bottom line: create a hybrid architecture which serves
all users in one consistent cost effective way
(5b of 12)
Scale 2-20-200
(5c of 12)
Services
2
Metro
20
National/
regional
Switching/ Routing
routing
200
World
B
VPN’s,
(G)MPLS
VPN’s
Routing
Routing
C
dark fiber
Optical
switching
Lambda
switching
Sublambdas,
ethernetsdh
A
ROUTER$
COST
# ~
200/RTT
(6 of 12)
Application
Application
Middleware
Middleware
Transport
High bandwidth app
Transport
Switch
Router
UvA
2.5Gb
lambda
GbE
ams
Router
SURFnet5
Lambda
Switch
chi
GbE
Router
party
carriers
GbE
UBC
Vancouver
Lambda
Switch
Router
Router
Switch
– Bypass of production network
– Middleware may request (optical)
pipe
• RATIONALE:
Router
3rd
• lambda for high bandwidth
applications
– Lower the cost of transport per
packet
(7 of 12)
CA*net 4 Architecture
CANARIE
GigaPOP
ORAN DWDM
Carrier DWDM
Edmonton
Saskatoon
St. John’s
Calgary Regina
Quebec
Winnipeg
Charlottetown
Thunder Bay
Montreal
Ottawa
Victoria
Vancouver
Fredericton
Halifax
Boston
Seattle
Chicago
CA*net 4 node)
Possible future CA*net 4 node
New York
Toronto
Windsor
Architectures - L1 - L3
(8 of 12)
R
Internet
R
SW
L2 VPN’s
Internet
R
R
Bring plumbing to the users, not just create sinks in the middle of nowhere
(8a of 12)
Distributed L2
Univ X
Univ A
Layer 2 VPN
Univ B
Univ Y
SN5
CHICAGO
SN5
AХDAM
lambda
(9 of 13)
Transport in the corners
BW*RTT
?
C
Needs more App & Middleware interaction
Full optical future
For what current Internet was designed
B
A
# FLOWS
(9a of 13)
QuickTime™ and a
PNG decompressor
are needed to see this picture.
Layer - 2 requirements from 3/4
WS
fast
L2
fast->slow
high RTT
L2
fast
WS
slow->fast
TCP is bursty due to sliding window protocol and slow start
algorithm. So pick from menu:
•Flow control
•Traffic Shaping
•RED (Random Early Discard)
•Self clocking in TCP
•Deep memory
Window = BandWidth * RTT
(10 of 14)
& BW == slow
fast - slow
Memory-at-bottleneck = ___________ * slow * RTT
fast
Forbidden area, solutions for s when f = 1 Gb/s, M = 0.5 Mbyte
AND NOT USING FLOWCONTROL
= 158 ms = RTT Amsterdam - Vancouver or Berkeley
s
1000
900
800
700
600
500
400
300
200
100
0
1
51
101
151
201
251
301
351
401
451
rtt
501
Daisy Chain control model of administrative
domains
Selector
Switch
Distributor
Switch
AAA
AAA
Domain X
Domain Y
(11 of 14)
(12 of 14)
Problem Solving Environment
Applications and Supporting Tools
Fault
Management
Communication
Services
Monitoring
Authorization
Auditing
Data
Cataloguing
Global Event
Services
Uniform
Resource
Access
Uniform Data
Access
the neck
(Resource)
CoScheduling
Brokering
Common
Grid
Services
Global
Queuing
Collective
Grid
Services
Grid
Information
Service
Application Development Support
Grid Security Infrastructure (authentication, proxy, secure transport)
Communication
Grid access (proxy authentication, authorization, initiation)
Fabric
Local
Resources
Grid task initiation
Resource Resource
Manager Manager
Monitors
CPUs
layers of increasing abstraction taxonomy
Resource
Manager
On-Line
Storage
Resource
Manager
Scientific
Instruments
Resource
Manager
Tertiary
Storage
Resource
Manager
Highspeed
Data
Transport
Resource
Manager
net QoS
(13 of 14)
CE
L1
L2
SE
L3
L3
ISP’s
peering
7, 6, 5, 4, 3, 2, 1
UE
NE
(13b of 14)
CE
L3/4
L2
L1
SE
L1
7, 6, 5, 4, 3, 2, 1
-tranport
NE
UE
L1
ISP’s
Research needed
(13c of 14)
• Optical devices
• Internet Architecture
• Network Elements as Grid Resources
• Transport protocols get in other corners
• How dynamic must your optical underware be
• Don’t mix trucks and Ferrari’s
Revisiting the truck of tapes
(14 of 14)
Consider one fiber
•Current technology allows 320  in one of the frequency bands
•Each  has a bandwidth of 40 Gbit/s
•Transport: 320 * 40*109 / 8 = 1600 GByte/sec
• Take a 10 metric ton truck
•One tape contains 50 Gbyte, weights 100 gr
•Truck contains ( 10000 / 0.1 ) * 50 Gbyte = 5 PByte
• Truck / fiber = 5 PByte / 1600 GByte/sec = 3125 s ≈ one hour
• For distances further away than a truck drives in one hour (50 km)
minus loading and handling 100000 tapes the
fiber wins!!!
(15 of 14)
The END
Thanks to
TERENA: David Williams
SURFnet: Kees Neggers
UIC&iCAIR: Tom DeFanti, Joel Mambretti
CANARIE: Bill St. Arnaud
Support from:
SURFnet
EU-IST project DATATAG
26/11/1910 -- 11/9/2002