GN2JRA3 Bandwidth on Demand - PowerPoint PPT Presentation

1 / 20
About This Presentation
Title:

GN2JRA3 Bandwidth on Demand

Description:

Maarten B chli Internet2, Ann Arbor, 21-22 June 2005. JRA3 work items ... Maarten B chli Internet2, Ann Arbor, 21-22 June 2005. WI-02: State-of-the-Art Review ... – PowerPoint PPT presentation

Number of Views:48
Avg rating:3.0/5.0
Slides: 21
Provided by: peopleIn
Category:

less

Transcript and Presenter's Notes

Title: GN2JRA3 Bandwidth on Demand


1
GN2-JRA3Bandwidth on Demand
  • Internet2 offices, Ann Arbor
  • 21-22 June 2005
  • Maarten Büchli
  • Network Engineer, Network Engineering and
    Planning

2
JRA3 work items
3
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)

4
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)

5
Current status
6
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

7
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.

8
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
  • Interest to test the BoD system during its
    deployment phases

9
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 protocols and frameworks
  • RSVP
  • UNI
  • TL1, SNMP (management really)
  • AAA services, architectures and infrastructures
  • Control plane survey
  • G.ASON, GMPLS, UCLP, Others

10
WI-03 Service Specification
  • Discussion on general framework
  • scope of the BoD
  • glossary and terminology
  • services, modules and blocks
  • functional specification (draft)
  • Take into account
  • Heterogeneous technologies
  • Domains with GMPLS control planes
  • Possibility of integrating existing domain
    managers into the framework
  • Services (BoD is but one) contending for
    underlying resources (capacity)

11
WI-03 Early results
  • BoD is a layer 2 service
  • Service needs to be requested to the first domain
  • High level functional blocks
  • Interdomain manager
  • Domain manager
  • Technology proxies
  • Pathfinder
  • Interdomain pathfinder (sequence of domains)
  • Intradomain pathfinder (path through domain)
    based on bandwidth constraints and possibly other
    constraints

12
Architecture
13
Bandwidth on Demand
  • A circuit-(or connection) oriented bandwidth
    allocation and reservation service with the
    ability to operate over multiple, heterogeneous
    technology and administrative domains
  • Start with MPLS layer-2 VPN approaches in many
    domains
  • Progress towards proper lightpaths (GE, SDH.
    lambda) as NRENs develop their infrastructures
  • Address multi-domain, heterogeneity, auto
    provisioning, advance reservation

14
The multi-domain BoD
15
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

16
Summary and future direction
17
Summary (1)
  • 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
    and measurement) 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

18
Summary (2)
  • 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???

19
Future direction (1)
  • Taking a top-down approach
  • First focus on interdomain process
  • Then focus on domain provisioning and interfacing
    with existing resource management systems
  • Interdomain signalling
  • Define messages and parameters
  • Develop the necessary XML schemas
  • Pilot a manually provisioned service
  • Automate the interdomain communication

20
Future direction (2)
  • Reuse existing single domain resource managers
  • Network Management System (NMS)
  • UCLP, DRAC etc.
  • Some functions may sometimes be implemented in
    the network elements already
  • GMPLS, G.ASON
  • routing, topology discovery, resource management
Write a Comment
User Comments (0)
About PowerShow.com