INFSO-RI Enabling Grids for E-sciencE Institution of SLAs TNLC Meeting ― Athens, Afrodite Sevasti (SA2, GRNET)

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Model Network Service Instance (NSI) refers to every instance of a distinct flow or aggregate of EGEE traffic being transported between two end-points located in two distant EGEE RCs. NSIs are active between two EGEE RCs at a specific point in time, as a result of corresponding equal in number requests made by the EGEE middleware. The GEANT/NREN community can currently offer two types of border-to-border services: –Best-Effort IP service –Premium IP service

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Services It is recommended that all EGEE NSIs are served using Premium IP service. However, there is also the possibility for an NSI to be served using the Best-Effort IP service All domains involved in network services provisioning to EGEE as part of the existing network infrastructure hierarchy have to be categorized as to whether they –Compliant with the Premium IP service –Supportive of the Premium IP service –Indifferent to the Premium IP service

Enabling Grids for E-sciencE INFSO-RI TNLC meeting PIP compliant domain A domain provides Premium IP service to an EGEE NSI by following a set of basic principles as listed here: –IP traffic belonging to a single NSI and served by Premium IP service is classified and its packets are being policed –Each router of the domain serves packets of PIP-served NSIs via a dedicated router queue; –Each router queue dedicated to serving Premium IP traffic must be able to accommodate the maximum of Premium IP traffic that can be routed through it; –For Premium IP traffic of NSIs, it is possible to measure the achievable bandwidth and provide statistical measurements for a set of quality metrics between two edges of the domain. –It must be capable of performing admission control on each new NSI request from an ingress interface to an egress interface of the domain.

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Non PIP compliant domains Definition of a PIP supportive domain –Preserving marking of PIP packets –Operating in an over-provisioned manner. –Monitoring of performance Definition of a PIP indifferent domain –Might alter the DSCP field value in packet headers –Might serve NSI traffic over congested links (and thus compromise NSI requested guarantees such as guaranteed bandwidth) –Lack of monitoring infrastructure A Premium IP indifferent domain can be part of the end-to-end path that the packets of an NSI traverse, however this automatically degrades the IP connectivity network service provided to the NSI from PIP to Best-Effort.

Enabling Grids for E-sciencE INFSO-RI TNLC meeting NSI establishment For every case where it is required that an amount of data is transferred from one EGEE RC to another either in bulk transfer mode or in a real-time transmission mode an NSI request is made. If the NSI request is accepted, the NSI is established For each NSI an end-to-end SLA is established that provides all the technical and administrative details for maintaining, monitoring and troubleshooting the NSI. This SLA is formed using the individual SLAs provided by all domains along the end-to-end path

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Scenarios

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Responsibilities GEANT-NRENs cloud –NIS request processing by each domain along the border-to-border part of the path. –If all three domains are able to confirm that the NSI request can be honored, the acceptance of the request together with a border-to- border SLA will be returned to the ENOC responsible, for each specific NSI Non-GEANT/NREN cloud domains –In case of a PIP compliant or PIP supportive domain:  use its admission control mechanism to examine whether the appropriate resources are available in order to accommodate the request  perform necessary configurations (in the case of a PIP compliant domain) to serve the NSI  fill in the corresponding SLA template (depending on whether the domain is PIP compliant or PIP supportive) for the NSI and return it to the ENOC contact point –In case of a PIP indifferent domain:  ENOC is notified as part of the normal process of collecting per-domain SLAs to produce the end-to-end SLA.  The end-to-end SLA is still established by the ENOC however it provides Best Effort IP service to the particular NSI

Enabling Grids for E-sciencE INFSO-RI TNLC meeting SLA templates SLA template for a Premium IP compliant domain SLA template for a Premium IP supportive domain SLA template for a Premium IP indifferent domain EGEE end-to-end SLA template

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Establishment of SLAs

Enabling Grids for E-sciencE INFSO-RI TNLC meeting End-to-end SLA establishment & the EGEE middleware

Enabling Grids for E-sciencE INFSO-RI TNLC meeting Other issues Monitoring of SLAs –Each domain is responsible for monitoring its network services’ provisioning according to the SLA it offers and whether it is a PIP compliant, PIP supportive or PIP indifferent domain –It is left to the EGEE RCs to install and/or run application oriented tests to verify the performance of the end-to-end path Fault reporting and troubleshooting of SLAs –In case of faults or degradation of performance, usually perceived by by those involving in an NSI VOs/RCs, the problem must be directly reported to the ENOC –The ENOC is responsible for deciding where the problem might be located and notifying the Technical Contact(s) of one or more of the domains along the path. Quotas Disqualifying a domain