1 / 21

Brian Bach Mortensen, NORDUnet Terena Networking Conference Vilnius 2010

Designing the Multi Domain Service Architecture for Network Connectivity Services in the GÉANT3 project. Brian Bach Mortensen, NORDUnet Terena Networking Conference Vilnius 2010. Outline. GÉANT Service area Terminology and definitions Service catalogue and portfolio Service Architecture

jude
Télécharger la présentation

Brian Bach Mortensen, NORDUnet Terena Networking Conference Vilnius 2010

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. Designing the Multi Domain Service Architecture for Network Connectivity Services in the GÉANT3 project Brian Bach Mortensen, NORDUnet Terena Networking Conference Vilnius 2010

  2. Outline • GÉANT Service area • Terminology and definitions • Service catalogue and portfolio • Service Architecture • Service Level Specification • Operational Level Agreement • Service descriptions and SLS • Static connectivity service • Dynamic connectivity service • Q&A

  3. GÉANT service area • Services provided jointly by independent organizations • Technological differences • Organizational differences • Targets and challenges • Joint service should hide internal differences • Support structure (service desk, monitoring) possible provided by organizations

  4. Service Access Hierachy

  5. Domain terminology

  6. Path agnostic services

  7. Service Demarcation Point (SDP) • Define a point where the service • is delivered: • An ”Equipment identifier” • Unique URN • A ”Port” identifier • A ”Service ID” identifier • <E/P/I> tuple • The syntax of the SDP may vary • from service to service

  8. Service Portfolio and Catalogue • Define a common service catalogue of connectivity services that can be offered to the NREN users • Currently two main connectivity services are in progress (design phase): Static connectivity service Dynamic connectivity service

  9. Sorry for spamming you.. Customers and service dependencies Customer B Customer A Customer C Requirements Requirements Requirements Requirements Requirements Requirements Service desc. IP IP SLS Service desc. wavelength Wavelength SLS Service desc. BoD BoD SLS Joined provider infrastructure I-SHARe (tool) perfSONAR (tool) Network Interfaces (resource) Network Protocols (resource)

  10. Sorry for spamming you.. Infrastructure and supporting services Joined provider infrastructure iShare (tool) perfSonar (tool) Network Interfaces (resource) Network Protocols (resource) OLA Supporting Service Supporting Service OLA OLA Supporting Service Supporting Service OLA Federated Support Team Support Team Federated Provider Internal groups Federated Support Team Support Team Individual NRENs or DANTE

  11. Service Descriptions (1) • Two service descriptions are delivered: • A General Service Description (GSD) • Non technical description of the service • Less than 300 words • Can be used by NRENs to advertise the service towards end users e.g: • “The GN3 Multi-domain Wavelength-based Static Connectivity Service (in the following referred to as “the service”) is an end-to-end, point-to-point connectivity service for data transport. Currently, the data transport capacity dedicated to a connection can range from 1 Gbit/s up to 40 Gbit/s.” • A few more paragraphs to further explain what the service offers • Simplicity is key!

  12. Service Descriptions (2) • A Service Functionality Description (SFD) • Technically oriented description of the service • Targetted at the NOC managers and operational staff at the instituitions that needs the service • Covers management of the service e.g: • Fault management, service delivery management, accounting management, performance management, security management, etc. etc. • Some dataplane specifics e.g. possible interfaces/protocols at service demarcation points between the NREN and user institution

  13. Service Level Specification • Specifies all the measureable service levels that the GN3 service consortium endeavours to deliver : • Examples: • Availability of the service (with specifications of measurement criterias when the service is compliant) • Packet loss, delay, etc. • MTU sizes, maximum burst sizes • Service Delivery times • Service initiation • Service operation change • Service removal

  14. Where are the networks?

  15. SLA/OLA dependencies

  16. LHC OPN based on multi-domain E2E links OLA OLA OLA SLS Figure is modification of work from R. Sabatino

  17. Static connectivity service • A static connectivity service offering SDH, Ethernet interfaces • 1-40Gb/s • Deterministic delay behaviour • (Some) open issues • Lead times • NRENs have very different lead times (technology dependent) • Lowest lead time can not be used • Highest may slow down even simple deliveries • A combination depending on request and possible paths may be the optimum solution • Path diversity? • Both inside individual networks and the whole multidomain path?

  18. Dynamic connectivity service (1) • A dynamic, end-to-end Ethernet connectivity service • Point-to-Point (between two SDPs within the joint domain) • Four tranport modes under consideration • Transport of untagged Ethernet frames • Transport of a specific VLAN (with or without VLAN rewrite) • Transport of all tagged Ethernet frames • Delivering untagged frames to specific VLAN • Bandwidth: 1Mbps-10Gbps (1Mbps steps), MTU: Standard, Jumbo • Path control (i.e, use/avoid domains/nodes) for diverse routing • Relatively short-living circuits with small lead time

  19. Dynamic connectivity service (2) • Participation requirements: Participating domains must implement the required supporting services. • Supporting services (draft list) • Inter-Domain Topology Distribution • Inter-Domain Path Finding • Intra-Domain Transport • Monitoring • Authorization and Authentication • Service Desk • Accounting & Billing • GN tools like AutoBAHN, cNIS, perfSONAR, eduGAIN can be used for this purpose; • but a domain can use its own tools as well

  20. The Teams • Static service design lead by Dr. Andreas Hanemann/Rebecca Corn • Carlos Friacas, Mark Yampolskiy, Andrea Kropacova, Gloria Vuagnin, MaciejŁabędzki, Kurosh Bozorgebrahimi, Tangui Coulouarn, Wolfgang Fritz • Dynamic service design lead by Andreas Polyrakis • Jerry Sobieski, Tomasz Szewczyk, Milosz Przywecki., Leonidas Poulopoulos, Bartosz Belter, Gustavo Neves, Jacek Łukasik, Damian Parniewicz, Kostas Stamos, Joan Garcia Espin, Jordi Jofre

  21. Q&A Thank you Additional questions may be send to brian@nordu.net

More Related