1 / 13

JRA3 - Bandwidth on Demand

JRA3 - Bandwidth on Demand. Mauro Campanella (from a slide set of Afrodite Sevasti). JRA3 architecture. Two major modules: Inter-Domain manager (IDM) and the Domain manager (DM) with Standardized interfaces

saddam
Download Presentation

JRA3 - Bandwidth on Demand

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JRA3 - Bandwidth on Demand Mauro Campanella (from a slide set of Afrodite Sevasti)

  2. JRA3 architecture • Two major modules: Inter-Domain manager (IDM) and the Domain manager (DM) with Standardized interfaces • Each domain participating in BoD service provisioning needs to operate an IDM and honor the IDM-DM and IDM-IDM interfaces • the DM can be any existing one (just proxies need to be developed)

  3. Why an Inter-Domain Manager • The effort to provision end-to-end Bandwidth on Demand services in the European scenario requires specific inter-domain collaboration • Splitting intra-domain management functionalities from inter-domain ones in separate modules, allows multi-domain R&D to proceed autonomously and focus on this less standardized area • At the same time it is compatible existing intra-domain managers through wrappers and interfaces, exploiting a modular approach • This effort can provide solid experience for brokering services other than Bandwidth on Demand

  4. IDM multi-domain issues • The IDM is facing faces the following challenges due to its multi-domain scope: • policies and technological choices • a service and network abstraction schema and specification • advance reservation • multi-domain path finding procedure • monitoring • Authentication and Authorization

  5. IDM Prototype implementation • DJ3.3.2 ‘Functional specification of the IDM prototype’ is available on the GEANT2 web • Objectives • to validate design and architectural assumptions • to define potential risk points and bottlenecks • to test IDM reservation procedures and communication schemas • Modular implementation • Web-services’ technology

  6. IDM Prototype testing • A number of test cases • Single request • Multiple requests • Request with multiple reservations • Multiple simultaneous requests • Multiple simultaneous request to the same destination domain • Multi-domain setup • IDM prototype installations in PSNC, GEANT, GRNET, DANTE • Simulated topologies

  7. Intra-domain provisioning • Manual intra-domain configurations and provisioning 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

  8. Technology StitchingNetwork Technology Types • Based on existing NREN technologies • SONET/SDH • Ethernet based: • Native Ethernet • L2 MPLS VPN • DiffServ technologies • PIP • IP MPLS QoS • 14 different interconnection scenarios in total identified

  9. JRA3 BoD Monitoring • JRA3 aims to use existing NRENs' network infrastructure to provide a BoD service, under a single interface • GN2 JRA1 activity aims to use provide ubiquitous access to monitoring information for groups of uses • JRA3 should build the technology-specific measurement tools for end-to-end L1-L2 services and feed them to the JRA1 framework for storage, processing, concatenation and visualization purposes • DJ3.3.3: Report on BoD service monitoring • Requirements for monitoring BoD service instances (lightpaths) • Functional specifications for the components necessary to allow partial and full path monitoring

  10. Monitoring priorities • Technologies: BoD Ethernet circuits over • One EoMPLS/switched Ethernet network • One SDH-based network • Metrics to be monitored, in order of priority • Up/down • Degraded/not degraded • Level of usage (where possible)

  11. Towards a common NIS • Network Information System to serve all Services • JRA3 focuses on SDH and Ethernet topology modeling

  12. Liaison activities, other than I2, Canarie, ESNET • We are (mainly) looking at: • DRAGON (http://cnl.gmu.edu/dragon/) • 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 • OIF work and latest drafts

  13. JRA3 team • The JRA3 work is a joint effort of the following NRENs & DANTE • CARNET • CESNET • DANTE • FCCN • GARR • GRNET • HEANET • HUNGARNET • PSNC • REDIRIS • RENATER • SURFNET

More Related