CA*net 4 Research Program Update – UCLP Roadmap for
 creating User Controlled and Architected Networks using Service
     ...
1.0 Introduction

On August 28, 2005 the National Science Foundation (NSF) in the United States
announced the Global Envir...
more substrates across different ownership domains. This user defined network can be
packet or switched and the user decid...
described in more detail in the following section. In GENI there is yet no defined process
for creating virtual links and ...
the topology of their collection of VPNs, and cross connect their collection of VPNs over
multiple domains to VPNs operate...
Another attraction of many work flow tools is their service oriented nature as opposed to
the document oriented architectu...
supercomputers for weather forecasts as well as to local users who may need more
immediate and local information.

1.3 Def...
The term “user” is used frequently in this document. It causes considerable confusion
amongst readers as they assume it me...
(c) Extension of the “network” into the application and/or computer;

   (d) Using web services and web services workflow ...
network, not a nameless, faceless network engineer who makes the decision of how the
networks should interconnect and peer...
In fact, this was how the original routers in the Internet were originally constructed. The
move to specialized high perfo...
For example an end user is not going to know, or care, about a syntactic structure of end
to end network connection made u...
2.0 UCLP status to date

In September 2003 CANARIE issued a call for proposals under the Directed Research
program to invi...
APN) objects. Once a root lightpath (or APN) object is created, the root can
independently create “child” lightpath object...
organization purchases current VPN services, optical or otherwise, from today’s carriers.
Current VPN architectures are on...
interconnect that new wavelength and use it as an integral part of network with its
existing NLR wavelength. UCLP was deve...
Another advantage of such specialized IP networks is that they can be designed to bypass
campus firewalls and LAN networks...
other rather than exchanging traffic through a hierarchy of IP networks as illustrated in
Figure 2.1.

                   ...
In order for end users to discover networks and or devices it was proposed that UCLP use
the BGP AS path information as a ...
immediately know which AS system provided lightpath capability. The user would still
have to query an OBGP server associat...
(b) UCLP primary purpose is NOT to offer reservation or scheduling mechanisms of
       lightpaths, but owners of partitio...
UCLP is designed with the assumption that the creation and assignment of partitions of
both network elements and lightpath...
3.0 UCLPv2 additional features

As mentioned previously not all the features described in the original UCLP architecture
h...
One of the primary applications for UCLP was to allow the deployment of application or
discipline specific IP networks for...
than what is possible on a switch which allows for full inheritance and many sub child
arrangements.




                 ...
4.0 UCLPv2

To address the requirements for these new features in the UCLP software as described in
Section 3.0, including...
Administrative-user can be an optical network and/or equipment facilities
       manager or operator. For example an admin...
entry point to a domain of switches or devices (i.e. network cloud) or linked to individual
lightpaths and devices as requ...
For example, traditional routing protocols were designed to forward packets between
physical network connected devices. Bu...
APNs are exposed as web services and therefore the APN manager can manipulate or
change the architecture and topology any ...
Individual financial transactions generally have small data volumes and so the overhead
cost of encapsulating transactions...
Most instruments and sensors used in research applications and process control have
some characteristics similar to that o...
As in the original UCLP design one of the key “services” that must be first invoked is a
path discovery and harvesting ser...
Ultimately it is essential that this information harvested from topology discovery
services, UDDI and WSIL resource broker...
5.0 UCLP Next Generation Scenarios using workflow

The following scenarios will attempt to illustrate the use of web servi...
server) will be connected via an IP flow QoS service or MPLS tunnel to a BCnet router.
The router interface supporting tha...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
CA*net 4 Research Program Update – UCLP Roadmap for creating ...
Upcoming SlideShare
Loading in...5
×

CA*net 4 Research Program Update – UCLP Roadmap for creating ...

753

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
753
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CA*net 4 Research Program Update – UCLP Roadmap for creating ...

  1. 1. CA*net 4 Research Program Update – UCLP Roadmap for creating User Controlled and Architected Networks using Service Oriented Architecture Draft—Draft—Draft—Draft—Draft—Draft—Draft—Draft You are free to distribute this paper as long as the following the disclaimer is included: “This is a discussion paper intended to provoke further thought and debate on the implications of web services and web services workflow for allowing users to architect their own Articulated Private Networks on a common network substrate connecting and managing geographically distributed router, switches research instruments and sensors to networks based on the original User Controlled LightPath (UCLP) software developed for CANARIE to manage geographically distributed optical and SONET/SDH cross connects and switches. Please send all comments, suggestions and criticisms to the author” Author: Bill.St.Arnaud@canarie.ca Last revised draft: January 3, 2006 Abstract Around the world there are several initiatives to develop the next generation canonical Internet network architecture . This discussion paper provides an alternative approach largely based on two significant development, first: the trend for more users to own, control and manage their own network resources and secondly: the demand by big science and large enterprises to have dedicated network resources for the data flows generated by their high end applications. As opposed to other approaches a key assumption in this discussion paper in regards to network architecture is that there is NO canonical network architecture. Instead this document describes new features and enhancements to the current implementations of the User Controlled LightPath (UCLP) software which will enable users to define their own packet or switched based network architecture including topology, routing, virtual routers, switches virtual machines and protocols based on the concept of many separate and independently managed Articulated Private Networks (APN) operating on top of one or more network substrates across different ownership domains. APNs can be considered as a next generation Virtual Private Network where, rather than signaling for a single end to end connection, a user can create a complex network structure, in any way they wish, by binding together layer 1 through 3 network links, instruments, computers, time slices and virtual or real routing and/or switching nodes. This capability is enabled through UCLP by representing all such network element, devices and links as web services, and by using web services workflow as the tool to allow the user to bind together their various web services to create a long lived APN instantiation. With web services workflow the user also has the ability to offer all, or portions of their APN as a web service (or set of services) in is own right to other downstream users. 1
  2. 2. 1.0 Introduction On August 28, 2005 the National Science Foundation (NSF) in the United States announced the Global Environment for Networking Investigations (GENI) [NSF-GENI]. Research that falls under the broad conceptual umbrella of this initiative will focus on designing new network architectures and services that range from new wireless and sensor devices to customized routers and optical switches to control and management software. The objective of the program is an attempt to “de-ossify” the Internet and develop and architecture that will allow an easy migration strategy such that users and applications can migrate effortlessly from the current Internet to a future more robust and secure environment. As such it is felt that a national testbed is necessary to carry out research in defining new network architectures. One proposed architecture under the GENI framework is “Network Virtualization” [VIRTUALIZATION] which provides for multiple virtual networks to co-exist on top of a shared “substrate”. Different virtual networks provide alternate end-to-end packet delivery systems and may use different protocols and packet formats. Virtual networks may also be interconnected with virtual routers and interconnect wireless, instrument and sensor networks as illustrated in Figure 1.0 Figure 1.0 GENI Network Virtualization The original concept for User Controlled LightPaths (UCLP)[UCLP-DESIGN] as subsequently updated with the UCLPv2 program [UCLPv2] has many similar objectives as that with the proposed GENI program in particular relation to the concept of network virtualization. The major difference between these concepts is that UCLP assumes there is no predefined canonical network architecture. Rather the user is given the tools to build any variation of virtual (and real) network architecture that so desire on top of one or 2
  3. 3. more substrates across different ownership domains. This user defined network can be packet or switched and the user decides what type of topology, restoral, protection and routing that may be necessary for their particular requirements. In essence the future network architecture has no predefined network architecture. Instead a substrate is provided which is capable of supporting many separate user defined networks which can be assembled through a series of lego block type web services as illustrated in Figure 1.1. APN Instrument WS Substrate Parent Router Lightpath Substrate WS Switch GMPLS Daemon WS Child Lightpath WS (may run over IP Virtual Ethernet, MPLS, etc Router WS Wireless Sensor Timeslice Network WS Figure 1.1 UCLP Network Virtualization The major differences between UCLP and GENI is that in UCLPv1 the network was assumed to be made up only of wavelengths and optical switches which could be partitioned into smaller lightpaths and where the lightpath owner could be given control of the optical or SONET cross connects that touched that particular lightpath. UCLPv2 allows for the user control of both wavelengths, MPLS tunnels, IP packet networks and Ethernet networks. UCLP allows for a creation of a set of VPNs which can be configured into a topology by the user decided upon by the user including meshes, rings, etc. As well UCLP allows the user to reconfigure the topology of this mesh of VPNs and change their shape, size and path. Hence the moniker of “articulated” Private Networks. Articulated Private Networks (APNs), in many ways are similar to the GENI concept of many virtual networks sharing a common network substrate linking together virtual instruments, router and devices. With APNs all the virtual links and devices are represented as web services and are linked together via web service workflow tools as 3
  4. 4. described in more detail in the following section. In GENI there is yet no defined process for creating virtual links and connecting them to virtual devices and/or time slices. By representing the substrate, child lightpaths, switches, routers and time slices or processes the user with UCLPv2 has complete flexibility and control to architect the resulting network in way they wish using web service workflow tools. 1.1.1 Market drivers for UCLP One of the drivers for UCLP is the growing trend for organizations such as universities, hospitals, schools and businesses to acquire their own fiber and point to point wavelengths from different suppliers. These organizations would like to manage these facilities as part of their own network domain, and, in turn offer a variety of downstream services to their users such as APNs, VPNs, etc. These needs are very similar to the “carrier’s carrier” market where carriers want to service customers outside of their facilities based footprint by acquiring leased layer 1 or layer 3 services from some other carrier and interconnect these facilities with virtual routers and switches. The driver for “carrier’s carrier” solutions is increasingly be driven by the large enterprise as well as other competitive local exchange carriers. Another important driver for UCLP is the growing recognition around the world that there are many large remote sensor and instrumentation projects whose large data flows will need to be delivered to computing facilities many thousands of kilometers away. As well, researchers will want to remotely control these instruments and, from time to time, re-direct the flow of data to different computing destinations. Examples of such facilities include the European eVLBI project- JIVE [E-VLBI], the US-Canada undersea network Neptune [NEPTUNE], the Canadian Light Source Synchrotron project (CLS) [CLS], the Ottawa University-NRC Nuclear Magnetic Resonance Instrument Facility [NRC-NMR] , and of course, the granddaddy of them all the CERN Large Hadron Collider (LHC) [LHC] . Up to now the interconnection of these instruments to networks and remote computers was static and pre-configured by network or software engineers using VPNs or lightpaths. Increasingly researchers need to do their own traffic engineering and control how these instruments are connected to the network and redirect or share the data flow amongst different geographically distributed researchers. As well they may want to control the transport mechanisms on how the data is delivered as for example through their own IP routed network with guaranteed QoS parameters. In some cases the expected data flow demands of these projects, in terms of throughput and duration will easily exceed by order of magnitude, that of conventional Internet traffic flows. In anticipation of these requirements CANARIE has been leading the development of User Controlled LightPaths [UCLP] in order to permit researchers to create “discipline” or “application” specific Layer 1 VPN or IP networks which would create separate high speed networks for these specific applications. As opposed to traditional VPNs the UCLP allows end users to do their own traffic engineering, change 4
  5. 5. the topology of their collection of VPNs, and cross connect their collection of VPNs over multiple domains to VPNs operated by other users as shown in Figure 1.2. In this example we see an APN created from three separate independent managed domains and in turn a “child” APN has been created out of the mult-domain APN. The nodes can be either virtual routers or switches. The nodes that indicate that they have been partitioned indicates that control of the virtual router or switch has also been handed over to the owner of the APN or child APN, which ever the case may be. Partitioned Node Child APN Pass Through Node Multi-Domain APN Domain A Domain B Domain C Figure 1.2 Creation of APN from multiple independent managed domains 1.1 Web Services Workflow With UCLPv2 it was proposed that Service Oriented Architecture (SOA) [SOA] new technologies of web services workflow and/or orchestration, that were originally conceived for eBusiness applications, would be the underpinning architectural framework for extending UCLP to allow the interconnection of instruments, time slices and sensors and for incorporating virtual routers and switches.. Specifically Web Services Description Language (WSDL) [WSDL] and Work flow languages such as Business Process Engineering Language (BPEL) [BPEL-INFO] were proposed as the implementation tools for such a reference framework. One of the major attractions of web service and work flow tools is that they provide a consistent and standardized set of interfaces to all sorts of process including instruments and networks and allow users to bind processes together as required for particular applications, unconstrained by the original design requirements. 5
  6. 6. Another attraction of many work flow tools is their service oriented nature as opposed to the document oriented architecture of most web service standards. For example every BPEL orchestration is represented as new WSDL web service and so it is possible to encapsulate web service orchestrations within other web service orchestrations allowing for a truly recursive object oriented architecture. BPEL as well supports life time management tools for the leasing and consumption of resources. There are many other possible tool service and object oriented sets including some of the original distributed object oriented middleware such as DCOM and CORBA. Alternatively Jini/Javaspaces as also been used in such applications. There are many approaches with various pros and cons that would be an entire paper in itself. But for a variety of reasons there seems to be an industry trend to web services and web services work flow language tools as a common platform for such applications. Various standards bodies are migrating their protocols to web services including the Object Management Group Unified Modeling Language (UMLv2), UPnP Forum for connecting devices in the home, The Instrumentation, Systems, and Automation Society (ISA) and many others. 1.2 e-Business tools and instrument/sensor networks The application of e-Business tools to the control of networks, instrumentation and sensors may also have large impact on many industrial and business process control applications. To date the e-Business revolution has had the biggest impact on “information" industries and processes such as financial trading, business transactions, on-line shopping and information services. But with UCLP and web services for instruments the same tools can be used to interconnect "physical" processes and process control systems in manufacturing, agriculture, pulp and paper, oil and gas, power distribution, marine, transport, environmental etc. To date many of these process control systems and Supervisory Control And Data Acquisition (SCADA) systems use proprietary or industry unique protocols and network architectures. The use of web services and web service workflow technologies promises to provide a standardized and open interface to these systems and allow them to be seamlessly integrated into existing e-Business applications. Just as importantly the web service and grid security standards can then also be adopted to these systems, many of which have only rudimentary security. Although many of these industrial applications will only encapsulate instruments and sensors connected to local area networks, there will be requirements for wide area network applications as well. A simple illustrative example is to use these tools to interconnect oil and gas sensors on the ocean floor across a network to computer systems in oil refineries to accurately control the flow of raw crude to the refinery with less inventory in ships and storage tanks [IBM-MQ]. Another example is to connect agriculture sensors networks in wheat fields over the network with remote sensing databases to provide future traders accurate and instant estimates of crop production. Or weather and environmental sensors that can simultaneously feed data to remote 6
  7. 7. supercomputers for weather forecasts as well as to local users who may need more immediate and local information. 1.3 Definition of Layer 1 VPNs, LightPaths and Articulated Private Networks The terms “LightPaths”, “Layer 1 Virtual Private Networks (VPNs)”[L1VPN] and “Articulated Private Networks (APNs)” are used extensively in this document. VPNs have normally been associated with statistical multiplexed networks while layer 1 facilities are usually circuits like STS channels or optical wavelengths. Layer 1 VPNs are generic to describe a number of layer “1” real or virtual network connections such as optical VPNs, concatenation of STS circuits etc. This is also consistent with the ITU definition of a Layer 1 VPN [ITU_Y.1312]. In the original UCLP design document [UCLP-DESIGN] a lightpath was defined as any communications link that could be treated as a circuit with fixed and guaranteed bandwidth. In addition some types of lightpaths can be subtended into smaller lightpaths while retaining the original attributes. Optical wavelengths, STS channels, MPLS with QoS, ATM CBR PVCs and 802.1 p/q links were therefore considered as lightpaths under that original definition. For the purposes of the UCLP roadmap it is proposed that the fixed bandwidth restriction be removed in defining a lightpath, and instead the definition be expanded to include any channel or link where an user can control the end points and topology. To distinguish between UCLP services and traditional end-to-end VPNs, whether at layer 3 or layer 1 we propose to use the term “Articulated Private Networks (APNs). Because the term lightpath is used with UCLP, many people assume it is a protocol to provide end-toend bandwidth on demand or allow for scheduled end-to-end bandwidth. Although UCLP can be used for these types of solutions, this was not its primary intended application. It’s primary purpose is to allow the partitioning of lightpaths and switches to be managed by third parties for the creation of multiple virtual VPNs sharing a common substrate or parent VPN. The outcome of this partitioning may coincidentally result in the creation of an end-to-end lightpath and/or inter-domain optical VPN, but not necessarily so. The defining characteristic of UCLP is that the user can reconfigure the partitioned lightpaths and cross connects at each node resulting in an “Articulated” private network. The articulated private network concept can be extended beyond the physical network links to devices outside of the network such as instruments, sensors, computers and so forth. As well the APN can incorporate internal virtual routers, switches and other devices to make up an entire network solution. Again this does not necessarily mean the APN must be “end-to-end”. A single APN can be thought of as a complex “object” linking together both virtual and real network elements, instruments and so forth, which when linked to other APNs may result in a complete end-to-end solution. 1.4 Definition of a “User” 7
  8. 8. The term “user” is used frequently in this document. It causes considerable confusion amongst readers as they assume it mean an “end-user”. However as explained later in this document, because UCLP exhibits inheritance the term user is generic reference to anyone who consumes the web services offered by an entity. The user could be a physical network administrator, a campus network administrator, a departmental network administrator or ultimately ( but probably least likely) a member of the general public. In each case the parent may aggregate and abstract a collection of web services and advertise them as single instantiated web service to their child users. 1.5 Security, Authorization and Authentication With more and more devices and software processes linked to local and wide areas networks, security, authentication and authorization becomes a major concern. It has becoming increasingly recognized that centralized single system firewalls and authentication/authorization system are inadequate. Many enterprise and process control networks are extremely complex systems and have numerous backdoors, multiple network connections and other weaknesses. The alternate approach is to compartmentalize security by building a complete security suite around each instrument and software web service. Each service or aggregation of services is then responsible for its own internal authorization, authentication and accounting (AAA) each of which also can be exposed as web services and orchestrated into a new service offering. This approach therefore necessitate some sort of delegated certificate security architecture. The whole of security for distributed resources in multiple independent management domains with computer to computer interaction is an entire separate discussion topic in its own right and so will only be briefly touched upon in this document. However, it is believed that by complying to some of the grid standard for security which employ the concepts of delegated certificates and virtual organizations may be the best approach for the management and control of APNs 1.6 Important concepts and assumption presented in this document There are several important inter-related concepts and assumptions presented in this document that will require further analysis and discussion. These are highlighted here to guide the reader through some of the basic design parameters and objectives. It is possible that these design parameters or objectives may not be fully realized in any actual working implementation, but they are presented here to set a framework and a “mind set” of the underlying architectural philosophy, namely: (a) With UCLPv2 the first rule of network architecture is that there is no network architecture; (b) Exposing all software (and/or time slices), hardware processes, network elements, individual lightpath and cross connect as web services; 8
  9. 9. (c) Extension of the “network” into the application and/or computer; (d) Using web services and web services workflow to build a universal control plane capability across instruments, lightpaths, cross connects, networks and software with connections and work flow state maintained by the end user orchestration; (e) Eliminating the concept of network layers which only communicate to the layer above and below such as the OSI 7 layer stack and replacing them with a stack of services which can communicate on a peer to peer basis with any other web services, anywhere in the stack or even outside the network stack; and (f) Using the semantic web with specially developed ontologies or RDF/OWL vocabularies [RDF] for UCLP and instrument web service discovery. These concepts and assumptions are explained in more detail as follows: 1.6.1 No pre-defined network architecture One of the fundamental concepts with UCLP is that there is no need to define, a priori, a network architecture. Instead the user (which may be a network administrator or in some cases an actual end user) may create a network of their choice including topology, routing, network protocols and so forth. One user may wish to create an IP over optical switched network, while another may wish to build an IPv6 or for that matter an ATM network. It is important to note that the resulting network is not necessarily a fixed static architecture. The user can change the network architecture at any time they so wish to adopt to new applications or requirements. The first question that springs to mind with such an approach is how to assure end-to-end universality, which is one of the defining hallmarks of the Internet today. But since one of the fundamental drivers of UCLP is the assumption that the customer will control and/or possibly own the network, and therefore it is in the customer’s own interest to deploy an architecture that provides the greatest end-to-end universality and peers with similar customer owned networks which are similarly motivated. This is in stark contrast with today’s network environment where service providers are trying to build walled gardens, and want to limit universality as it is seen as a competitive threat. Peering between customers may exist at several different levels, and again the assumption here is that is the user or customer who chooses with whom and in what way, they would like to peer with like minded networks. In some case user controlled networks may peer at the optical plane, in other cases they may peer at the IP layer, and in other cases they may peer only at the application layer as for example with VoIP or port 80 peering. Again the important point to stress that is the user or owner of the 9
  10. 10. network, not a nameless, faceless network engineer who makes the decision of how the networks should interconnect and peer. Of course, in many cases, there will be many users who will want to keep their network closed and private and have no interest in peering with others at any plane. Again this should be a user’s choice. Similar to GENI, this adaptability of having no predefined network architecture allows users and researchers to explore new network architectures and concepts. For example one area of interesting research would be to investigate other possible addressing and naming mechanisms as for example using URIs (Uniform Resources Indicators) for end host names and addresses and more traditional IPv4/IPv6 for network addressing. In essence this would eliminate the need for DNS as the actual host name is in the edge forwarding table. Of course there are all sorts of issues with regard to performance and speed as well as memory with effectively unbounded size limits on addresses. This type of research would not be possible on a conventional R&E network. 1.6.2 Exposing web services In terms of the first concept of “exposing” or “atomizing” web services is an assumption that web services will increasingly be less of a “shell” or “wrapper” around a legacy application and be replaced by small native web service applications running on a mini- web server or chip set equivalent in functionality to an Axis/Apache/Linux kernel proxy. Many manufacturers of instruments, software processes, network equipment are already adding these capabilities with the new single chip or single card processors. Exposing services is also one of the key underlying principles of UCLP. UCLP pioneered the concept of rather than building one common generic IP network service for many users, one instead could deploy many parallel networks for individual groups of users. Every lightpath and every cross connect is a service and the concatenation or subtending of these services is also represented as a service. Each of these individual networks on a common substrate has their own separate routing topology and discovery mechanisms. This architecture then makes it possible to extend some of these networks into new areas, which would be impractical with a general purpose IP network, such as deep into the application because every routing node may be in fact a software abstraction rather than a physical device. 1.6.3 Extending the network into the application ”Networks” today are often thought of as physical entities that route or forward packets between “physical” interfaces on computers, routers or switches. By exposing individual application and software processes there is no reason why the network itself can be extended beyond the physical realm deep into the computer or application itself and route packets not only between hardware interfaces, but software interfaces as well. 10
  11. 11. In fact, this was how the original routers in the Internet were originally constructed. The move to specialized high performance routers was required over time because of the sustained high volume packets these devices were required to forward and the increased complexity of routing over the global general purpose Internet network. However by moving from a common IP network with high performance routers to many smaller parallel customer controlled (or owned) or application specific networks or APNs (i.e. routable and reconfigurable VPNs), may enable some these networks to be extended past the physical interface of a computer and be connected directly to the application. Currently routing of packets between software processes is largely done through overlay networks or through virtual interfaces e.g. XML routing, peer to peer networking etc. However by extending the physical network into the software might provide for a more global, seamless and portable applications. URI (Uniform Resources Indicators) addressing could be used rather than IPv4 or IPv6 with ports and sockets. This is described in more detail in Section 4.3 This concept again is similar to the proposed GENI Virtualization architecture to have different time slices on a host linked to different virtual networks. 1.6.4 Web services workflow as a universal control plane This leads us to the third concept of using web services and web services work flow as a common open standard for the control plane, not only of the network but the equipment, routers, switches, time slices and sensors as well. The attraction of using web services as opposed to a myriad number of other control plane mechanisms like GMPLS, ASON, O- UNI, etc is that web services can not only interact with each of these control planes through a wrapper, but also communicate directly with other control plane web services that may or may not be network related. 1.6.5 Network service stack instead of network layers The above concepts can be further extended by thinking of the network itself as a set of exposed web services rather than layers, in such a way that any network service can communicate with any other service, network or not. This has the potential to provide a lot more flexibility into the network layer and also allow the many software concepts of object oriented design, inheritance, etc to be applied to the network in what is sometimes referred to Object Oriented Networks (OON). 1.6.6 Using the Semantic web as a discovery tool To date most network architectures and instrument systems have had a very fixed and defined device and topology discovery protocol generally using a very simple syntactic structure for query and expression. The semantic web with carefully crafted vocabularies and/or ontologies may provide a greater degree of flexibility and allow the intersection of different ontologies for different instrument types and network connectivity. 11
  12. 12. For example an end user is not going to know, or care, about a syntactic structure of end to end network connection made up of AS numbers, IP address and port/slot/channel assignments. Rather they will want to say (most likely use a graphical orchestration tool) "I want a lightpath from my bio-informatics application on my computer at University X to your visualization engine on a computer University Y" The end user does not want to be bothered by complex hierarchical naming structures. In this roadmap we proposed that he UCLP or instrument WSDL query a well known service for a UCLP semantic web server. The semantic web server would then do a distributed search with an ontology cross reference that matched these input requirements. Some third party such as graduate student or another researcher may have already created such a specific end to end lightpath with that name and has offered it up for lease to other parties which would be discovered by the semantic web. If there is no existing lightpath exists then the UCLP semantic web might resolve "University X” to "AS 506" and "University Y" to "AS 403". In turn the semantic web would continue to resolve these highest level hierarchical names to lower names until it can establish a sequence of connection interfaces and cross connects that would form an end to end lightpath. 1.7 Layout of this document This document in Section 2.0 first provides an update and background on UCLP in its current configuration. Understanding the drivers for the development of UCLP will hopefully provide the context as to its adaptability to instrument and sensor networks. Section 3.0 describes new features for UCLP that are required to complete its functionality for use in networks, but more importantly will have applicability in the new emerging sensor and instrumentation grids. Section 4.0 lays out the architecture vision for the UCLP road map followed by specific example scenario in Section 5.0 on how UCLP would work for interconnecting sensor and instrument to a network. 12
  13. 13. 2.0 UCLP status to date In September 2003 CANARIE issued a call for proposals under the Directed Research program to invite university researchers and business to develop a proof of concept for User Control of Lightpaths over the CA*net 4 network. Three teams subsequently undertook to develop the first implementations of the UCLP. Details on these developments can be found at the CA*net 4 UCLP web [UCLP]. Each team undertook an entirely different design approach to the problem. This has proved quite useful in identifying and comparing strengths and weaknesses in the different implementations as well as providing useful directions for this roadmap document. CANARIE staff has deployed and are testing the various UCLP implementations. This UCLP roadmap document is an outcome of these ongoing tests and end user evaluations. As well new developments in Web services and grid technology, particularly the new evolving Web Service Work Flow and Orchestration have provided insight to possible new features for the next version of the UCLP software. 2.1 UCLP description It is important to review the original objectives of the UCLP program and as they are still critical to the future evolution of the concept of user control not only of networks, but also of instruments and software process. This will be fully elaborated further in this document. There still remains considerable misunderstanding about the purpose of UCLP. Some people think it is an alternative optical routing/switching protocol to GMPLS or ASON, while others think that it is an “on-demand” inter-domain or end-to-end VPN protocol. Some people also think it is a bandwidth scheduling and reservation mechanism. It is none of these. UCLP can very simply be thought of as a configuration and partition manager that exposes each lightpath in a physical network and each network element associated with a lightpath as an “object” or “service” that can be put under the control of different network users to create their own logical IP network topologies. Related concepts have been developed elsewhere such as the ITU standards Y.1312 [ITU_Y.1312] and Y.1313 [ITU_Y.1313], and the IETF MEGACO [MEGACO] and General Switch Management Protocols (GSMP) [GSMP]. The primary purpose of UCLP is not yet another optical switching-routing protocol, or to create on-demand, inter-domain and/or end-to-end VPNs. Nor is it intended for the scheduling and reservation of bandwidth. However, as a secondary benefit, the many implementations of UCLP can be used for all these purposes. The major difference between other proposed partition manager protocols and UCLP is the object oriented recursive architecture of UCLP. Rather than one layer of partitioning UCLP assumes that owners of switches and lightpaths will create “root” lightpath (or 13
  14. 14. APN) objects. Once a root lightpath (or APN) object is created, the root can independently create “child” lightpath objects. Each one of these child lightpath objects can have its own independent AAA, routing, topology and end to end lightpath services. In fact it is quite conceivable for the child APNs to use GMPS or other routing protocols across their constituent components. A key assumption when using UCLP is that all the resultant APNs will mostly be used to support the interconnection of “long lived” IP networks. This greatly simplifies the need for inter layer communication and puts the onus of link failure detection and routing on the owner of the APN as opposed to the partition manager. Given that no commercial switch or router supports partition management across multiple domains or this recursive feature of lightpath objects, UCLP was developed as a “proxy” server in front of existing switches and provide this virtual capability of lightpath objects in terms of partitioning both the switches and the associated lightpaths. Grid technology using web services (Globus Toolkit 3.0) as well as Jini/Javaspaces were used as implementation strategies to provide this proxy service for the current UCLP proxy solutions. The advantage of using such tools is that they incorporate proven solutions for security and authentication as well as advertising and discovery of services across independent managed domains. 2.2 UCLP objectives UCLP was intended to address a number of unique and novel business and network models that are only now starting to appear in the marketplace. These new models, for the most part are starting in the same community where the Internet was first developed – universities and research centers. Briefly they are: (a) Customer owned and managed IP networks; (b) Discipline or application specific fine grained IP networks; and (c) User controlled traffic engineering of IP networks These objectives are described in more detail as follows. 2.2.1 Customer owned and managed networks Many large enterprises such as universities, regional networks, government departments and commercial organizations are acquiring their own dark fiber and unprotected, point- to-point wavelengths for their wide area networks. Ideally these institutions want to integrate these wavelengths and dark fiber from different suppliers within their own network management domain. They want be able to do their own topology and discovery and protection and restoral as well as offer value added services such as VPNs (layer 1 through layer 3) as well as APNs to their downstream users. This is not possible if the 14
  15. 15. organization purchases current VPN services, optical or otherwise, from today’s carriers. Current VPN architectures are only single domain, do not allow cross connection between VPNs within a domain, and, as yet do not allow VPNs to cross connected to VPNs in other domains. The UCLP architecture allows a carrier and/or condominium wavelength provider to partition their optical switches and wavelengths to enable different organizations to manage their own partitions independently and link those partitions to partitions in other independently managed networks so that the a comprehensive wide area network solution can be operated by the enterprise. The enterprise can then run its own routing and topology discovery protocols in these partitions and incorporate them within their existing LAN or WAN network. 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 Figure 2.0 National LambdaRail Condominium Wavelength Network A good example of such a model is the National LambdaRail [NLR] network in the United States. This is a classic condominium wavelength network where different organizations own and operate different wavelengths for different purposes. Since each wavelength owner may operate a separate network, and may wish to integrate that lambda with external network services it is not practical to have a central management plane for topology discovery and routing that is typical of most traditional DWDM carrier networks. This is illustrated in Figure 2.0 where one of the condominium partners CAVEwave [CAVEwave], which has acquired one of the lambdas that is part of NLR and wants to do its own add/drop, wavelength routing and partitioning on that specific wavelength independent of the other wavelength owners. It also at some point in the future wish to acquire an additional wavelength outside of the NLR and yet 15
  16. 16. interconnect that new wavelength and use it as an integral part of network with its existing NLR wavelength. UCLP was developed specifically to allow for this integration of wavelengths from other suppliers in different management domains. 2.2.2 Specialized Internet networks for high end applications and/or disciplines Today’s Internet networks (both research and commercial) are generic in design and optimized to serve the average traffic flows and requirements of many thousands of users with relatively small flows. Increasingly however there are small communities of users who have extreme traffic volume per flow requirements, that in many cases dwarf the traffic volumes of regular IP networks. These traffic flows may originate from the newly emerging grids of high performance computers, but are also likely to originate with specialized instruments and sensors. A good example is the collection of data from radio dishes involved in Very Long Baseline Interferometers (VBLI). Another example is the data streams that originate at high energy physics detectors located in various facilities around the world including TRIUMF, Fermilab, CERN etc. Additional examples include acquiring the data streams directly from the charge coupled devices used in astronomy and synchrotron detectors. See next slide for more details University Common DWDM substrate Dept High Energy Physics Network Figure 2.1 Traditional Hierarchical Internet networks CERN Commodity Internet University Research University Network Bio-informatics Network University University eVLBI Network Lab Figure 2.x Discipline Specific Internet networks Because of the size these data flow volumes it makes sense to enable the physical network topology to be more dynamic and responsive to their specific application needs. However, rather than having a network engineer undertaking traffic engineering decisions, as is done today, these can be done by the end users or by their community with UCLP, in effect, creating discipline specific IP networks as illustrated in Figure 2.x 16
  17. 17. Another advantage of such specialized IP networks is that they can be designed to bypass campus firewalls and LAN networks through direct fiber or campus wavelength connections as illustrated in Figure 2.y. Campus Universit DWDM Global Physics Networ Physics Interne Departmen NREN Main campus Borde Health Firewal Networ r Global University eVLBI Network Radio Telescop Figure 2.y Direct Campus Connections This obviates the need for the campus network manager to make a large investment in high end routers, switches and firewall to provide a solution which meets the needs of only a very small subset of their client base who need such capabilities. Campus or corporate network security policies can still be applied to discipline or application specific networks especially with the move away from centralized security systems using firewalls to more compartmentalized security systems based on web services standards. 2.2.3 User Controlled Traffic Engineering A related concept is the enabling of network managers to dynamically undertake their own traffic engineering, based on source-destination IP address block pairs as well as AS paths. Already there are a number of commercial products that look at BGP routing and allow the network manager at the edge, to “pref” the best BGP path based on throughput and other metrics, but this approach can affect the routing of all traffic going through a particular BGP peering. The UCLP approach allows an end user to “create” a new BGP path rather than selecting the best BGP path that may be advertised by setting up direct optical links between managed partitions on UCLP enabled network. In addition with a plethora of lightpaths such as with the National Lambda LambdaRail, it is possible for regional networks and institutes to establish direct peering with each 17
  18. 18. other rather than exchanging traffic through a hierarchy of IP networks as illustrated in Figure 2.1. Other national networks National or Pan-Nationl IP Network NREN A NREN B NREN C NREN D Regional University Figure 2.1 Traditional Hierarchical Internet networks With UCLP and a national DWDM network like CA*net 4 or NLR a much richer peering mesh is possible between regional networks, but also between institutions, and in some cases individual departments as shown in Figure 2.2. In this example a number of UCLP lightpaths (or APNs) have been created over a common DWDM network to enable the direct peering. Some of the lightpaths are across the national DWDM network, but others may be implemented through direct physical connection of the regional networks themselves. The concept of inheritance in the creation of child lightpaths out of parent lightpaths is also illustrated. In this example, the four optical regional advanced networks (ORANs) could each own a wavelength across the national DWDM network such as the NLR. The ORANs could use these wavelengths to create their own national IP networks, directly peer with each other or international partners, or interconnect to national IP network for international peering. Some of the ORANs may partition their wavelength into smaller lightpaths and through UCLP assign control and management of that lightpaths to a downstream client such as university. In turn the university may also further partition a lightpath such that an individual department or server may have a direct lightpath connection. Alternatively a researcher or department could acquire from the regional network or the national DWDM network a direct wavelength or lightpath. Any number of interconnections and peerings are possible. 2.3 UCLP discovery and advertisement 18
  19. 19. In order for end users to discover networks and or devices it was proposed that UCLP use the BGP AS path information as a Uniform Resource Indicator (URI) to a well known UCLP (or AAA) server. Upon finding an end to end path the BGP routing information at each end of the link would be updated to indicate the new path. This process is referred to as Optical BGP (OBGP). As well it was proposed that an existing end to end lightpath which been previously established across multiple partitions and was subsequently not being used by the partition owner could be advertised through well known resource advertisement and discovery tools such as UDDI or WSIL. World World National DWDM Network World Child Lightpaths ORAN A ORAN B ORAN C ORAN D Child Lightpaths Regional University Server Figure 2.2 Richer mesh of direct peering enabled with UCLP In the case of OBGP, the end user’s application would invoke an agent that would query the local border router to get the BGP AS path information to the destination IP address. The agent would then query well known URIs, as for example http://ASxxx.net/UCLP- server to see if a partition could be created to provide a lightpath across that domain to the next associated AS in the BGP path. If a path could be successfully set up then the OBGP agent at each end of the connection would insert a new static route in the forwarding table, so that data packets with the associated destination address would now be redirected along this new route. Because the connection is layer 1 physical connection between interfaces in different domains ARP proxy services may be required, or prior agreement on sharing the same address space. An Internet RFC draft [OPTICAL_BGP] was also written which outlined a process of how lightpath information could be carried in BGP updates. This would allow as user to 19
  20. 20. immediately know which AS system provided lightpath capability. The user would still have to query an OBGP server associated with a given AS as to the availability and policy of the lightpaths. However to date this version of OBGP has not been deployed as it would require router manufacturers to implement it in their routing code. 2.4 UCLP design assumptions and criteria There is often considerable confusion as to whether UCLP is a competing optical network protocol to GMPLS, ASON or other inter-domain optical switching reservation bandwidth protocols. UCLP can be thought of a technology that operates on the layer below these protocols or any other protocol that operate on the network topology discovery and routing layer. Although UCLP can be used for reservation and scheduling of bandwidth and/or lightpaths, that is not its primary intended purpose. In fact, it is still an open question as to whether reservation and scheduling of bandwidth or lightpaths will ever be required in networks. Any application that is “bursty” and requires a lot of bandwidth for a short period of time is probably best served with a high bandwidth routed network. High bandwidth IP networks are designed for statistical multiplexing such types of flows. UCLP, on the other hand is intended to be a user controlled traffic engineering protocol that allows users such as ISPs, enterprises and, in some cases, individual users to setup direct high throughput, or high QoS, long duration IP connections. As mentioned previously UCLP is akin to a partition manager, but with much more functionality and extensibility. Once network elements and links have been partitioned, the respective owners of those partitions may elect to implement their choice of network topology discovery and routing protocol. So rather than one topology discovery and routing plane there may be several parallel topology discovery and routing planes each with independent topologies and routing protocols. As such, with UCLP there is no primary requirement in terms of traditional optical/IP routing to support routing, topology discovery, reservation, scheduling, authorization, accounting, or other related services. However, variations of these services are largely implemented in the current versions of UCLP not so much to support traditional optical/IP routing but to enable partition management applications. It is expected that most of the optical/IP network functionality will be provided by higher layer services operating above the partition layer. Although the services are similar it is important to distinguish between the respective objectives of these services in terms of an optical/IP routing network using GMPLS or ASON versus a partition management service: (a) UCLP does not require a central control plane for the establishment of end to end lightpaths (although a discovery service is required to find the switches that offer partition services and creation of “root” objects); 20
  21. 21. (b) UCLP primary purpose is NOT to offer reservation or scheduling mechanisms of lightpaths, but owners of partitions or root lightpath object may offer this service to users of any child lightpaths that are inherited from the parent or root lightpath; (c) UCLP does not require millisecond provisioning as lightpath root objects or partitions are assumed to be provisioned on a long term basis (d) UCLP does not necessarily require node or link failure error messages to be redirected to partition owner or the root lightpath object owner (as that owner may in fact reside in another independent network domain and like the Internet itself restoral and protection is done at layer 3 independent of failure on the underlying transport); and (e) UCLP does not require crank-back or fail over mechanisms to be provided in the event of a link or node failure as this is a service that can be implemented above the partition or root lightpath object. It should be noted that some lightpath owners may want to operate a routable VPN (APN) where the lightpaths, rather than the packets are re-routed in the event of a link failure. In that case link status information needs to be delivered to the UCLP partition owner in order that the cross connects in that partition can re-route the lightpath. However in most cases it is assumed that a partition owner (as opposed to the switch and facilities operator) who will run and maintain a set of layer 3 routing, topology and fail- over daemons or protocols to provide such services between the partitions on different switches which are under the control or ownership of that specific partition owner. These routing daemons may be a logical router or a blade router that is integrated with the switch. It is the subsequent partition owner’s layer 3 routing protocol that determines link failures, rather than depending on the underlying switch or optical fabric to report outages. It is important to note that a user may have ownership of partitions on switches that are in different physical network domains. As such the user must run their own keep alive or hello messages between each link to detect link or node failure, as well as provide restoral and protection services if required. The underlying physical network providers will have no visibility or awareness of the other networks and cannot provide such a capability. Of course, in an optical/SONET network the routing information can not be done in band and as such the partition owner must use an out of band channel, such as the Internet itself or a common channel provided by the switch owners for this purpose. The later arrangement is the most common in optical/SONET networks and so it is incumbent on the switch owner to provide accessibility to the switch partition through the out of band control channel to the partition owner. This can be easily achieved through industry standard security techniques. 21
  22. 22. UCLP is designed with the assumption that the creation and assignment of partitions of both network elements and lightpaths will be for long duration, in the order of hours and days if not weeks. UCLP was never intended to be a fast switching algorithm for optical circuits. Fast optical switching is required if maximum utilization of limited network resources is required. It is expected that the demand for fast switching, or scheduling and reservation, of optical circuits will become obsolete as the cost of wavelengths continues to drop. Once wavelengths start following the same price curve as semi- conductors users will waste bandwidth rather than incurring higher operational costs on optimizing their utilization through fast switching, or scheduling and reservation mechanisms. Finally it should be pointed out that UCLP can operate on a physical switch or a virtual abstraction of a physical switch. It is not necessary that a network operator expose and partition all their network switches and links within their network. Instead they can offer a “virtual” UCLP service through a well known interface such as O-UNI. To the end user the network cloud appears as single switch entity, but in fact, the “cross connects” across the virtual switch may in fact be facilitated through the creation of edge to edge VPNs across a network cloud. In reality, this is likely to be the most common way for network operators to provide “intra-domain” UCLP services. 22
  23. 23. 3.0 UCLPv2 additional features As mentioned previously not all the features described in the original UCLP architecture have been implemented in the current versions largely for cost and complexity reasons. The first versions of UCLP were developed as a proof of concept to provide the minimal functionality required in a research network like CA*net 4. These additional features representing new services that need to be added to the UCLP software to make it more scaleable and extensible, particularly in new application areas beyond networks. These new features are described briefly as follows: (a) Support for providing layer 3 and/or layer 2 routing and links , topology discovery, and link status daemons in each partition through the use of virtual routers, link failure detection, etc; (b) Graphical tools to allow partition owners to link, create end to end lightpaths and manage their partitions; (c) Resolvers to map IP addresses to port/slot/channel numbers on the switches such as Semantic Web tools, as most applications use IP addresses for end points and interfaces; (d) UCLP extensions for LAN campus networks; (e) UCLP extensions to support interconnection of virtual and/or logical routers and switches; (f) Exposure of all lightpath, cross connect and lightpath creation services as WSDL web services; and (g) Semantic web ontology for describing UCLP services to be used by advertising and discovery service and for describing WSDL web service port types across heterogeneous network types from IP to optical networks As described later in this document it is believed that web services using work flow tools such as BPEL can enable most of these enhancements without major modification to the existing UCLP software. 3.1 Adaptation of UCLP to sensor and instrumentation facilities Early on in the UCLP design process it was recognized that the challenges and problems that UCLP was supposed to address in allowing partitioning and providing user control of an optical network could equally apply in providing users the ability in the management and in the connection of data instruments to the network. 23
  24. 24. One of the primary applications for UCLP was to allow the deployment of application or discipline specific IP networks for specialized high volume uses where instruments that produce large volumes of data need to be connected to computers, grids and/or databases in far away locations. It would make sense therefore not to limit user control to just the network elements but also extend this capability to specific network instruments at one end, and software process at the other end to allow researcher and other users to completely control the entire research equipment connectivity. The grid community is actively addressing the ability for remote user control of software processes through the application of web services to control software process on distributed independent managed on high performance computing facilities. But little has been done to extend this same concept to the other end of the network where the instruments and facilities would be located. This document proposes to lay out an architecture that will allow UCLP to be adapted to instrument and sensor networks as well as addressing some of the newly required features that have been identified for UCLP to support greater functionality for use in CA*net 4 and similar infrastructures. 3.2 Adaptation of UCLP to IP Routed Networks Many modern day routers support sophisticated IP flow structures with advanced queue management. It is proposed in this UCLP Roadmap that UCLP be modified to provide end users to modify certain IP flow management properties through a web services interface and in some cases IP flows be mapped to optical lightpaths and vice versa. The GENI Virtualization program has largely focused on this aspect of the problem. Researchers like Jon Turner et al have done considerable in depth work in this area in the architecture of special routers that can handle the forwarding of packets for the various virtual networks. [TURNER] In UCLPv2 we do not propose to duplicate this effort in creating the special router technology to allow the identification and separation of flows through a router. Instead it is proposed that web services be wrapped around existing tools for creating logical or virtual routers on a larger parent router. The web service tools will allow the owner of the substrate or parent router to create a virtual or logical router and assign one or more interfaces to that router. The interfaces may be SONET STS channels, MPLS tunnels, or GMPLS tunnels. The owner can also assign to a given APN manager and create proper access control tools to the virtual or logical router. The designated APN manager then has access to a limited set of router commands applicable to that virtual or logical router. The range of commands and tools will be largely dependent on the specific of the manufacture and type of router. Once the virtual router is represented as a web service the APN manager has some limited to do configuration and topology management – but this will be far more limited 24
  25. 25. than what is possible on a switch which allows for full inheritance and many sub child arrangements. 25
  26. 26. 4.0 UCLPv2 To address the requirements for these new features in the UCLP software as described in Section 3.0, including extensibility for the integration of sensor and instrumentation grids a new high level functionality for UCLP will be described. This will serve as framework for other investigation into detailed implementation issues and identification of appropriate architectures and tools to support the implementation. The driving technology that will enable this new functionality is the emerging grid/web services technology called Service Oriented Architectures (SOA) built on integrating web services using the emerging web services work flow and/or orchestration tools and platforms for the creation of end to end solutions and the use of the Semantic Web and ontologies for describing and finding resources. 4.1 Definition of a user To fully describe the proposed architecture for the UCLP roadmap a common understanding and meaning must be given to who and what is expected of a “user”. An important philosophical underpinning to the UCLP roadmap is that, as much as possible, all services should be exposed to an end-user and that the end-user has direct control of the various web services and work flow orchestrations. Clearly only some users will be interested in this type of flexibility and control, while to others it represents unnecessary complexity. So to accommodate both requirements we must define different types of users as follows: (a) An “End-user” in many cases will be a researcher or a non-technical user who will have little interest in the concepts of web services and web services work flow and simply wants a working solution or a single abstraction of all the underlying services. An “End-user” does not necessarily need to be a human being. It can also be another web services orchestration which incorporates the current orchestration into another web services abstraction. (b) A “Super-user” will generally manipulate or aggregate published services to produce partial or complete end-to- end solutions for some end-user. Some of these services may in fact be offered as new web services or orchestrations to other super users who will incorporate them within their own work flows or orchestration. Super users may work closely with end users as technical support staff or they may also be third parties such as Virtual Organizations (VOs) who specialize in aggregating complex service orchestrations across multiple administrative domains into new single web service entity. (c) An “Administrative-User” is a special type of “super-user” who has ownership or management control of a given domain and its resources. An administrative- user is a super user within an administrative domain and is responsible for aggregating or orchestrating internal services and/or creating “child” services or work flows that will be advertised as a web service to an external user. An 26
  27. 27. Administrative-user can be an optical network and/or equipment facilities manager or operator. For example an administrative user may aggregate a AAA service with an instrument device and/or internal optical network link to produce a single service instance for secure access to a specific instrument or network device. In this document the generic form of “user” applies to all 3 definitions and does not necessarily imply specifically an end-user or super-user. 4.2 Service Granularity and exposing of services Although all the original UCLP implementations support the use of Open Grid Services Architecture (web services) to varying degrees there was no consistent implementation of such services. As well most of the UCLP implementations developed their own internal database architecture for keeping track of the lightpath objects and their state. A large part of this was driven by the technical nature of SONET/SDH multiplex hierarchy where centralized records had to be maintained in order keep track of the creation of child lightpath objects and their connection status. In this UCLP roadmap it is proposed that a new architecture framework be established that as much as practically possible will push web service constructs down to the smallest network or instrument element and use Web services workflow or service orchestration to bind or concatenate these “services’ together to build a complete network-instrument sensor solution. In the current UCLP implementations only the lightpath creation process is exposed as a web service and each lightpath segment is a simple database entry describing its end points, lightpath ID, owner ID, bandwidth and other relevant parameters. In the UCLP roadmap It is proposed that each lightpath and cross connect be represented as a WSDL web service and that concatenation of lightpaths be done with a web services orchestration tool which creates a new lightpath WSDL web service. Conversely each partitioning of a lightpath and/or cross connect will result in the spawning of a new lightpath service representing the child lightpath and/or cross connect. Probably the easiest way of achieving this is to allow many instances of the current implementations of UCLP (wrapped in web services) to operate on the same proxy platform. More importantly rather than building a priori a hierarchical set of services or abstractions that are permanently linked together, this new framework approach permits a hierarchical set of services to be defined by super-users as required. A simple example is to provide secure access to a UCLP web service for either a single lightpath or a network cloud. Rather than definitely binding a UCLP web service to a security interface such as a AAA server, they can be linked together a service orchestration by a super-user and exposed a single web service to other users – end-users or other super-users. The advantage of this approach is that the AAA service can be orchestrated as single service 27
  28. 28. entry point to a domain of switches or devices (i.e. network cloud) or linked to individual lightpaths and devices as required. Or, if the switch or device can be partitioned into child services it may be desirable to bind the AAA service to only specific child services or partitions. A good model of this more generic solution is to look at WSFL and work flow tools for a variety of grid eScience applications such as the Taverna open source workflow project Taverna [TAVERNA], the Feefluo [FREEFLUO] project, Keppler [KEPPLER] or Active End-Points [ACTIVE]. The Taverna and Active-Endpoint systems are graphic tools that allow users to create web service work flows which constituent parts are various web services. Another good model of a workflow Graphics User Interface (GUI) is LabView [LABVIEW] which is a popular tool for virtualzing instruments and creating workflows by connecting instruments together through a GUI. Graphical workflow tools are analogous to “real time” Unified Modeling Language (UML) tools where software architects can create complex linkages and inter- relationships between many different software sub-routines and modules. Web services are much more loosely coupled than traditional software modules, and through SOAP and HTTP, they now have a common interface language. Both LabView and the new UMLv2 [UMLv2] standard support web service interfaces. This abstraction of a set of services into a workflow web service can allow “super-users” to create innovative, custom, end-to-end workflow solutions that in turn can be advertised to a user community, who may or may not be interested in creating these workflow solutions themselves. 4.3 Moving from network “layers” to network “services” Current network architecture perspectives are largely proscribed by the network layer stack model where each network layer only communicates with layer above and below it and is largely hidden from the end user. However another view is that network is less of an layered set of services, but more akin to a software service, conceptually like the Unix “pipe (|) ” command. The Unix pipe command is a utility that links the output of one software program to the input of another. This concept can now be applied to network services where the network is a software utility that allows data to piped from one application to another. Exposing all network links as individual web services would enable this concept of Unix piping in the wider area not only between end points but between traditional network layers. By viewing everything as a service from the traditional application layer to the physical layer new relationships and linkages can be established between applications, users and networks. 28
  29. 29. For example, traditional routing protocols were designed to forward packets between physical network connected devices. But by abstracting the network into services, the “network” can now be extended past the physical interface into the middle of a computer to a “soft” interface on a software process or web service as shown in Figure 4.0. GENI has a similar concept where individual time slices on a host are connected to different virtual networks. Daemons for layer 3 routing protocols like OSPF, BGP, etc can also be exposed as services and be linked to the software process with web service workflow orchestration tools. So routing of packets can now occur, not only between devices but between processes (time slices) and/or between processes and network devices. Within a single “physical” computer software processes or time slices could be forwarding packets to different interfaces and/or other internal processes at the same time. Moreover different processes or services within a single machine could be integrated into different network APNs. VPN extends into computer to specific processes zzzz:410:0 Time slice or software process Layer 3 WS User A http://10.0. Virtual Routers http://10.0. http://10.0. Routing daemon http://10.0. http://10.0. Time slice or http://10.0. DWDM Software Network process orchestratio instance of Computer Single WS yyyy:410: an or Interface Card or port n With URI addressing User B Figure 4.0 Extending the network into the application Our whole concept of a network now completely changes. Rather than being a physical infrastructure layer that only connects physical devices and lies below the application layer, it can now be a seamless part of the entire distributed application. The “network” can now be deeply embedded into the application and provide a more open and transparent method for forwarding packets from one application to another. Figure 4.0 illustrates to separate APNs or virtual networks with their own separate virtual routers interconnecting to separate processes or time slices on the host computer. In addition on the host computer, in this example, there is a common routing daemon which allows packet forwarding between the two processes. Again all the elements of these 29
  30. 30. APNs are exposed as web services and therefore the APN manager can manipulate or change the architecture and topology any time they wish. Of course, if software processes and/or embedded web services can communicate via a routing protocol with other devices and/or processes the demand for address space will increase significantly. Rather than using URIs for handles and ports, they can also be used to identify interfaces and neighbors for these embedded software networked devices. A physical interface on a computer may advertise itself not only to physical neighbors such as routers and switches but to internal software processes and/or interfaces. Similarly these devices would advertise their URI addresses to the physical interface for packet forwarding. In Figure 4.0 there are two separate routable APNs. The APNs can be at layer 1 or higher layers. But in this example we assume they are operating at layer 1 with UCLP routing daemons located at each optical/SONET cross connect switch. As noted previously each VLAN can be operated independently by the APN owner with their own separate routing protocols and services. More importantly because of the granularity of the APNs it is possible to build one APN with software routing daemons that are embedded within an application as show in the diagram. This would be impractical on a normal routed IP network because of the size of the routing tables and the need for a comprehensive set of protocols for router management, etc. Another simple example illustrates the concept of exposing each layer of the OSI network stack as a network service which can communicate with any other layer or with services outside of the stack. Today many applications send and receive data through a well known port and TCP/IP stack on their computer. The TCP/IP stack assembles the data into packets and manages the actual TCP session with a remote host. Generally there is little flexibility in this architecture. If the application needs to do a large file transfer over long distances this type of “default” arrangement may not be adequate. The current solution today in these situations is to custom assemble special applications protocols for the file transfer. In fact there is a community of researchers who are actively involved in this type of work [PFLDnet]. However, if the application was exposed as a web service then it might be able orchestrate different file transfer techniques based on the size of the file, distance, time to deliver, etc. Each file transfer technique would also be exposed as web services – one might be for best efforts transmission while another may be integrated directly with a optical/SONET channel to provide guaranteed throughput over longer distances. 4.4 Web services for control plane versus data plane To date the primary use of web services has been to encapsulate transaction data for financial and commercial transactions. Consequently the biggest application for web services and related work flow and orchestration technologies has been for e-business applications. 30
  31. 31. Individual financial transactions generally have small data volumes and so the overhead cost of encapsulating transactions within a verbose web services framework has not been that onerous. However the data flows for instruments, sensors and networks can be quite significant, sometimes on occasion in the order of Gigabits per second. Clearly encapsulating this data would be impractical due to the high overhead costs. Therefore in this document it is proposed that the web services constructs and workflows or orchestration be used with the control plane to setup “pipes” and or linkages to enable the rapid flow of un-encapsulated data between services. Traditional web services are designed for transaction based interactions, but since the establishment of pipes or linkages requires maintaining state, “state full” web services are required such as WSRF. However, another approach is to use orchestration and workflow tools such as BPEL or Keppler to maintain state. There is still an open debate as to which is the best approach. But increasingly it is seen that tools like BPEL offer true object oriented characteristics with inheritance and long lived state and as such are more suited to instrument grids, as opposed to WSRF. Over the past decade there have been several message passing and object oriented protocols have been developed such as CORBA, DCOM, Jini/Javaspaces etc. Each protocol has had a difficult time dealing with the issues of dealing with generic failures, healing of state-full partitions, graceful degradation of guarantees in the presence of partial failures, etc. The attraction of WSDL and workflow tools such as BPEL and Keppler is that they are not designed to replace existing protocols that handle these issues extremely well. What WSDL and web service workflow tools enable is a common interface between existing and new processes. WSDL and BPEL are more akin to provisioning and configuration tools to link together existing state-full processes. The underlying processes and protocols maintain actual state of the process and handle disruptions, outages, etc. Although BPEL specifically supports state through correlation sets it is not the intent in this framework document to use such tools to maintain state in the BPEL linked processes. Hence there is no intent to replace existing routing protocols like OSPF or BGP, but instead give the user greater flexibility of WSDL and BPEL in configuring networks and software processes. The other aspect of WSDL and BPEL that is appealing is that they are built on a much simpler paradigm of the web itself. They allow for the very simple concept of linking text and images through embedded http pointers to be extended to processes. And because WSDL and BPEL (which really is a specialized version of WSDL) use URI structures there is no predefined data types and constructs that must be adhered to by developers in order for their applications to communicate with each other. The data types and the message passing is defined through http itself using SOAP bindings. 4.5 UCLP (WSDL) Proxy for Instruments and Sensors 31
  32. 32. Most instruments and sensors used in research applications and process control have some characteristics similar to that of optical cross connect switches. They assume a single management entity and are intended to connected to a communication medium through a fixed long term configuration, usually through a single LAN interface or serial port. However increasingly researchers are recognizing it would be useful to be able to independently link or “bind” these devices to different systems such as networks, APNs and software services, particularly when these instruments may be shared by different teams of scientists at multiple institutions. Connecting the instrument to a lightpath may be one of many types of “bindings” that could be required. Other possible bindings would be to connect the instrument or sensor to an IPsec tunnel for secure transmission of data, or to another instrument in order to correlate or calibrate data flows. Of course, today this can all be done by network managers just as easily as they can setup lightpaths across an optical network without using UCLP. But the purpose of UCLP is to allow end users to do their own configuration management and bindings without the need to signal or request permission from a network operator to provide such a service. The same principle could be applied to connection of remote instrumentation to computers and servers located at a home institution. As part of the UCLP roadmap it is hoped that a couple of sensor or instrumentation facilities can be identified that would be willing to implement a UCLP proxy server to allow user control of the instrument as well as the ability to create daughter services and other features that are currently available with UCLP for optical switches. An open question remains is whether child services should be described as workflows (orchestrations) or state-full web services. In order to do this, the current versions of UCLP must become more generic and not assume that the only things they are concatenating or binding are lightpaths. More importantly it would be useful to describe lightpath objects as a web service - WSDL (or perhaps a web service work flow which can also be expressed as web service) in their own right. This allow a user to link together an instrument and a software process through a UCLP “service” as is currently available today, but also to discover existing pre- configured lightpaths that may have been created by a previous invocation of UCLP. Many of these other services already exist in one form or another and are used by specific science teams around the world. But few of them have been adapted to serve a number of different science disciplines or allow seamless integration with other services. A good example of a prototypical web service based sensor network is ROADnet [ROADNET] -. And a good example of a prototypical set of common database and network services for multiple science disciplines is the US Integrated Ocean Observing System Plan [ORION] using the Open Source Project for Network Data Access Protocol (OPeNDAP) [OPENDAP]. 4.6 Semantic web, WSIL and UDDI for path discovery and resolution 32
  33. 33. As in the original UCLP design one of the key “services” that must be first invoked is a path discovery and harvesting service. The path discovery and harvesting service can be a web service in its own right or be a “harvesting” tool to find and locate appropriate web services that describe all the possible segments between a source and destination. Path information can consist of AS numbers, IP addresses of routing/switching devices along the path, and/or slot port/channel interface identifiers of devices along the path. 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 BCnet Neptune Instrument WS UCLP Lightpath WS Winnipeg Vancouver CA*net4 CA*net4 Seattle Montreal CA*net4 CA*net4 UCLP Chicago New York Cross Connect Seattle CA*net4 Pwave MAN LAN WS Chicago STAR LIGHT Figure 4.2 Possible graphical representation of UCLP web services The path service can query a border router for the AS inter-domain path and/or an internal routing metric such as OSPF or ISIS to get the intra-domain path information. But the path discovery service must be also capable of discovering pre-configured partial or complete end to end lightpaths that bypass existing hop by hop connections. So a combination of UDDI, WSIL and topology discovery tools is needed. It is expected that most APNs, and/or lightpaths will be expressed as existing WSDL services (or factories). They will not created on demand. The pre-established web services most likely will be “permission sets” to an existing UCLP service where there those who meet the required criteria will be to create a lightpath within a limited domain, or actual nailed up lightpaths between specific end- points. Path connections may also use different sets of descriptors for bandwidth (e.g. OC3 versus 155 Mbps), connection types and channels. Intersection of ontologies or RDF vocabularies may also be needed as different disciplines may describe connection port types differently or with different relationships. 33
  34. 34. Ultimately it is essential that this information harvested from topology discovery services, UDDI and WSIL resource brokers be presented graphically with each UCLP web service graphically illustrating the various connections available to other web services. This is illustrated in Figure 4.2 A graph connections tool can be built on top of any Keppler, Taverna or one of the commercial BPEL visual scripting engines. One possible scenario would be for the user to click and drag the required connections to create an end to end lightpath from the Neptune instrument to the visualization engine. With each click and drag operation the underlying web service for either a lightpath or cross connect would be queried for the availability of a service that meets the specified requirements of the lightpath. 4.7 Extending UCLP to the LAN There are already several tools that allow end users to create their own VALNs within a campus network environment [VLAN-UBC], [VLAN-McGILL]. Some of these tools also allow users to create nested VLANs similar in concept to creating child lightpaths. It therefore is not a great leap in complexity to extend the UCLP concept to user controlled campus VLANs. All that is required is to wrap these existing services in web services and allowing multiple instantiations of such services. Network administrators or “orchestration engineers” could provide orchestration services to users, or create orchestration on behalf of users linking a VLAN web service to an external lightpath web service. This is illustrated in Figure 4.3 Campus Border Router End user Standard Ethernet Links VLAN External Lightpath 802.1 p/q VLAN Lightpath Creation Web Service Workflow Service VLAN to LightPath Cross Connect W eb Service Figure 4.3 Exposing Nested 802.1 p/q VLANs as web services 34
  35. 35. 5.0 UCLP Next Generation Scenarios using workflow The following scenarios will attempt to illustrate the use of web services work flow or orchestration as a tool for linking remote instruments to users or computers over a user controlled optical network and create a private application specific IP network. The details presented are examples of how the underlying web services may be scripted, but to the actual user it is expected that the primary interface will be through a specialized GUI modeled on Taverna or Keppler such that the user can click and drag to connect the various services together. 5.1 Creating a simple APN linking instrument to a visualization engine This scenario is made up of several components to illustrate aspects of the proposed roadmap for UCLP as illustrated in Figure 5.0. The scenario will demonstrate the connection of a remote undersea instrument such like that would be used in the Neptune project to a visualization engine located many thousands of kilometers away across four independently managed networks – BCnet, CA*net 4, CAVEwave ( using a partitioned wavelengths on NLR) and OMNInet. It is assumed in this scenario that the instrument will produce extremely large data volumes and therefore will require dedicated lightpaths. However, the same scenario could be used for small data flows where some other end to end network service could be required such as IPsec. Neptune Neptune Lightpath Instrument WS Winnipeg Calgary CA*net 4 Seattle NLR Visualization Optiputer CAVEwave Engine Chicago Lightpath OMNInet Figure 5.0 Orchestration scenario to connect instrument over network There will be 4 different types of networks used in this scenario. It is assumed the Neptune Instrument Web service (which in fact is a proxy running on a land based 35
  36. 36. server) will be connected via an IP flow QoS service or MPLS tunnel to a BCnet router. The router interface supporting that flow is then connected to lightpath on the CA*net 4 network, which is then cross connected to a partitioned lightpath provide by the CAVEwave at the Pacific Wave exchange point in Seattle. The CAVEwave lightpath (which is a partitioned lambda on the NLR) is then connected to the OMNInet O-UNI network in Chicago. From there the lightpath finally terminates on a visualization engine at the Electronic Visualization Laboratory at the University of Illinois. Each network will have its own independent authorization and policy management mechanism. In this scenario the CA*net 4 lightpath for Neptune will also orchestrate a separate policy and access mechanism that is different than that for the underlying CA*net 4 network itself. As a first step CAVEwave and Neptune must acquire lightpaths from CA*net 4 and NLR respectively. It is assumed that NLR and CA*net 4 have UCLP implemented on their respective networks. Both NLR and CA*net 4 engineering staff would create APNs on their respective networks for the use of Neptune/BCnet and CAVEwave respectively. The researcher or Neptune “super-user” would then see a number of web services for lightpaths and cross connects that have been “harvested” and/or discovered as illustrated in Figure 4.2. The super-user would then create a complete end to end orchestration as detailed further in this document. The Neptune “super-user” described in Section 5.2.2 has the most important job of “harvesting” or “discovering” the various web services representing APNs or lightpaths in each domain and then linking these together to create a complete end-to-end solution from instrument to visualization engine. In this scenario there will be at least four “Administrative-users” who will be have control of networks and facilities in their respective independent managed domains. The Administrative-users performing the critical role of defining which web services will be exposed and how they will be advertised to third parties. The Neptune super-user will then harvest these advertised web services to create their own orchestration. 5.2 Different users and different orchestration views Probably the best way to understand service orchestration is to think of it being analogous to of the familiar concept of specialized web pages where web-masters or “super-users” create web pages on specific topics that link to other web pages. This makes it easy for “end-users” who have a particular interest on a given topic to find one canonical source to all related web sites for that specific topic. It is expected that similar “orchestrations” of web services will be done by super-users rather than end users by themselves. As well users of all kinds will be able to use search and discovery tools to find appropriate services that are of specific interest to them. It is assumed that every user, whether they are an end-user or super-user has a specialized graphics orchestration work flow similar to Keppler, except that it can display geographical relationships as well as workflows. The orchestration graphics tool actually creates the orchestration XML scripts for the binding together of various selected web 36

×