Download presentation
Presentation is loading. Please wait.
1
UCLP Roadmap Bill St. Arnaud CANARIE Inc – www.canarie.ca Bill.st.arnaud@canarie.ca
2
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
3
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
4
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
5
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
6
UCLP for LAN Campus Border Router 802.1 p/q VLAN Web Service Lightpath Creation Workflow Service VLAN End user Standard Ethernet Links External Lightpath VLAN to LightPath Cross Connect Web Service
7
Taverna Workflow graph
8
Vancouver CA*net4 Winnipeg CA*net4 Seattle CA*net4 Chicago CA*net4 Montreal CA*net4 Chicago STAR LIGHT New York MAN LAN Seattle Pwave UCLP Lightpath WS UCLP Cross Connect WS 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
9
End to end choreography Neptune/ ORION Instrument WS Visualization WS IP Flow QoS WS OMNInet Bandwidth Reservation WS Lightpath WS NeptuneInstrumentServicePT BandwidthReservationPT LightPathConectionPT InstrumentNetworkServicePT Super user orchestration 1 2 3 4 5 1 2 3 4 5 End user orchestration Neptune admin orchestration Xconnect WS Lightpath WS Xconnect WS
10
Scenario Neptune Instrument WS OMNInet Winnipeg Calgary Chicago Seattle Optiputer CA*net 4 NLR Neptune Lightpath CAVEwave Lightpath Visualization Engine
11
WSDL for instrument Control Port(s) Data Port(s) Java Stub Instrument instrumentControlPT Data Path A Data Path B Axis/Apache/Linux Server dataPathConnectionPT WSDL Interface
12
WSDL Power & Instrument Control Port(s) Data Port(s) Java Stub Instrument instrumentControlPT Data Path A Data Path B Axis/Apache/Linux Server dataPathConnectionPT WSDL Interface instrumentEnablelPT To user’s WSDL Power WSDL Proxy Instrument WSDL New Instrument WSDL
13
Neptune Admin Orchestration NeptuneInstrumentServicePT Instrument WS Proxy LAN WS Archive & Fork WS instrumentControlPT Neptune Instrument WS dataPathConnectionPT LANnetworkConnectionPT archiveForkPT 1 Data Flow Path 1 Path A Path B
14
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 sub- system with web services and link them together with web services workflow
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.