[CAnet - news] Request for Proposals for UCLP with web services worflow capabilities

For more information on this item please visit the CANARIE CA*net 4 Optical
Internet program web site at http://www.canarie.ca/canet4/library/list.html
-------------------------------------------
La version Française suit...

Request  for Proposals (RFP) for a Production Version  of UCLP with Graphics
Interface and Web Service Workflow capability

1.0 Introduction

CANARIE Inc. is pleased to invite the submission of  proposals for the
delivery of a production version of User Controlled LighPath software to be
deployed on the CA*net 4 network.  The purpose of this RFP is to adapt the
development of the User Controlled LightPath (UCLP) software developed under
the Directed Research program in 2003-2004 and make it robust and user
friendly for wider scale deployment by providing a graphical user interface
and providing web service workflow capability. 

This call for proposals is competitive, and is intended to encourage the
definition and implementation of innovative solutions, whether individual or
collaborative.  The successful respondent to the RFP should demonstrate a
robust working product that allows users to control, manage, partition and
advertise their Lightpaths across the CA*net 4 network infrastructure
through a graphical interface, as more fully described in the following
sections.

Respondents to this RFP can be from either the public or the private sector.

2.0 Program Budget and Project Size 

The budget for this RFP  is $1 million. However the maximum allocation to
any single applicant is expected to be no more than $500,000.  

3.0 RFP Objectives

The overall objective of the RFP is the delivery  and development of  a
robust production version of UCLP with a user friendly graphics user
interface and support for web services workflow.

The specific objectives of this program are to:

3.1 Develop software solutions that will allow users on any UCLP enabled
network to graphically control designated cross connects on designated cross
connect devices  which:

(a) allows the creation of Articulated Private Networks (APNs) where each
cross connect device, or groups of devices, may be in separate management
domains;
(b) exposes all lightpaths, interfaces and lightpath creation tools as web
services that can be incorporated into workflow tools and services;
(c) automatically integrates and graphically displays all available
lightpaths and interfaces within a network of cross connect devices in a
physical single domain network or previously created  APN as further
detailed in the attached Appendix;
(d) allows a user or administrator to graphically create APNs as web
services and graphically display specific attributes and assign ownership
and control of lightpaths and interfaces to a third party;
(e) allows authorized third parties to launch their own graphics interface
running on another computer and graphically display a number of “harvested”
APNs and link them together graphically or partition them and in turn create
a new APN web service that can be advertised to other third parties ;
(f) allows a user to integrate logical routing (OSPF, BGP, ISIS) web
services or logical switching GMPLS web services with the lightpath or APN
web services;
(g)  communicate with destination and source routers to create a new BGP
forwarding path along established lightpath;
(h) allows an administrative user a convenient way to visualize current and
futures resources utilizations, e.g. by user or group of users, by time
period, etc; 
(i)  synchronize network’s resources utilization with their own resources
stored in its multiple distributed databases and/or java spaces in a
real-time manner;
(j)  allow the creation of mapping tables that users can use IP addresses
rather than slot/channel/port/wavelength to indicate endpoints; and
(k) allow cross connect status and alarm information to be displayed to the
administrative and APN graphical user interface.


3.2 Develop simple prototype instrument web services that will interface
with APN lightpath web services and will allow end to end network-instrument
solutions to be established using web services workflow tools;

3.3 Develop UCLP interfaces for QoS routed devices and intra-domain 802.1
p/q networks so that dedicated bandwidth channels can be established across
the LAN and interconnect to a WAN provided lightpath

3.4 Develop simple prototype web service wrappers for logical routing nodes
(OSPF, ISIS or BGP) and GMPLS so that they can incorporated with lightpath
or APN web services to create a routable APN.

3.5 Interoperate with other possible UCLPv2 deployments that are funded
under this program;

3.6 Provide at least one year’s support and enhancements to the software
after the final deliverable is accepted by CANARIE

3.0 Project Selection Criteria

It is expected that a high degree of interaction with CANARIE staff and
other awardees will be required through the duration of the project. Project
proposals should make allowances for numerous design and review meetings
with CANARIE staff and other project awardees through the duration of the
Project.

Projects approved will be selected through a competitive process. All
proposals will be reviewed by CANARIE staff relative to the following
criteria: 

a)	The applicant’s demonstrated ability and past experience to develop
and deliver on time complex software such as UCLP;
b)	The applicant’s demonstrated knowledge and understanding of the
UCLPv2 roadmap, Grid Canada Certificate Authority and Service Oriented
Architectures (SOA) with web services, web services security and workflow;
c)	The quality and the detail of the applicant’s submission and
costing;
d)	The applicant’s ability to insure a permanent team will be in place
during the development of the project and for a minimum of year period
following its completion to provide software support, warranties and changes
to the software as requested by CANARIE; and
e)	The applicant’s ability to develop the software and support third
party users within an open source environment..


Interim payments will only be made at the completion of specific milestones
as determined by CANARIE and the applicant, and upon demonstration of costs
incurred.

The successful applicant must provide a functioning product equivalent to an
industry standard “beta release” product at the end of the Project. The
applicant must commit to supporting the product and correcting bugs or other
problems for at least one year after delivery of the final product.  The
cost of one year’s maintenance and support should be included in the project
budget.

4.0 Process

Applicants should first consult with CANARIE staff on some of the detailed
technical requirements before making a submission. Please contact
[email protected] or [email protected] for more technical
information.

Completed detailed proposal should be sent via Email by April 30, 2005 to
[email protected]. The proposal must include:

(a) Detailed software architecture describing all functionality, plugs,
sockets, etc;
(b) Draft XML schema, WSDL descriptors, workflow orchestrations;
(c) Sample screen shots of graphical user interfaces;
(c) Detailed milestones and deliverables;
(d) Who will be involved;
(e) How much it will cost; 
(f)  What upgrades and warranties will be offered; and
(h) How the open source support will be provided.

Proposals will be assessed by a committee made of CANARIE staff with
external reviewers for additional subject matter expertise. Approved
proposals will then be submitted to CANARIE's Executive Committee for final
approval (a non-competitive process) and you will be asked to sign a
standard contract. The entire process typically takes 4 to 6 weeks

** All projects will have to be completed by March  30, 2006**


 
Appendix

Specific graphical user interface (GUI) requirements for UCLPv2

1.0 Definitions:

1.1	An APN is a web service that describes a collection of individual
lightpath and interface web services that are grouped together within a
larger web service representing  a  mesh, straightline or some other
topology.
1.2	A single domain physical network is a facility where a single
administrator has control and management of the various switches and routers

2.0  The Graphical User Interface (GUI) must display geographically various
links, interfaces and nodes in a physical network or APN

2.1 As an input the GUI must operate in a manner similar to Cisco CTC, HP
Openview, Nortel Preside and similar graphical network management interfaces
which have these features:
2.1.2 Allows user to specify a geographical map as a JPEG, GIF or other
format as a background
2.1.3 Drag or nudge icons representing lightpaths, switches or APNs to their
proper geographical representation


2.1The GUI can display either 
(a) the actual physical links, interfaces and nodes of a single domain
network; or
(b) the links, interfaces and nodes of an existing APN; or
(c) all assigned APNs in an existing physical network or APN; or
(d) individual specified APNs within an existing network or APN


2.2 An physical network administrative user can elect to see all APNs and
lightpath web service and/or unallocated facilities on their network

2.2.1 The GUI must show the complete inventory of all links and nodes from
single domain network system (or manager) or for a given APN all links and
nodes and stay synchronized with network inventory

2.3 Through the GUI a user can:
(a) create a new APN by partition existing lightpath WS within APN or
physical network; or
(b) modify existing an APN by harvesting external APNs and attach to the
existing APN; or
(c) modify existing APN by changing the configuration of the interfaces or
lightpath WS

3.1 The GUI is used to create new APNs using as input:
(a) the available bandwidth,  physical links and interfaces in a single
domain network and existing APNs; or
(b) an existing APN in order to partition, change node permissions or
concatenate to other APNs

3.1.2 The GUI can also "harvest" on demand lightpath creation services
and/or other APNs and link these to the existing APN to create a new APN

4.1 Through the GUI the user creates a series of lightpaths which are then
exposed as WS by dragging and dropping the mouse (like drawing a freehand
line in power point)

4.2 The lightpath web services do NOT have to be end to end, but in most
cases be small segments that encapsulate one ore more physical switches,
interfaces and/or links.  A user CANNOT see the individual components that
make up a given lightpath WS.

4.2.1 If user wants change the cross connect or interfaces at the end of a
lightpath WS or APN Ws, these must be exposed as separate web services
within a given APN

4.3 To create an APN the user uses a click and drag motion as if drawing a
freehand line in Powerpoint (or they can manually assign each Lightpath WS
to a specific APN WS).  Each click starts a new lightpath WS.  The APN WS
describes the set of all lightpaths WS.

4.4 When a user creates a lightpath or (perhaps at the end of creating an
APN) they can set permissions at the interfaces, set the size of the
lightpath (or APN), lease length, set cross connect and interfaces
permission, etc

4.5 The lightpath  WS or APN WS may in fact be simply a WS interface to an
existing UCLP implementation

4.6 The GUI can also be used to create an APN that links to an "on-demand"
lightpath WS - which would simply look like an end-to-end lightpath WS from
ingress to egress point on a network cloud.  However, it is expected that
the administrator of “on demand” service may initially create some
pre-assigned APN or Lightpath WS they can be discovered or harvested by the
user

5.0 At each end of an individual lightpath WS, the user can right click the
mouse and see what possible cross connects may be possible. There many be
more cross connects available than lightpaths. The right click would also
initiate a "harvesting" of all other APNs that might touch that same node
who are willing to cross connect

5.1 The GUI can be also by a user to change the cross connects at a node. If
it is an intermediate node at the end of a lightpath WS- then the effect is
to create 2 new APNs .  

6.0 Using GridNexus, Kepler or BPEL a third party can take an APN WS and
incorporate into a workflow with other WS

-----------------

Demande de propositions en vue de la production d’une version finale du
logiciel CROU avec interface graphique et fonctionnalités de service Web

1.0 Introduction

CANARIE inc. est heureux d’inviter les intéressés à lui soumettre des
propositions en vue de la création d’une version finale de son logiciel de
Commandement des routes optiques par l’utilisateur (CROU) et de son
déploiement sur le réseau CA*net 4. L’idée est d’adapter ce logiciel, mis au
point dans le cadre du Programme de recherche heuristique de 2004, afin d’en
accroître la robustesse et la convivialité en prévision d’un déploiement à
plus grande échelle par l’élaboration d’une interface graphique et l’ajout
de fonctionnalités semblables à celles d’un service Web.

La demande de propositions se fera par voie de concours et a pour but de
favoriser le développement et l’exploitation de solutions novatrices,
élaborées individuellement ou collectivement. Le candidat dont la
proposition sera retenue mettra au point un prototype robuste qui permettra
à l’utilisateur de maîtriser, de gérer, de diviser et de faire connaître ses
routes optiques sur l’infrastructure du réseau CA*net 4 grâce à une
interface graphique dont on trouvera une description plus précise dans les
pages suivantes.

Peuvent répondre à cette demande de propositions les membres du secteur
public ou du secteur privé.

2.0 Budget du programme et envergure du projet

La présente demande de propositions dispose d’un budget de un million de
dollars. Toutefois, le maximum alloué à un candidat ne devrait pas dépasser
500 000 $.

3.0 Objectifs

L’objectif général de la demande de propositions est le développement d’une
version finale robuste du CROU pourvue d’une interface graphique conviviale
et de fonctionnalités permettant le soutien de services Web au niveau de la
transitique.

Plus précisément, les objectifs sont les suivants :

3.1 Concevoir des solutions logicielles qui permettront à l’utilisateur d’un
réseau quelconque habilité par le CROU de contrôler graphiquement des
connexions transversales à partir de répartiteurs donnés autorisant ce qui
suit :

a) la création de Réseaux privés articulés (RPA) dans lesquels chaque
répartiteur ou groupe de répartiteurs pourra se trouver dans un domaine
administré séparément;
b) l’affichage de la totalité des routes optiques, des interfaces et des
outils de création de trajets optiques sous forme de services Web qu’on
pourra intégrer aux instruments et aux services de transitique;
c) l’intégration automatique et l’affichage des routes optiques et des
interfaces disponibles sur un ensemble de répartiteurs dans un réseau
physique à domaine unique ou dans un RPA déjà défini, conformément à la
description donnée dans l’annexe;
d) la création graphique de RPA sous la forme de services Web par
l’utilisateur ou l’administrateur du réseau et l’affichage de leurs
attributs spécifiques ainsi que de l’affectation et du contrôle des routes
optiques et des interfaces par des tiers;
e) le lancement d’interfaces graphiques fonctionnant sur d’autres
ordinateurs par les tierces parties autorisées et l’affichage des RPA
regroupés ainsi que des liens les raccordant ou les séparant, de manière à
engendrer une nouvelle toile de services Web sur RPA qu’on pourra proposer à
des tiers;
f) l’intégration des services Web à routage logique (OSPF, BGP, ISIS) ou des
services Web GMPLS à commutation logique aux services Web à route optique ou
RPA;
g) la communication avec des routeurs de destination ou d’origine, de
manière à créer un nouveau circuit de transmission BGP le long de la route
optique établie;
h) la visualisation facile de l’exploitation actuelle et future des
ressources par l’administrateur, à savoir exploitation par un utilisateur ou
un groupe d’utilisateurs, par période, etc.;
i) une synchronisation en temps réel des ressources exploitées du réseau et
des ressources stockées dans des bases de données multiples, des espaces
java ou les deux;
j) la création de tables de cartes dont les utilisateurs pourront se servir
comme adresses IP pour indiquer les points terminaux, à la place des
concaténations du genre logement/canal/port/longueur d’onde;
k) l’affichage de l’état des connexions transversales et des avertissements
sur l’interface graphique des administrateurs et des exploitants de RPA.


3.2 Élaborer des prototypes d’instrument simples pour services Web qui
pourront servir d’interface avec les services Web optiques des RPA et
permettront l’implantation de solutions intégrales instruments-réseau à
partir des outils de transitique des services Web.

3.3 Mettre au point des interfaces CROU pour la qualité de service des
dispositifs routés et les réseaux intra-domaine 802.1 p/q afin qu’on puisse
établir des routes optiques d’une largeur de bande dédiée à la grandeur du
RL et raccorder celui-ci à un RE par route optique.

3.4 Créer de simples enveloppes de services Web pour les nœuds de routage
logiques (OSPE, ISIS ou BGP) et GMPLS en vue de les intégrer aux services
Web des routes optiques ou des RPA, de manière à obtenir un RPA qu’on pourra
router.

3.5 Assurer l’interopération avec d’autres projets éventuels de déploiement
de la version 2 du CROU financés dans le cadre de ce programme.

3.6 Dispenser au moins un an de services de soutien et de perfectionnement
au logiciel après remise d’un produit final acceptable à CANARIE.

3.0 Critères de sélection

Une grande interaction avec le personnel de CANARIE et les autres candidats
retenus sera indispensable pendant la durée du projet. La proposition
devrait tenir compte de nombreuses rencontres avec les employés de CANARIE
et les autres candidats retenus au chapitre de la conception et de l’étude
du projet lors de sa réalisation.

Les projets retenus le seront par voie de concours. Toutes les propositions
seront étudiées par les employés de CANARIE en regard des critères que voici
:

a)	capacité manifeste du candidat de créer un logiciel aussi complexe
que le CROU et de le remettre dans les délais impartis, et expérience en la
matière;
b)	connaissance évidente de la carte routière du CROUv2, du régime de
certification de Grid Canada et des architectures orientées services (AOS)
dans le contexte des services Web, de la sécurité des services Web et de la
transitique;
c)	qualité et précision de la proposition et du budget du projet;
d)	aptitude à garantir la permanence d’une équipe pendant la
réalisation du projet et au moins l’année qui en suit la conclusion, de
manière à dispenser le soutien voulu, à respecter les garanties et à adapter
le logiciel en fonction des demandes de CANARIE;
e)	aptitude à élaborer un logiciel et à soutenir les utilisateurs dans
un environnement d’exploitation libre.


Les paiements provisoires se feront uniquement à des jalons précis
déterminés par CANARIE et par le candidat, sur preuve des frais encourus.

Le candidat retenu devra fournir un produit utilisable équivalent à la norme
bêta en usage dans l’industrie à la fin du projet. Il s’engagera de surcroît
à soutenir le produit et à corriger les bogues et autres problèmes qui
pourraient survenir durant l’année suivant la remise du produit. Le budget
du projet devrait inclure le coût d’une année de maintenance et de soutien.

4.0 Processus

Les candidats devraient consulter le personnel de CANARIE pour en savoir
plus sur les contraintes techniques du projet avant de soumettre une
proposition. On communiquera avec [email protected] ou
[email protected] pour obtenir les précisions techniques nécessaires.

La version détaillée de la proposition devrait être envoyée par courriel
avant le 30 avril 2005 à [email protected]. Elle inclura ce qui suit
:

a) architecture détaillée du logiciel indiquant les fonctionnalités, les
connexions, les connecteurs logiciels, etc.;
b) ébauche du schéma XML, descripteurs WSDL, voies de la transitique;
c) échantillons des écrans de l’interface graphique;
c) liste détaillée des jalons et des résultats livrables;
d) liste des personnes qui participeront au projet;
e) coût du projet; 
f) mises à niveau et garanties offertes;
h) soutien assuré en exploitation libre.

Les propositions seront évaluées par un comité composé d’employés de CANARIE
et d’examinateurs de l’extérieur possédant l’expertise voulue dans certains
domaines. Les propositions retenues seront ensuite présentées au comité
exécutif de CANARIE qui prendra la décision finale (évaluation restreinte).
Le candidat retenu sera prié de signer une entente standard. En tout, ce
processus demande habituellement en 4 à 6 semaines.

** Tous les projets devront être achevés le 30 mars 2006.**


 
Annexe

Exigences spécifiques concernant l’interface graphique (GUI) du CROUv2

1.0 Définitions

1.1	Par RPA, on entend un service Web constitué d’un regroupement de
services Web sur routes optiques et sur interfaces dans un plus vaste réseau
de services Web à topologie maillée, rectiligne ou autre.
1.2	Par réseau physique à domaine unique, on entend un réseau dont les
commutateurs et les routeurs sont contrôlés et gérés par un seul
administrateur.

2.0 L’interface graphique (GUI) affichera les connexions, les interfaces et
les nœuds géographiquement distincts du réseau physique ou du RPA.

2.1 En tant qu’entrée, l’interface fonctionnera d’une manière analogue aux
interfaces CTC de Cisco, Openview de HP, Preside de Nortel et aux interfaces
similaires qui autorisent la gestion graphique d’un réseau possédant les
caractéristiques que voici :
2.1.2 il permet à l’utilisateur de présenter une carte géographique en
format JPEG, GIF ou autre sur l’arrière-plan;
2.1.3 il permet de faire glisser ou bouger des icônes correspondant aux
trajets optiques, aux commutateurs ou aux RPA sur la carte qui les situe.


2.1 L’interface graphique montrera un des groupes d’éléments qui suivent :
a) les connexions physiques, les interfaces et les nœuds réels d’un réseau à
domaine unique;
b) les connexions, les interfaces et les nœuds d’un RPA;
c) tous les RPA affectés à un réseau physique ou à un RPA existants;
d) les RPA individuels d’un réseau ou RPA existants.


2.2 L’utilisateur-administrateur d’un réseau physique pourra choisir de voir
l’ensemble des RPA et des services Web optiques, les ressources non
attribuées du réseau ou les deux.

2.2.1 L’interface graphique montrera la totalité des connexions et des nœuds
du réseau à domaine unique (ou à un administrateur) ou l’ensemble des
connexions et des nœuds d’un RPA donné tout en maintenant à jour
l’inventaire des ressources du réseau.

2.3 L’utilisateur pourra se servir de l’interface graphique pour faire ce
qui suit :
a) créer un nouveau RPA en divisant la route optique personnelle dans un RPA
ou un réseau physique;
b) modifier un RPA en y greffant d’autres RPA;
c) modifier un RPA en changeant la configuration des interfaces ou des
routes optiques personnelles.

3.1 L’interface graphique permettra de créer de nouveaux RPA à partir de ce
qui suit :
a) la largeur de bande, les connexions physiques et les interfaces
disponibles dans le réseau à domaine unique ou le RPA existants;
b) un RPA existant par sa division, la modification des nœuds autorisés et
le regroupement d’autres RPA.

3.1.2 L’interface graphique permettra aussi le regroupement des services de
création à la carte de routes optiques, d’autres RPA ou les deux, et leur
raccordement au RPA existant afin d’en créer un nouveau.

4.1 Grâce à l’interface graphique, l’utilisateur produira une série de
routes optiques qu’on présentera ensuite comme des postes de travail en
faisant glisser la souris (un peu comme on trace une ligne à main levée dans
PowerPoint).

4.2 Les services Web optiques ne seront PAS nécessairement des services de
bout en bout. Dans la plupart des cas, il s’agira de petits tronçons
englobant des commutateurs physiques, des interfaces et des connexions.
L’utilisateur ne verra PAS les composants qui constituent une route optique
personnelle.

4.2.1 Pour que l’utilisateur puisse les modifier, les connexions
transversales ou les interfaces à l’extrémité d’une route optique ou d’un
RPA devront avoir l’apparence de services Web distincts d’un RPA donné.

4.3 Pour créer un RPA, l’utilisateur cliquera et glissera la souris comme
s’il traçait une ligne à main levée dans PowerPoint (il pourra aussi
affecter manuellement chaque route optique personnelle à un RPA spécifique).
Chaque déclic servira de point de départ à une nouvelle route optique
personnelle. Le RPA personnel indiquera l’ensemble des routes optiques
personnelles qu’il regroupe.

4.4 Quand il crée une route optique (ou peut-être une fois que le RPA est
terminé), l’utilisateur pourra accorder des autorisations au niveau des
interfaces, établir la taille de la route optique (ou du RPA), déterminer la
durée du bail, définir les connexions transversales et les autorisations
pour les interfaces, etc.

4.5 La route optique ou le RPA personnels pourraient aussi bien se résumer à
l’interface d’un simple poste de travail que correspondre à une application
existante du CROU.

4.6 L’interface graphique pourra aussi servir à créer un RPA relié à une
route optique personnelle sur mesure, soit une route optique de son point
d’entrée dans un nuage de réseaux à son point de sortie. Néanmoins, on
s’attend à ce que l’administrateur du service à la carte crée d’abord un RPA
ou une route optique personnelle que l’utilisateur pourra ensuite découvrir
et exploiter.

5.0 À la fin de chaque route optique personnelle, l’utilisateur pourra voir
les connexions transversales accessibles en cliquant le bouton droit de sa
souris. Le nombre de connexions transversales pourrait dépasser celui des
trajets optiques. Le bouton droit pourrait aussi servir à récolter tous les
RPA connectés au nœud pour lesquels il existe une connexion transversale.

5.1 L’utilisateur pourra aussi se servir de l’interface graphique pour
modifier la connexion transversale d’un nœud. Si la route optique
personnelle aboutit à un nœud intermédiaire, on créera donc deux nouveaux
RPA.

6.0 Une tierce partie pourra saisir un RPA personnel avec GridNexus, Kepler
ou BPEL et l’intégrer à un autre réseau personnel par transitique.





-------------------------------------
To SUBSCRIBE:
send a blank e-mail message to
[email protected]

To UNSUBSCRIBE:
send a blank email message to
[email protected]
-------------------------------------

These news items and comments are mine alone and do not necessarily reflect
those  of the CANARIE board or management.



-----------
[email protected]


_______________________________________________
news mailing list
[email protected]
http://lists.canarie.ca/mailman/listinfo/news