Transcript UCLP Roadmap Figures

Today’s hierarchical IP
network
Other national networks
National or Pan-Nationl IP Network
NREN A
University
NREN C
NREN B
Region
al
NREN D
Tomorrow’s peer to peer IP
network
World
World
National DWDM
Network
World
Child
Lightpaths
NREN A
University
Server
NREN B
NREN C
Region
al
Child
Lightpaths
NREN D
Creation of application VPNs
University
Dept
High Energy
Physics Network
Commodity
Internet
University
Research
Network
CERN
University
Bio-informatics
Network
University
University
eVLBI
Network
Definitions - 1
> Lightpath Object (or layer 1 VPN)
– An aggregation of a number of web services into a workflow created
by owner of WS resources
– Workflow script is run on the same server where original WS
resources are located
– The degree of control that a user has over a lightpath object, such as
partitioning, concatenation is dependent on complexity of workflow
script, but assumed to be limited compared to APN
> APN resource list
– A pointer to a set of WS that may constitute all or part of an APN
– Essentially a set of WS(s) with a common set of permissions
– User can run their own workflow script to create functioning APN; or
re-advertise all or some of the APN resource list to other users
Definitions - 2
> APN
– A workflow script that links together a number of WS from APN
resource list and other sources, including WS that any be
encapsulations of workflows on a host server
– Workflow script runs on client’s server
– To make major changes to an APN, workflow script may need to
be terminated and re-compiled
> The essential difference between a lightpath object (or layer 1
VPN) and APN is the location of where the workflow script runs
– If the workflow script runs on the host server then it is a lightpath
object (or layer 1 VPN)
– If the workflow script runs on the client server then it is an APN
• Client can terminate script at any time and re-articulate the
connection of WS – hence APN
Security
> Highly recommended that standard SAML security
be used with delegated certificates
> Each WS such as interface, cross connect, etc
should be able to accept delegated certificates using
SAML and X.509
> Certificates should be obtained from Grid Canada –
www.gridcanada.ca
Types of Resources
> Sources:
– Physical Network
• Inquiry OSPF or Tl1 to get all path lists of a physical network
and then represent each interface and link as a WS (i.e.
URI); or
– APN web service resource list
• a fixed set of APN web service resource list of URIs from
another provider
> Resource discovery of a physical network should be automatic
as possible, with regular updates, but with ability for domain
manager to add certain conditions and exception e.g.
– Some interface WS may have limited throughput
– Domain manager may want to restrict advertisement of certain
interfaces or links
TRIUMF APN Resource List
(illustrative example)
<TRIUMF-APN resource elements/
<Administrator: Steven MacDonald, ID: 99999>
/etc/
/List of Lightpath web services/
<OC48: Victoria-Vancouver> http://CAnet-4/UCLP#OC48-Victoria-Vancouver
<OC192: Vancouver-Edmonton> http://CAnet4/UCLP#OC192-Vancouver-Edmonton
<OC192: Edmonton-Toronto>
…
<OC192: Toronto-New York>
…
<OC192: New York-Amsterdam>
…
<OC192: Amsterdam-Geneva> http://CAnet4/UCLP#OC192-Amsterdam-Geneva
/etc/
/List of Interface Web services/
<10Gbe Interface Vancouver> http://CAnet4/UCLP#10Gbe-Vancouver
<Gbe Interface Vancouver>
…
<GbE interface Edmonton>
…
<5GbE interface Toronto>
….
<5GbE interface Victoria http://CAnet4/UCLP#5Gbe-Victoria
/etc/
</TRIUMF-APN>
Resource view of ONS physical
network on CA*net 4 available
for APN composition
YEG
YUL
YVR
YOW
Winnipeg
YYZ
TRIUMF
YCG
Halifax
OME
Pwave HDX
STAR LIGHT HDX
MAN LAN HDX
10G STS partitionable interface
1Gbe non-partitionable interface
Resource View of OME physical
network on CA*net 4 available
for APN composition
ONS
ONS
Montreal
ONS
Vancouver
ONS
BCnet
Toronto
Ottawa
MAN LAN HDX
Chicago
New York
Seattle
STAR LIGHT HDX
Pwave HDX
OC192 Interface
GbE Interface
APN Creation Process - 1
> UCLPv2 GUI has multiple resource windows and two
types of composition windows
– Lightpath object composition to aggregate a number of network
elements into a single exposed WS (using BPEL?)
– APN resource composition window which provides a set of WS to
be consumed by a third party
> Resource windows may show physical network
elements OR previously created APN resource list e.g.
– One window displays CA*net 4 ONS network elements
– One window displays CA*net 4 OME network elements
– One window display APN resource list previously created by
SURFnet for CANARIE
APN Creation Process - 2
> APN resource list may be made up of:
– Interface WS
– Lightpath WS
– Cross connect WS
– Lightpath object WS – which is an encapsulation of a workflow of other
WS
> In fact all advertised WS in a resource list may be separate and
individual BPEL implementations
– Ongoing debate as to whether state, security and other feature be
incorporated within a very complex and statefull WS or;
– Each function be a workflow of simple stateless services, and resulting
BPEL represented as a new WS
> First CANARIE staff create all necessary lightpath object WS using
workflow (on slide 15)
> Second CANARIE staff create APN resource list by dragging WS from
resource windows as well as from Lightpath Object Creation window
(on slide 15)
APN Creation Process - 3
> With each drag and drop CANARIE staff may be asked to select
STS channel, size, port number
– Only those elements that are free, and are not used in another
APN (or are reserved) will be made available in selection lists
> Ideally each element that is brought into composition window is a
web service (i.e. a URI pointing to a web service)
– The URI itself may contain all necessary information rather then
creating a new WS for each element
> When the composition is done – there needs to be a final
permission and lifetime-lease assignment phase to make sure
cross connects of the APN are assigned to a specific user or
class of users (e.g. all Canadian researchers)
APN Creation Process - 4
> A Microsoft like “wizard” may be required to help accomplish the
composition
> Every time a lightpath object composition or APN resource
composition window is created, the wizard would be invoked
– Wizard would ask questions about bandwidth, keep track of STS
channel assignment, and globally assign permissions and lifetimelease variables to all WS elements
– When composition is complete, wizard would either advertise APN
resource as a URI; or invoke workflow engine to run workflow
script
Nomenclature & misc. notes
> Dashed lines are WS resources available to 3rd parties
– The click and drag of such resources is to assign specific permissions
and lifetime parameters
> Solid lines are “ligthpath object” WS that have been compiled
into a workflow script on a host server
– The workflow encapsulation can be advertised as a new WS to a third
party
•
e.g. Edmonton Chicago Toronto link has been encapsulated into a single
WS that is then advertised to TRIUMF HEpnet
> The cross connects between 2 WS from different domains may
require a two handed handshake to complete the workflow e.g. SURFnet at NYC and CA*net 4 at NYC
> Where an interface points to another interface across an STS or
DWDM network, the selection of STS channels is limited to
what was chosen on the initial interface
APN Resource List Creation
View by CANARIE staff
Lightpath Object Creation
YEG
CANARIE ONS Network
Resources
1
YVR
YUL
ONS
OME Vancouver
BCnet
Pwave HDX
3
Chicago is hidden
ONS
New York
Chicago
Seattle
Victoria
2
MAN LAN HDX
4
Toronto
Vancouver
Montreal
SURFnet
APN
Halifax
resources advertised
to
Amsterdam
Ottawa
CANARIE
MAN LAN HDX
ONS
Toronto
STAR
ChicgaoLIGHT HDX
Edmonton
Edmonton
YYZ
TRIUMF
CANARIE OME YCG
Network Resources
Toronto
YOW
Winnipeg
STAR LIGHTOttawa
HDX
Edmonton
New York
Amsterdam
ONS
Montreal
To Fermi
New York
New APN Resource list composition
To Brookhaven
Geneva
5
Geneva
CANARIE provides APN
resource list to TRIUMF
1G Interface WS
URI: http://canarie_apns/triumf_apn.ws
5G Interface WS
10G Lightpath WS
1G Lightpath WS
Toronto
Ottawa
Vancouver
Victoria
Amsterdam
Edmonton
Montreal
To Fermi
New York
NOTE: This resource element is actually
an aggregation of several elements on
CANARIE network. The exposed WS
may actually be a BPEL composition of
the underlying WS elements
To Brookhaven
Geneva
Possible APN composition GUI
display using a workflow tool
Tier 2
Server
ATLAS
server
“drag and drop”
TRIUMF
VLAN
1 Gbe
1 Gbe
UoT
Tier 2
1 Gbe
1 Gbe
10 Gbe
Van-Edm
10 Gbe
Edm-Tor
2 Gbe
Vic-Van
1 Gbe
1 Gbe
1 Gbe
Tor-Ott
10 Gbe
Tor-NYC
1 Gbe
NYC-MTl
1 Gbe
1 Gbe
UoVic
Tier 2
1.
2.
3.
Note: External APN may be
represented as a single web service
TRIUMF
CWDM
5 Gbe
Harvested APNs
5 Gbe
TRIUMF
FERMI
Interface web service
Lightpath web service
External web service
1 Gbe
10 Gbe
NYC-Ams
10 Gbe
Ams-Gen
5 Gbe
5 Gbe
Brookhaven
CERN
http://TRIUMF_APN/triumf.ca
http:/UoVic-APN/uvic.ca
http://UoT_APN/uot.ca
HEPnet APN/Lightpath
creation process
> HEPnet receives APN resource list from CANARIE
> HEPnet acquires additional APNs or lightpath objects from
local loops at universities
> HEPnet create new APN resource lists or lightpath objects
> TRIUMF/HEPnet staff create a number of child lightpath objects
or APNs
> UCLPv2 GUI displays several APN windows
– Original TRIUMF/HEPent APN resource list provided by CANARIE
– 802.11 p/q lightpath WS created by UoVic for TRIUMF/HEPnet
– CWDM channel lightpath WS created by UBC for TRIUMF/HEPnet
> In this example HEPnet creates a lightpath object for the Tier 2
connection between TRIUMF and UoVic
TRIUMF GUI harvests other
APNs from UoVic, UoT, etc
TRIUMF
Tier 1
UBC
Physics
UoVictoria Physics
Tier 2
TRIUMF
APN
1G Interface WS
UoToronto Physics
Tier 2
UA
Physics
5G Interface WS
UoT
Physics
UoT
APN
Toronto
10G Lightpath WS
UdM
Physics
Carleton
Physics
External links or APNs
Amsterdam
Vancouver
Edmonton
Montreal
UoV
APN
Ottawa
Victoria
CA*net 4
New York
Geneva
Chicago
Note: Typical View on
TRIUMF UCLP GUI
FERMI
Tier 1
Brookhaven
Tier 1
CERN
Tier 0
TRIUMF/HEPnet Lightpath
Object Composition GUI
UBC Campus
CWDM Lightpath
Object
UoVic Campus
802.11 Lightpath
Object
TRIUMF APN
Toronto
Ottawa
Vancouver
Amsterdam
Edmonton
Montreal
To Fermi
Victoria
New York
UoVic
Vancouver
Victoria
Composition Window
TRIUMF
Lightpath Object for 2 Gbps Tier
2 between TRIUMF and UoVic
To Brookhaven
Geneva
UoVic Physics UCLPv2 GUI or
workflow tool adds Router WS to
lightpath object
UoVic Physics router
resource
CLI interface exposed as
a WS
Resource Window
UoVic
TRIUMF
Vancouver
Victoria
Lightpath Object for 2 Gbps Tier
2 between TRIUMF and UoVic
Created by TRIUMF/Hepnet
UoVic
TRIUMF
Vancouver
UoVic workflow process to
attach a router
> UoVic gets URI from TRIUMF/HEPnet composition of a lightpath
object linking Tier 2 site
> UoVic physics uses UCLPv2 or some other workflow tool that
links “router” WS to the lightpath object
> A “router” WS is essentially a WS that encapsulate some of the
CLI commands on the router
– This is already available on Juniper routers
> The router WS provides the necessary CLI commands to active
the router interface that faces the lightpath object
> Finally the router WS may also change the forwarding table of
the router (i.e. OBGP)
TRIUMF partitions APN and
creates several child APNs
TRIUMF
Tier 1
UBC
Physics
UoVictoria Physics
Tier 2
UoToronto Physics
Tier 2
UA
Physics
UoT
Physics
CWDM
CWDM
Toronto
Vancouver
5G Tier 1 data
2G Tier 2 data
Carleton
Physics
UdM
Physics
Amsterdam
Edmonton
Victoria
To other physics users at
smaller universities
Note: Typical View on
TRIUMF UCLP GUI
1G HEPnet daisy chain
routed
Ottawa
CA*net 4
Optional
interfaces
New York
Geneva
Chicago
FERMI
Tier 1
Brookhaven
Tier 1
CERN
Tier 0
TRIUMF creates child APN
for HEPnet
1G Interface WS
Note: View seen by HEPnet UCLP GUI
UBC
Physics
UA
Physics
Toronto
Vancouver
Edmonton
UoT
Physics
Carleton
Physics
Ottawa
UoV
APN
UdM
Physics
Montreal
CERN
Victoria
CA*net 4
Note: TRIUMF has created this child APN from elements
from the original CANARIE APN and the APNs provided by
UoVictoria, TRIUMF, UoT, etc
HEPnet APN cannot
see switches in
Amsterdam or NY
Resultant HEPnet routed
network
1G Interface WS
UBC
Physics
UA
Physics
UoT
Physics
Carleton
Physics
UdM
Physics
Montreal
UoV
APN
CERN
CA*net 4
To smaller physics depts
through university router
CANARIE provides APN to
NRC
Edmonton
Saskatoon
Vancouver
Winnipeg
Victoria
Calgary
Regina
Seattle
Ottawa
Montreal
Toronto
Fredericton
Chicago
New York
CA*net 4 router
1G Lightpath WS
GbE interface WS
Halifax
NRC partitions APN
Edmonton
Saskatoon
Vancouver
Winnipeg
Victoria
Calgary
Seattle
Regina
Ottawa
Montreal
Toronto
Fredericton
Chicago
New York
Halifax
NRC logical view of APN
Edmonton
Saskatoon
Vancouver
Winnipeg
Ottawa
Regina
Victoria
Montreal
Toronto
Seattle
Fredericton
Chicago
New York
Halifax
UCLP intended for projects
like National LambdaRail
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
Extension of the network
into the application
Single Computer or
WS instance of an orchestration
VPN extends into computer
to specific processes
zzzz:410:0:1
Instrument
Web service or
software process
User A
xxxx:410:0:1
xxxx:410:0:4
xxxx:410:0:2
Routing daemon
Web service
xxxx:410:0:3
UCLP Layer 3
Routing Daemons
xxxx:410:0:5
DWDM
Network
Web service or
software process
Interface Card or port
yyyy:410:0:1
VPN Links
User B
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
Typical Large system today
VPN
USER
Internet
Security Web Services OGSA
DMAS
Process
Process
Process
Process
Process
SONET/DWDM
Instrument Pod
SONET/DWDM
Layer 3 switch/router
Layer 2 switch
Sensor
Sensor
Instrument
Instrument
Sensor
Service Oriented Architectures
HPC
VPN
WS*
WS*
CA*net 4
Lightpath
Process
Data
Management
System
WS**
Process
Process
WS**
Process
WS
Process
Process
LAN
WS
LAN
Web service
Interface
*CANARIE UCLP
CA*net 4
Instrument Pod
WS*
WS*
**New web services
Sensor
Sensor
WS
Instrument
Layer 2/3 switch
Instrument
Sensor
USER
Science user perspective
WS*
WS*
WS**
CANARIE UCLP
WS**
WS
AAA process
WS*
Lightpath
WS*
ONS15454
New Web service
New development
UDDI or
WSIL service registry
WS**
Log Archive Process 2
WS**
Log Archive Process 1
WS*
LAN
WS*
LAN
WS**
Sensor/Instrument
WS HPC
Process
WS**
NLR or CA*net 4
DMAS
USER with
WSFL
binding
software
Science Pod
User defined
WSFL
bindings
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
1. E-gun &
Linear Accelerator
VESPERS Beamline at the
Canadian Light Source
 microanalysis with
unprecedented sensitivity
3. Storage Ring
4. Beamline
End Station
Current CLS Infrastructure
StorageRing
Gateway
Data Archive Server
Managed by I/T Group
Input Output Controller
Operator Interface
Beamline Hardware
Input Output Controller
Operator Interface
Managed by I/T Group
Input Output Controller
Operator Interface
MySql
Operator Interface
iMate
Beam Line Instrumentation
& Control System
Managed by IT Group
Alarm Handler
MySql
Proposed Infrastructure
StorageRing
Gateway
Data Archive Server
Managed by I/T Group
Input Output Controller
Web Service
Portal
Operator Interface
Beamline Hardware
Web Service
ESB
Input Output Controller
Operator Interface
Managed by I/T Group
Input Output Controller
Operator Interface
MySql
Operator Interface
iMate
Beam Line Instrumentation
& Control System
Managed by IT Group
Alarm Handler
MySql
Web Service
Other
Service or
Client
Web Service
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