JRA3 - Bandwidth on Demand

1
JRA3 - Bandwidth on Demand
GGF16 Athens, 14th February 2006 Afrodite
Sevasti GRNET
2
GN2 project

• Multi-Gigabit European Academic Network
• Project funded under FP6 (Research
  Infrastructures-Integrated Infrastructure
  Initiative)
• 31 partners (NRENs, DANTE, TERENA)
• Total expected budget 178.643.730
• EC contribution requested 93.000.000
• Duration 4 years
• Combining in a single contract, several
  activities essential to reinforce research
  infrastructures and to provide an integrated
  service at the European level
• Networking activities (including consortium
  management)
• Provision of access to transnational users
• Joint Research Activities
• Scope
• Further develops the successful GN1 project which
  has created the GEANT pan-European network
• Specific emphasis on end-to-end provision of
  services across multiple interconnected networks
• Gaining improved understanding of user needs
• Direct support and performance monitoring
• Migration from IP services to combination of
  routing and switching, network control,
  light-paths

3
Goals of JRA3 in GN2 project

• Joint Research Activity
• aim for a proof-of-concept and pilot network
  service for dedicated capacity provisioning
• production service during a subsequent project
• Streamline the inter-domain setup of lightpaths
• shorten the provisioning time
• reduce the amount of human intervention
• Take into account heterogeneity from the
  beginning
• Specify and document the manual procedures
• Automate the process step-by-step focus on
  inter-domain coordination process
• Provide northbound interfaces/APIs to
  applications-middleware

4
Service Definition

• Point-to-point, connection oriented service
• Non-contended capacity
• Layer 1, 2
• focus on provisioning of a deterministic
  non-contended bandwidth pipe between two 1Gigabit
  Ethernet access ports over multiple domains that
  employ different technologies
• Multi-domain and multi-technology
• e.g. SDH with GFP, EoMPLS, native Ethernet
• Automated provisioning
• Advance reservation (scheduled)

5
Requirements survey

• Deliverable DJ3.2.1 GÉANT2 Bandwidth on Demand
  (BoD) User and Application Survey
• disappointing response rate (6 out of 12)
• GRID community most responsive
• The questionnaire was organized 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.
• RESULTS
• The need for BoD-like services exists today for a
  (small) number of different communities/projects/u
  sers 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
  expressed interest in testing a prototype BoD
  system

6
State-of-Art survey

• Deliverable DJ3.2.2 Initial Review of
  Technologies Related to the Provision of
  Bandwidth-on-Demand (BoD) Services
• Mainly covers
• Transmission switching technologies
• Control Plane technologies
• BW broker implementations
• BMP, CATI, DRAC, DRAGON, ODIN, Operax, SBM,
  Tequila, UCLP
• An update is expected during Y2 including
• recent developements in the OIF, IETF
• results of the collaboration with other projects
  related to JRA3 activities (MUPBED, DRAGON,
  VIOLA, HOPI ...)

7
Multi-domain provisioning
8
Service characteristics

• Inter-domain the end user points may be located
  in different domains
• Capacity The minimum amount of capacity that can
  be requested will depend on local domain policies
  and restrictions imposed by the technology used
  (e.g. SDH granularity)
• Point to point the BoD service provides
  Point-to-Point services. Point-to-Multipoint may
  be realized as a set of point-to-point services
• Bi-directional the service is a bi-directional
  service
• Symmetric capacity
• Symmetric paths
• Advance reservations
• Protection

9
Inter Domain Manager

• A set of automated procedures for the required
  non-technology specific inter-domain negotiations
  in order to establish an end-to-end non-contended
  1 GE bandwidth pipe
• Reservation process
• Ensure adequate e2e capacity
• Ensure technical feasibility (e.g. a common VLAN
  id along the e2e path)
• Capacity reservation scheduling
• Path resilience-restoration

10
Intra-domain provisioning

• Manual intra-domain configurations and
  provisioning processes for the establishment of
  the intra-domain segments of the end-to-end path
• Intra-domain provisioning design to accommodate
• Domains that have a G.ASON/GMPLS CP out of the
  box e.g. Generic MPLS Routing Engine
  (distributed control plane in their Alcatel 1678
  MCC OXC)
• Domains operated via NMS
• Domains that may decide to adopt proprietary
  Bandwidth Brokers
• Intra-domain modules, implemented in later
  phases, will comprise the so-called BoD service
  Domain Manager (DM)

11
Integration of technologies

• Evaluating the implementation implications and
  testing a number or scenarios

12
Monitoring

• Inter-domain monitoring system must
• Troubleshoot in case of failure
• Provide concatenated monitoring data of the
  quality of the end-to-end service
• Working together with relevant GN2 project
  activities (JRA1 and JRA4)
• JRA3 will provide technology-specific monitoring
  data at L1-2 as well as topology data
• JRA1 will provide monitoring data management and
  visualization
• Activities
• Design and prototype implementation of the
  database schema and interface for retrieving and
  storing monitoring data from the Alcatel NMS
  (GEANT2 core)
• Specification and design of the database schema
  and application for retrieving and storing
  monitoring data in EoMPLS and native Ethernet
  topologies
• Integration of the monitoring data extraction and
  storage components with the JRA3 Network Topology
  Database
• Minimum requirements for monitoring
• Initially focus on availability lt up/down
  info, unavailable-seconds
• Also offered capacity, errors lt BER, error
  counter, errored-seconds

13
Implementation

• Following the Web-services paradigm
• Each component of the system is implemented as a
  Web service
• Interfaces are defined between IDMs, the IDM and
  the DM of a domain, the DM and the technology
  proxy within a domain
• Using Java, MySQL
• A prototype of the IDM is expected by May 2006

14
Liaison activities

• We are looking at
• DRAGON (http//cnl.gmu.edu/dragon/)
• Network Aware Resource Broker (NARB)
• Virtual Label Switching Router (VLSR)
  Implementation
• OSCARS-BRUW projects
• MUPBED (http//www.ist-mupbed.org), NOBEL
  (http//www.ist-nobel.org/)
• VIOLA (http//www.viola-testbed.de/)
• Testbed
• ARGON (Allocation and Reservations in
  Grid-enabled Optical Networks)
• HOPI- GLIF
• Working on a Common Service Definition for e2e
  circuit oriented services with DRAGON/GLIF
• Joint workshops and meetings