Towards a pan-European Bandwidth on Demand Service Michael Enrico Network Engineering & Planning DANTE TNC 2005 Poznań, 6-9 June 2005

Outline of talk Motivation for a BoD service in GÉANT2 BoD in GÉANT2 (outline of JRA3) Status and Conclusions

Motivation for a BoD Service

Point-to-Point Services Various projects have been using pt-to-pt L2 connections (mostly GE ) –Some single domain (just across GÉANT) –Many across multiple domains (GÉANT & NRENs & regionals) Approach has been to use L2 VPNs (using MPLS) for GÉANT part –Initially using vendor-proprietary techniques (CCC & LSP “stitching”) –More recently IETF (experimented with Martini & Kompella drafts) Hard work in multi-domain environment –All hand-crafted (control plane based on SMTP & SS7…) –Can take a few weeks to commission & troubleshoot More frequent requests over last few years An example…

UPC-Bexco (Korea) HDTV Demo

BoD in GÉANT2

GÉANT2 R&D Activities SA3 (PACE) – End-to-End QoS (Premium IP & PERT) JRA1 – Performance Monitoring (IP Services) JRA2 – (Network) Security JRA3 – BW Allocation & Reservation JRA4 – Testbed JRA5 – Ubiquity (Mobility) (and AAI)

JRA3: BW Allocation & Reservation Aim: to research and develop “connection-oriented” L1/L2 BoD services suitable for the European R&E community –start with MPLS layer-2 VPN approaches in many domains –progress towards “proper Lightpaths” as NRENs develop their infrastructures –address multi-domain, heterogeneity, auto provisioning, advance reservation… About 260 man months of effort (over 4 years) Participants: DANTE, CARNet, CESNET, GARR, GRNET, HEAnet, HUNGARNET, PSNC, RedIRIS, RENATER, SURFnet Should provide input to SA3 (PACE) (E2E QoS) during later stages

JRA3 Work Items (I) Work Item 1 – Activity Management Work Item 2 – Reqs Gathering & State-of-the-Art –Identify BoD users, their service reqs, reqs placed on the networks –Comprehensive survey of existing technologies –Estimated: 31 MM (total) –Leader: GRNET (Greece) Work Item 3 – Service Specification –Study key issues (architectures, policy, components, interfaces, control plane, monitoring, etc) –Derive service specs in phased manner –Estimated: 53 MM (total) –Leader: GARR (Italy)

JRA3 Work Items (II) Work Item 4 – Implementation –Adapt or create software components required for control plane (again in phases) –Estimated: 116 MM (total) –Leader: PSNC (Poland) Work Item 5 – Testing & Service Validation –Performed mainly on GÉANT2 (JRA4) testbed –Possibly pilot service(s) in production environments –Estimated: 40 MM (total) –Leader: HEAnet (Ireland)

Status of Work Work item 2 –Deliverable D J3.2.1 “BoD User and Application Survey” finalised and review process started –Deliverable D J3.2.2 “Initial Review of BoD-Related Technologies” near to completion Work item 3 –Framework and architecture discussions are ongoing –Face-to-face meeting held 13th April in Zürich –Work started on first deliverable (high-level spec for a manually provisioned BoD service)

WI-02: BoD User and Application Requirements Survey A questionnaire was sent to 12 projects to solicit requirements for a potential BoD service –6 projects responded The questionnaire was organised as follows –General Issues, description of the application –Control Issues, requirements on BoD system and its interfaces –Network Issues, capacity requirements, service duration, etc. –ReIiability Issues, latency, security, restoration, etc. –Other Issues, accounting, participation in a BoD pilot, etc.

Survey Results The need for BoD-like services exists today for a number of different communities/projects/users groups BoD users/applications should be provided with standardized interfaces for resource reservations and service monitoring –Web services approach looks popular –Ability to schedule reservations seems important Bandwidth requirements range from 10 Mbps to 10 Gbps A number of the projects/user groups contacted have expressed their interest to test the BoD system during its deployment phases

WI-02: State-of-the-Art Review Available “transport” technologies –SONET/SDH, VCAT/LCAS, GFP, L2VPN, VLAN Capacity management middleware –BMP, CATI, DRAC, DRAGON, ODIN, Operax, SBM, Tequila, UCLP Signalling/management protocols and frameworks –RSVP –UNI –TL1, SNMP (management really) AAA services, architectures and infrastructures Control plane survey –G.ASON –GMPLS –UCLP –Other

WI-03: Service Specification End-to-end services (layer 2) –Ethernet (main focus of JRA3) –PPP, HDLC, Frame relay, ATM (for illustration only) –i.e. transparent transport of layer 2 frames between two service endpoints To be considered? SDH/SONET path service Heterogeneous network technologies –SDH/SONET network, GFP / WANPHY / PoS encapsulation –IP/MPLS network, CCC / L2VPN / PWE3 –Native Ethernet network

WI-03: Functional blocks Inter-domain service manager (IDM) –Session management –AAA (possibly also AAA in domain manager) –Inter-domain routing Domain-centric service manager (DM) –Intra-domain routing –Resource management –Topology discovery –Reservation scheduler –Monitoring Technology proxy –Technology or vendor specific layer –Translate generic service requests into vendor specific configurations

WI-03: Functional blocks Possible to reuse existing single domain resource managers –Network Management System (NMS) –UCLP, etc. Some functions may sometimes be implemented in the network elements already –GMPLS, G.ASON –routing, topology discovery, resource management

WI-03: Routing Inter-domain routing (option 1) –First domain determines the sequence of domains to be traversed –Each domain may implement a different inter-domain routing algorithm –Allows for inter-domain traffic engineering Inter-domain routing (option 2) –Each domain determines the next domain –Each domain must implement a common inter-domain algorithm to avoid loops etc. –More scalable than option 1? Intra-domain routing –goal: find a path within the domain between an ingress and egress point that satisfies a given bandwidth constraint (future: take delay into account) –each domain may use its own routing and traffic engineering algorithms

WI-03: Signalling Signalling to setup or teardown BoD services Option 1 –First domain contacts each domain separately –AA relations between all domains required –If routing option 2 is used then each domain must signal back the next domain Option 2 –Domains only exchange signalling with the adjacent domains –If routing option 1 used then the signalling message must contain a list of domains –Only AA between adjacent domains Route distribution –Static route tables (during initial phase) –Protocol to distribute interdomain routing information (e.g. similar to BGP) => final goal

WI-03: Proposed Framework (signalling option 1) Domain 1 Domain 2 Domain 3 Interdomain manager Domain manager Technology proxy Interdomain manager Domain manager Technology proxy Interdomain manager Domain manager Technology proxy In case of routing option 2 then domain 2 must signal back the next domain (i.e. domain 3)

WI-03: Proposed Framework (signalling option 2) Domain 1 Domain 2 Domain 3 Interdomain manager Domain manager Technology proxy Interdomain manager Domain manager Technology proxy Interdomain manager Domain manager Technology proxy In case of routing option 1 then the signalling message must contain a route list (i.e. list of domains)

Time to Liaise

First with GN2-SA3 & EGEE EGEE aims to integrate current national, regional and thematic Grids, to create a seamless infrastructure for worldwide, scientific research. Specific Network Services Development (EGEE-JRA4) activity –Focuses on: Network Performance Measurement Bandwidth Allocation and Reservation (BAR) –UCL (now UEDIN), DANTE, CNRS, GARR, DFN, CCLRC –See also “Networking activities in the EGEE project” talk on Tuesday at 16:00

EGEE BAR High-level aim is to cultivate a close working relationship between the Network providers and the (EGEE) Users. Developing a pilot IP Premium service between a limited set of sites –GÉANT(2), GARR, GRNET, possibly UKERNA –Due Dec 2005; prototypes June and September Clear distinction of duties and explicit collaboration with GN2 –Software interfaces defined in partnership

BAR Architecture

Conclusions Initial survey work completed –Latent demand for BoD service but still “niche” –GRID and “big science” users most likely users –Need to revisit surveys later (planned for next year) BoD service specification discussions now started –Draft framework drawn up –Now need to compare notes with those developing frameworks for other GÉANT2 services (notably PIP) + beyond –Functional blocks and interfaces now being defined (high level) Aim at this stage is to define information flows and block functions –in order to derive a streamlined manual BW provisioning process (in one then multiple domains) – by Q Automation to come later (and bit-by-bit) –Build domain managers, technology proxies, integrate with external systems (e.g. AAI), gradually replace manual components, etc –Then test (using testbed) Finally: maybe pilot service towards end of GÉANT2 –a production service for GÉANT3…???

Thank you for listening Questions?