Presentation is loading. Please wait.

Presentation is loading. Please wait.

Connect. Communicate. Collaborate BANDWIDTH-ON-DEMAND SYSTEM CASE-STUDY BASED ON GN2 PROJECT EXPERIENCES Radosław Krzywania (speaker) PSNC Mauro Campanella.

Similar presentations


Presentation on theme: "Connect. Communicate. Collaborate BANDWIDTH-ON-DEMAND SYSTEM CASE-STUDY BASED ON GN2 PROJECT EXPERIENCES Radosław Krzywania (speaker) PSNC Mauro Campanella."— Presentation transcript:

1 Connect. Communicate. Collaborate BANDWIDTH-ON-DEMAND SYSTEM CASE-STUDY BASED ON GN2 PROJECT EXPERIENCES Radosław Krzywania (speaker) PSNC Mauro Campanella GARR Afrodite Sevasti GRNET

2 Connect. Communicate. Collaborate Agenda Introduction Technology Choice Domain Privacy Pathfinding Advance Reservations

3 Connect. Communicate. Collaborate JRA3 AutoBAHN – Geant2 AutoBAHN = Automated Bandwidth Allocation across Heterogeneous Networks A ‘Joint Research Activity’ investigating the provision of ‘Bandwidth on Demand’ services to the NREN community The environment: –Multi-domain –Multiple technologies –Requirements for: end-to-end non-contended capacity a standardized interface for service requests at end-points service level indication to end-users advance reservation (scheduled)

4 Connect. Communicate. Collaborate Architecture overview

5 Connect. Communicate. Collaborate Agenda Introduction Technology Choice Domain Privacy Pathfinding Advance Reservations

6 Connect. Communicate. Collaborate Technology Choice European network is heterogeneous Each NREN develops its own architecture independently, relying on various technology NRENs are interconnected through GEANT2 pan-European network NRENs can connect with each other with cross-border links, evading GEANT2 infrastructure

7 Connect. Communicate. Collaborate Technology Choice AutoBAHN aims at the following technologies: –Layer 1 lambda circuit management –Layer 2 MPLS VPNs Gb Ethernet SDH GFP over SDH Layer 3 technologies are out of scope, as they belong to the responsibility of other GEANT2 activities.

8 Connect. Communicate. Collaborate Agenda Introduction Technology Choice Domain Privacy Pathfinding Advance Reservations

9 Connect. Communicate. Collaborate Domain Privacy –AutoBAHN aims at operating over a federated architecture, where each domain is independent –The AAI and domain privacy is a key issue –Each domain would like to hide its internal details from other domains –The public advertisements are limited to reachablity information only

10 Connect. Communicate. Collaborate Domain Privacy Various representations of abstracted domains –1 to 1 representation –Aggregated nodes –Edge nodes only (currently used by AutoBAHN) –Single node

11 Connect. Communicate. Collaborate Domain Privacy Aggregation of attributes issue – If alternative paths will be abstracted to single one, what attribute values should be used? –It is impossible to have a 10Gbps path with 10ms delay and cost of 15 points…

12 Connect. Communicate. Collaborate Agenda Introduction Technology Choice Domain Privacy Pathfinding Advance Reservations

13 Connect. Communicate. Collaborate Pathfinding Single point computation – Detailed –The advertised domain topologies include information about internal nodes and attributes (limited domain privacy, peering model) –The path contains exact nodes and links in each domain along the reservation path between two end points –The path is computed in one domain (any domain manager, PCE, etc.)

14 Connect. Communicate. Collaborate Pathfinding Single point computation – General –The advertised domain topologies are abstracted, no (or limited) intra-domain details are visible –The path contains only domains that should be traversed by a path (ingress and egress domain points) –Each domain must perform local pathfinding to find a detailed part of inter-domain path (this part may be published or hidden due privacy reasons) –The inter-domain path is computed in single point, the domain details must be computed in each domain

15 Connect. Communicate. Collaborate Pathfinding Distributed computation –Inter-domain topologies provide only routing information –Instead of defining a full path, each domain defines only the „next hop domain” –Each domain defines its part of the path in detail, including outgoing inter- domain links

16 Connect. Communicate. Collaborate Pathfinding AutoBAHN inter-domain pathfinding is performed based on inter- domain abstracted topology (reachability information between domains + abstracted intra-domain links), which is built with OSPF Quagga daemon. Currently Dijkstra algorithm is used to find a potential inter-domain path. The information on abstracted topology database are insufficient to perform a reservation, therefore an additional process (negotiation) is required to validate the path. During the process each domain is queried for details and validation of inter-domain part of the path. The details are called constraints The last domain on a path is responsible to agree all constraints and prepare a final set of reservation attributes, which includes technology specific parameters.

17 Connect. Communicate. Collaborate Agenda Introduction Technology Choice Domain Privacy Pathfinding Advance Reservations

18 Connect. Communicate. Collaborate Advance Reservations AutoBAHN allows to perform advance reservations –Each reservation has start and end time attributes attached –Resources are booked, not configured – a calendar module is used –At reservation time, involved domains configure the network to build a circuit –When reservation time expires, domain removes circuit configuration

19 Connect. Communicate. Collaborate Advance Reservations Inter-domain centralized approach –Calendar must be aware of each particular resource in every domain (limited domain privacy) –One place of data storage (simple maintenance) –Easy to implement

20 Connect. Communicate. Collaborate Advance Reservations Inter-domain distributed approach –Each domain has its own calendar –Domain privacy may be kept –Synchronization of databases is required (for inter-domain resources) –More complex solution than centralized approach

21 Connect. Communicate. Collaborate Advance Reservations Intra-domain centralized approach –There is one calendar instance per domain –The calendar is aware of each resource under control of BoD system –Easy to implement and maintain –Single point of data storage

22 Connect. Communicate. Collaborate Advance Reservations Intra-domain distributed approach –Each resource or resource group has it’s own calendar module –The synchronization is required between calendars for shared resources (e.g. links) –Interaction with external domains is more complex than in centralized approach –Calendars should be part of equipment – vendor support

23 Connect. Communicate. Collaborate Advance Reservations Pathfinding –Pathfinder (PF) module is request to find a chain of domains, which should be involved in circuit creation –Pathfinder takes a snapshot of current abstract topology view (includes other domain information as advertised by Quagga) –Dijkstra algorithm is executed to find best paths (delay value is used as optimization attribute)

24 Connect. Communicate. Collaborate Advance Reservations Negotiations –All domains (included in circuit) are involved in negotiation process –Each domain checks possible intra-domain paths and validates resource availability for reservation time –The constraint entities are created, which describe domain requirements for particular reservation (e.g. allowed VLAN range or SDH time slots)

25 Connect. Communicate. Collaborate Advance Reservations Negotiations –The constraints are collected from all domains along reservation path –The destination domain is responsible to concatenate all constraints in order to find common set of configuration attributes –If such set is found, the resources are booked in all domains’ calendars along the way back to source domain

26 Connect. Communicate. Collaborate Advance Reservations Reservation –Each domain is responsible for initialization of circuit configuration, when reservation time starts (calendar module) –DM configures circuit through Technology Proxy module –Source domain IDM module is notified about circuit creation in all domains –Similar proces is executed to remove circuit configuration

27 Connect. Communicate. Collaborate JRA3 AutoBAHN Partners The JRA3 work is a joint effort of the following NRENs & DANTE –CARNET –CESNET –DANTE –FCCN –GARR –GRNET –HEANET –HUNGARNET –PSNC –REDIRIS –RENATER –SURFNET This presentation was co-authored by –Mauro Campanella (GARR) –Afrodite Sevasti (GRNET)

28 Connect. Communicate. Collaborate Q&A Thank you for your attention


Download ppt "Connect. Communicate. Collaborate BANDWIDTH-ON-DEMAND SYSTEM CASE-STUDY BASED ON GN2 PROJECT EXPERIENCES Radosław Krzywania (speaker) PSNC Mauro Campanella."

Similar presentations


Ads by Google