COMMON: Coordinated Multi layer Multi domain Optical Network - PowerPoint PPT Presentation

COMMON: Coordinated Multi ‐ layer Multi ‐ domain Optical Network Framework for Large ‐ scale Science Applications (2010 ‐ 2013) PI: Dr. Vinod Vokkarane Associate Professor, University of Massachusetts at Dartmouth (Currently on Sabbatical: Visiting Scientist, MIT) Contact: vvokkarane@ieee.org Project Website: http://www.cis.umassd.edu/~vvokkarane/common/ Supported by DOE ASCR Brookhaven National Laboratory (BNL) January 12 ‐ 13, 2012 under grant DE ‐ SC0004909

Outline Outline • Introduction and project objectives Introduction and project objectives • Year 1 Objectives: – Anycast Multi ‐ domain Service Anycast Multi domain Service – Multicast ‐ Overlay Algorithms • Year 2 and 3 Project Objectives Year 2 and 3 Project Objectives – Multi/Manycast ‐ Overlay Deployment – Survivable Connections Survivable Connections – QoS support • Multi ‐ domain Anycast Demo Multi domain Anycast Demo 2

COMMON Project Team COMMON Project Team UMass Team ESnet/LBNL Team • Dr. Vinod Vokkarane (PI) • Chin Guok • Dr. Arush Gadkar (Post ‐ Doc) • Andrew Lake • Dr. Joan Triay (Visiting D J T i (Vi iti • Eric Pouyoul E i P l Fulbright Scholar) • Brian Tierney • Bharath Ramaprasad (MS) • Mark Boddie (BS ‐ MS) • Tim Entel (BS ‐ MS) • Jerem Plante (Ph D ) • Jeremy Plante (Ph.D.) • Thilo Schoendienst (Ph.D.) 3

Introduction • To support large ‐ scale science applications we need to provision network resources across multiple layers and multiple domains. • The network needs to provision connections between clients efficiently. – Immediate reservation (IR): network provisioning “immediately” when the connection request arrives. – Advance reservation (AR): resources can be reserved at some point in the future. 4

Communication Services: Anycast Unicast Vs Anycast • • Unicast request is represented by a d1 tuple ( s,d ), where s is the source tuple ( s,d ), where s is the source node and d is the destination node. d2 Unicast s d3 Anycast request is represented by a Anycast request is represented by a • • d4 d4 “ s ” connects tuple ( s,{D} ) where s is the source d5 to just one node and the { D } is the set of destination candidate destination nodes. d1 • In Anycast, the source node d2 communicates with any one node communicates with any one node Anycast s d3 from the set of candidate destination d4 nodes. “ s ” selects one d5 destination ( k =1) destination ( k 1) from the group 5

Communication Services: Multicast/Manycast Multicast Vs Manycast • • Multicast request is represented by a tuple d1 (s,{D}), where s is the source node and D is the set of destination nodes ( d 1 , d 2 , …,d m }. h f d i i d ( d d d } d2 “ s ” connects to all nodes in the s d3 group ( k = m ) In Multicast, source node communicates with • d4 Multicast Multicast each destination node in { D }. d5 • Manycast request is represented by a tuple y q p y p ( s,{D},k ) ,where s is the source node and the “ s ” connects to a subset of m { D } is the set of candidate destination nodes. ( k <= m ) d1 The source node communicates with any k nodes from the set { D }. Manycast d2 s d3 d4 d4 d5 6

COMMON Project Objectives • Design and Implement new services for advance reservation of network resources across multiple domains and multiple layers. • COMMON Focus Areas: – Deploy Anycast AR algorithms on OSCARS (Year 1). – Develop Multi/Manycast Overlay models and deploy them on OSCARS (Y1 ‐ Y2). – Design and Deploy survivability techniques for multi ‐ domain networks (Y2 ‐ Y3). Design QoS mechanisms to support scientific applications on multi ‐ – domain networks and deploy them on OSCARS (Y2 ‐ Y3). – Extend QoS and Survivability mechanisms to multi ‐ layer scenarios and deploy them on OSCARS (Y3). 7

Outline Outline • Introduction and project objectives Introduction and project objectives • Year 1 Deliverable: Anycast Multi ‐ domain Service Service • Year 2 and 3 Project Objectives • Anycast Demo 8

Year 1: Deployment of Anycast Service on OSCARS Obj Objectives ti Impact I t  Design and implement a production ‐ ready  Provide scientific community with ability to: anycast service extension to existing OSCARS (a) Allow for destination ‐ agnostic service framework. hosting on large ‐ scale networks.  Improve connection acceptance probability and (b) Increase service acceptance. user experience for anycast ‐ aware services. Design & Implementation (Complete)  Designed anycast service as a PCE extension.  Implementation of the PCE modules to find anycast connectivity, remove the unavailable resources, and select the best possible destination. l t th b t ibl d ti ti  Successfully completed Stress, Regression, and Integration testing of the anycast modules on OSCARS 0.6 (Q4, 2011). 0.6 (Q4, 2011).  Hot deployment ready (PnP capable) anycast version of OSCARS 0.6 available at: https://oscars.es.net/repos/oscars/branches/common ‐ anycast/  Plan to work with ESnet and ESG group to attach this service to a specific application. 9

End to end Anycast Flowchart End ‐ to ‐ end Anycast Flowchart Notification Broker Topology Bridge Lookup • Manage Subscriptions M S b i ti • Topology Information T l I f ti • Lookup service • Forward Notifications Management 3 2 2 PCE PCE AuthN • Constrained Path • Authentication Coordinator Computations • Workflow Coordinator 1 1 4 Resource Manager Web Browser User • Manage Reservations Interface • Auditing AuthZ* Path Setup IDC API • Authorization • Authorization • Network Element • Manages External WS • Costing Interface Communications *Distinct Data and Control Plane Functions 10

End ‐ to ‐ end Anycast Flowchart End to end Anycast Flowchart 1 • The user interface servlets would process the anycast request as a unicast request with a big exception: the destination field will be a list of destination nodes (the anycast destination set) the destination field will be a list of destination nodes (the anycast destination set). – An option is to encapsulate the anycast data as an OptionalConstraintType, in addition to the rest of parameters mapped into a UserRequestConstraintType. Both, UserRequestConstraintType and the OptionalConstraintType will be part of the ResCreateContent. – The ResCreateContent will be passed to the Coordinator to further process the anycast request. 2 2 • The Coordinator, through the CreateReservationRequest, will get the ResCreateContent and map the user request constraints and optional constraints into a PCEData object. – The PCERuntime will handle the query process to the PCE. 3 • The PCE (using the design proposed in the following slides) will make use of the OptionalConstraintType (which carries the list of destinations) (which carries the list of destinations). 4 • The result of the PCE will be the path from the source node to a single destination node, so, from the path reservation and PSS modules standpoint, the rest of the flowchart will work as a unicast request. User Interface User Interface Coordinator Coordinator PCE PCE ResCreateContent PCEData PCEDataContent OptionalConst OptionalConst UserRequestC UserRequestC OptionalConst OptionalConst UserRequestC UserRequestC OptionalConst OptionalConst UserRequestC UserRequestC raintType onstraintType raintType onstraintType raintType onstraintType Anycast destination set 11

Anycast PCE – Design Anycast PCE Design • In this design, we need to: PCERun – implement a new time connectivityPCE and dijkstraPCE which are anycast ‐ aware. 1) 1) The AnycastConnectivityPCE Anycast computes the connectivity topology Connec from the source to all destinations tivityPC in the anycast set in the anycast set. E 5) 2) The constraint set is sent to the AnycastBandwidthPCE to check the 2) bandwidth availability on the Anycast anycast topology. y p gy bandwi dthPCE 3) The AnycastVlanPCE receives the pruned topology to the selected 3) destination and checks for the vlanPCE. Anycast Anycast 4) The AnycastDijkstraPCE gets the VlanPCE constraints and pruned input topology from the bandwidthPCE 4) and checks the shortest path for Anycast Anycast each destination in the anycast set each destination in the anycast set. Dijikstra It also selects the final destination. PCE 5) It then returns the final reply to the PCERuntime Tag 1 12

Multi ‐ domain Anycast Multi domain Anycast 13

Performance of Anycast Service for OSCARS Results for single domain Results for single domain • We simulated 30 unique sets of 100 AR requests (and present the average values). • All links are bi ‐ directional and are assumed to have 1 Gb/s bandwidth. have 1 Gb/s bandwidth. • For each request, the source node and destination node(s) are uniformly distributed. • Request bandwidth demands are uniformly distributed in the range [100 Mb/s, 500 Mb/s], in 16 ‐ node ESnet SDN core network topology used in 16 d ES t SDN t k t l d i increments of 100 Mb/s. obtaining results. • All requests are scheduled to reserve, transmit, and release network resources within two hours such that we stress test the network by increased traffic loads in this time frame. t ffi l d i thi ti f • The correlation factor corresponds to the probability that requests overlap during that two ‐ hour window. Average hop ‐ count of successfully provisioned Percentage blocking reduction of 14 requests: unicast vs. anycast m /1 . anycast m /1 over unicast.