Transcript UCLP Roadmap Bill St. Arnaud – www.canarie.ca CANARIE Inc

UCLP Roadmap
Bill St. Arnaud
CANARIE Inc – www.canarie.ca
[email protected]
UCLP Objectives
> Allow institutions to integrate wavelengths and fiber from different
suppliers and integrate with institution's network management
domain
– And offer VPNs to users
> Create discipline specific re-configurable IP networks
– Multihomed network which bypasses firewalls with direct connect to
servers and routers
> User controlled traffic engineering
– Active replacement for Sockeye and Route Science
– Alternative to MPLS
> Primary purpose is NOT reservation and leasing of wavelength
resources
> Primary purpose is NOT switched optical networks
> Primary purpose is NOT end-to-end optical VPNs
> Primary purpose is NOT inter-domain connection of lightpaths
UCLP intended for projects
like Optiputer and CaveWave
CAVEwave acquires a separate wavelength between
Seattle and Chicago and wants to manage it as part of
its network including add/drop, routing, partition etc
NLR
Condominium
lambda network
Original
CAVEwave
Recent UCLP examples
> Over 20 UCLP lightpaths setup across CA*net 4
> Need to purchase additional wavelength in 2005
> AARnet used UCLP to setup lightpath for Huygens-Cassini data
transfer
> 5 HDTV streams to be switched and controlled through UCLP at
APAN in Bangkok
> 3 UCLP lightpaths for restoral/protection by regional networks
> 2 UCLP lightpaths for distributed backplane – e.g. mini TeraGrid
> 7 international UCLP lightpaths – 1G to 2.5 G
> 10G UCLP lightpath shared between Tokyo Data reservoir and
HEPnet
UCLPv2
> UCLPv2
– Graphical interface to allow users to create “on demand” lightpaths or
APNs
– All lightpaths represented as web services that are consumed by user
by linking through portal on workflow engine
– will create a priori “articulated private networks” (APNs) represented as
a web service
> CAVEwave excellent example of an APN
–
–
–
–
Change add/drop configuration
Change termination networks
Create daughter APNs through partitions
Cross connect to other APNs
> BPEL or Keppler to link APNs together to form end to end
lightpaths and to link instruments
UCLP for LAN
Campus Border Router
End user
Standard Ethernet Links
VLAN
Lightpath Creation
Workflow Service
802.1 p/q VLAN
Web Service
External
Lightpath
VLAN to LightPath
Cross Connect
Web Service
Taverna Workflow graph
Third Party Lightpath
Bidirectional -1 Gbps
Vancouver: Port x/Slot y/Channel z
Montreal: Port x/Slot y/Channel z
Partitionable
Available until 2006 to all Vancouver
CA*net 4 peers
Neptune
Instrument WS
BCnet
Vancouver
CA*net4
UCLP
Lightpath
WS
Winnipeg
CA*net4
Montreal
CA*net4
Seattle
CA*net4
Seattle
Pwave
Chicago
CA*net4
Chicago
STAR LIGHT
New York
MAN LAN
UCLP
Cross Connect
WS
End to end choreography
3
2
Lightpath
WS
IP Flow
QoS
WS
Xconnect
WS
Lightpath Xconnect
WS
WS
OMNInet
Bandwidth
Reservation
WS
1
2
LightPathConectionPT
LightPathConectionPT
5
BandwidthReservationPT
Neptune/
ORION
Instrument
WS
4
3
4
Visualization
WS
InstrumentNetworkServicePT
NeptuneInstrumentServicePT
1
Neptune admin orchestration
Super user orchestration
5
End user orchestration
Scenario
Neptune
Instrument WS
Neptune Lightpath
Winnipeg
Calgary
Seattle
CA*net 4
NLR
Optiputer
CAVEwave
Lightpath
Chicago
Visualization
Engine
OMNInet
WSDL for instrument
Control Port(s)
Java
Stub
WSDL
Interface
Data Port(s)
instrumentControlPT
dataPathConnectionPT
Data Path A
Data Path B
Instrument
Axis/Apache/Linux
Server
WSDL Power & Instrument
instrumentControlPT
instrumentEnablelPT
Control Port(s)
Java
Stub
WSDL
Interface
Data Port(s)
Instrument
New Instrument WSDL
Data Path A
Instrument WSDL
Data Path B
Axis/Apache/Linux
Server
Power WSDL Proxy
dataPathConnectionPT
To user’s WSDL
Neptune Admin
Orchestration
instrumentControlPT
Path B
LAN
WS
Archive
& Fork
WS
archiveForkPT
Path A
LANnetworkConnectionPT
dataPathConnectionPT
Instrument
WS Proxy
Neptune Instrument WS
1
Data Flow Path
NeptuneInstrumentServicePT
1
Significance of UCLP v2
> Many power plants, water, sewage and process control SCADA
(System Control and Data Acquisition) are moving to TCP/IP so
that they can integrate process control with other eBusiness
systems
> But this makes systems more vulnerable to DOS attacks,
viruses, etc
> Impossible to fully protect with firewalls etc because too many
back doors
> Need to build “micro” firewalls around each SCADA subsystem with web services and link them together with web
services workflow