Towards a pan-EuropeanBandwidth on Demand Service

Michael EnricoNetwork Engineering & Planning

DANTE

TNC 2005Poznań, 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 ApplicationRequirements 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 MeasurementBandwidth 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

HLM

BAR

NSAP NSAP

Core Network

BAR

Site 1 Site 2

NSAP

Network

EGEE

Network 3Network 2Network1

L-NSAP L-NSAP

L-NetworkL-Network

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 Q3 2005• 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?