12.07.2015 Views

Grid Job Routing Algorithms - Phosphorus

Grid Job Routing Algorithms - Phosphorus

Grid Job Routing Algorithms - Phosphorus

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Grid</strong> <strong>Job</strong> <strong>Routing</strong> <strong>Algorithms</strong>This model is intended to be mainly deployed when most of the computational and service intelligence need tobe maintained in the <strong>Grid</strong> layer for specific middleware design and functional behaviours. The leading role inthis case is played by the <strong>Grid</strong> scheduler, which is the overall responsible for initiation and coordination of thereservation process through the participating <strong>Grid</strong> sites and the network in between. The <strong>Grid</strong> topology overlaysthe network topology, but the <strong>Grid</strong> scheduler needs to know both in order to send detailed connection requeststowards the G 2 MPLS, e.g. by specifying the ingress and egress network attachment points or possibly theexplicit route to follow.5.1.2 Peer (integrated) modelIn the GMPLS peer model, routing advertisements are distributed to the whole network and all the nodes runthe same instance of GMPLS Control Plane, even if they have different switching capabilities. This is the nativeGMPLS deployment model, which in some cases may encounter scalability issues.In such a framework, the basic construct is the Forwarding Adjacency Label Switched Path (FA-LSP). It is anLSP created either statically or dynamically by one instance of the Control Plane and advertised as a TE linkinto the same instance of the Control Plane (for the use by upper layers or neighbouring regions). Thetopological view in a peer model is obtained by a mix of TE-links with different switching capabilities descriptorsand dynamical virtual TE-links bound to FA-LSPs.In the PHOSPHORUS peer model, <strong>Grid</strong> sites are modelled as special network nodes with specific additional<strong>Grid</strong> resource information. The resulting topology is flat and integrated with respect to the positioning of the<strong>Grid</strong> layer against the network layer. The <strong>Grid</strong> scheduler functionality is still needed to support the many userapplications that rely on specific <strong>Grid</strong> infrastructure but most of the functions are implemented by the Controlplane i.e. the full path between the selected <strong>Grid</strong> job providers is determined by the G 2 MPLS.5.2 Network scenarios to evaluate <strong>Grid</strong> job routingalgorithmsThe PHOSPHORUS global testbed will consist of multiple local testbeds located in several places in Europe,United States and Canada. For the integration of the whole PHOSPHORUS testbed all local testbeds must beinterconnected on the data plane as well as on the control/provisioning plane. The data plane connections willbe used to transit user data between <strong>Grid</strong> resources located in different local testbeds while thecontrol/provisioning plane connections will be used for integration of the control planes (GMPLS, G 2 MPLS) oflocal testbeds as well as integration of NRPSes to allow for signalling between them and multi-domainprocessing of users’ requests.The data plane connectivity will be based on dedicated lightpaths capable of transmitting huge amounts of data(the amounts which will be generated by PHOSPHORUS applications) and will be comprised of switchingresources in local testbeds and a set of transmission links between local testbeds. In order the PHOSPHORUSProject:PHOSPHORUSDeliverable Number: D.5.3Date of Issue: 31/06/07EC Contract No.: 034115Document Code: <strong>Phosphorus</strong>-WP5-D5.346

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!