UCLP Roadmap Bill St. Arnaud CANARIE Inc –
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 p/q VLAN Web Service Lightpath Creation Workflow Service VLAN End user Standard Ethernet Links External Lightpath VLAN to LightPath Cross Connect Web Service
Taverna Workflow graph
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
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 End user orchestration Neptune admin orchestration Xconnect WS Lightpath WS Xconnect WS
Scenario Neptune Instrument WS OMNInet Winnipeg Calgary Chicago Seattle Optiputer CA*net 4 NLR Neptune Lightpath CAVEwave Lightpath Visualization Engine
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
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
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
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