Changes between Version 5 and Version 6 of GEC24Agenda/EveningDemoSession

02/24/16 12:48:34 (8 years ago)



  • GEC24Agenda/EveningDemoSession

    v5 v6  
    119 ==== VTS in GENI ====
     119==== Teaching using GENI and iPython notebooks ====
    121121''  Exhaustive demonstration of the full features provided by VTS across the GENI testbed. ''
    123  Attendees interested in rich networking experiments on the GENI testbed should attend.   This demonstration will outline all the features available in GENI through VTS for creating isolated network topologies. This includes (but is not limited to) OpenFlow 1.3 forwarding elements, arbitrary in-path network functions, dynamic control of port failures, statistics reporting, and WAN connectivity.
     123We will show a self-contained VM environment for interacting with GENI using geni-lib completely within a browser interface, with a local Jupyter (iPython) notebook host, and browser-based terminal.
     125Notebooks can be saved as teaching references, and replayed by any user in their own environment to reproduce a complete session (reserving resources, inspecting them, etc.). Example notebooks will be shown for basic networking labs using VTS, with topology visualization.
    153155''This demo shows !CloudLab, a facility for research on the future of cloud computing. ''
    155 Attendees interested in research on clouds should attend.  !CloudLab provides researchers with control and visibility all the way down to the bare metal. Provisioning an entire cloud inside of !CloudLab takes only minutes. Most !CloudLab resources provide hard isolation from other users, so it can support hundreds of simultaneous "slices", with each getting an artifact-free environment suitable for scientific experimentation with new cloud architectures. Run standard cloud software stacks such as !OpenStack and Hadoop. Or, build your own from the ground up. The bare metal's the limit!
     157This demo will showcase several new features of CloudLab, including:
     159* Status reports (health and available resources) for clusters
     160* Realtime status notifications for startup commands, image creation, and other events
     161* Persistent storage
     162* New organization for profiles
    163171<div class="alignleft" style="width:100%;height:2;border-top:2px solid #FF7500;"></div>
     174==== Dynamic Sharing of GENI AM Resources ====
     176Resource requirements may change over the lifetime of an experiment or job. The experimenter may think, ""What would
     177happen if I scaled up the number of compute nodes?"", and want to add more temporarily to test a theory --- without recreating other experiment infrastructure. Compute or I/O-intensive jobs may be able to opportunistically use additional resources to increase throughput. Moreover, cluster or testbed resource requirements change as user workloads come and go. Depending on cluster design, location, and resource requirements, it may be useful for clusters to share resources, seeking temporary ""loans"" from under-utilized clusters to increase job throughput at times
     178of high load.  We have developed new ProtoGENI API extensions, server-side (AM) management and policy code, and client tools to manage experiments whose resource allocations grow and shrink dynamically over their lifetimes. These features support not only dynamic experiments within an AM, but also allow the AM's resources to be used temporarily by other, external clusters. To arbitrate and facilitate sharing between both clusters and experiments with different resources, priorities, guarantees, and users, our dynamic experiment management software employs a mix of flexible policy, soft and hard resource guarantees, and a general, cooperative encoding of resource values among cluster management and dynamic experiment clients to promote eager sharing of unused resources. Our demo will showcase both dynamic experiments, and
     179inter-cluster resource sharing, at several CloudLab clusters. OpenStack cloud experiments at multiple CloudLab clusters will add nodes when they are available, and give up nodes when the local cluster is under pressure. One CloudLab cluster will share its resources with a Condor pool, and the CloudLab share of the Condor pool will grow and shrink. We also hope to have another CloudLab cluster integrated with an HPC cluster running Slurm,with the HPC cluster requesting CloudLab nodes based on its workload demands, or releasing them when CloudLab is under resource pressure (and thus requests or demands them back). We will be able to twiddle policy knobs to induce dynamic change and
     180show how the clusters and experiments adapt. We plan for demo participants to see this resource dynamism and a snapshot of the management software's decisions in a ""dashboard"" web page.
     183 * David Johnson,, Univ of Utah
     187<h1 style="text-align: center; color: #808080">
     188<div class="alignleft" style="width:100%;height:5;border-top:10px solid #808080;"></div>
    165191==== Education Modules using GENI ====
    205 ==== ExoGENI / Science Shakedown ====
    206 ''This demo show recent work on GENI Science Shakedown ''
     231==== Dynamic Slices in ExoGENI: Modifying Slice Topology On Demand ====
     233This demo shows new ExoGENI features including dynamic slice modification. Functionality includes adding/removing compute nodes, storage nodes, and network links.
    307 ==== VNode & FLARE ====
    308 '' This demo shows latest version of VNode testbed and new version of FLARE node. ''
    310 Attendees interested in application providers and network providers should see this demo.  In this demo, we show latest version of VNode testbed. We introduce some new functions of VNode infrastructure and application experiments on VNode testbed. Slice Exchange Point(SEP)-based SDX is also shown. For FLARE demo, we show new version of FLARE using DPDK.
     334==== Building an End-to-end Slice through Slice Exchange between Virtualized WiFi, VNode, and ProtoGENI ====
     337An SDX technology of dynamically building an end-to-end slice across multiple virtualized networks including virtualized wireless access is introduced.
     338We demonstrate building a federated slice between virtualized WiFi, VNode, and ProtoGENI based on the enhanced Slice Exchange Point (SEP) framework over JGN-X and GENI inter-connected testbeds.
    314343 * Akihiro Nakao,, University of Tokyo
    315  * Kazuhisa Yamada,, NTT
    316344 * Michiaki Hayashi,, KDDI
    317  * Shu Yamamoto,, University of Tokyo
     345 *
    328356''Paradrop -- an educational platform to teach network and wireless programming''
    330 Attendees interested in teaching network and wireless programming should attend this demonstration on the paradrop platform.
     358We will demo the Paradrop Platform, which is a software platform that allows developers to launch applications onto specialized Access Points that exist in the home. This provides the ability to introduce unique control and high quality value adds onto services the end-user chooses to use in their home including applications related to Internet of Things,
     359high-definition media content distribution, and others. For this demo, we will showcase the Platform's ability to dynamically launch and control  virtual machines that are running within the Access Point for a few specific services.
    344374''The demo shows a proposed protocol to trace flow paths on a given network composed of SDN network devices. ''
    346 This demo is of interest to attendees who are interested in network troubleshooting operation of traceroute on SDN boxes.  (a) A probe packet is formed to trace a layer 2 frame's path with a proposed SDNTrace protocol. The demo will show a northbound application that processes SDNTrace protocol packets on a network topology created on GENI using VTS. (b) Network troubleshooting is an essential part of network engineers' job with tools such as traceroute, ping, and others. With NSF's investments to upgrade bandwidth and support more orchestrated large science transfers through SDN network devices on campuses, network engineers will be able to utilize our proposed protocol to achieve traceroute functionality. A tracing of paths over SDN network devices is challenging in current deployment experiences. Please see requirements page that inspired and drove this project from the needs assessment of network engineers at  [ Internet2 Technology Exchange meeting] in October 2014:  [ Meeting Notes from BoF at TechExchange2014]. In addition, a project charter has been published on the Internet2's SDN workgroup page, open for comments and participation in the project from the community:  [ SDNTrace Project Charter] Page on Internet2 wg-SDN. [ The poster of our demo is included here.]
     376This demo shows a network protocol to trace L2 flow paths using network function.
     377A probe packet is created to trace a flow paths with an SDNTrace network protocol. The devices on the path will forward the probe to the Network Function (NF). The NF will construct and send a respond packet back to the originator, and as the same time send the original probe back to the devices to forward to the next hop.
     378The process continue until the probe packet reaches the destination and all the traced information is collected at the originator.
    349382 * Deniz Gurkan,, University of Houston
    350  * Joe Breen,, University of Utah
    351383 * Nick Bastin,,  University of Houston
    352  * Amir Ali Kouhi Kamali,
    353384 * Kyle Long Tran,
    413 ==== Resilience of KanREN !OpenFlow network to large-scale disasters ====
    414 '' This demo shows the response of the Kansas KanREN network to large-scale disasters using a GUI to draw the area under the disaster.''
    416 Attendees interested in network resilience and !OpenFlow should attend. Our demo is an interactive visualization system that shows how the KanREN OpenFlow network behaves in the presence of area-based challenges. Our visualization system consists of a Google Map front-end and a server to communicate the events between the front-end and the challenged network. The challenges can be determined by the user using a real-time editable polygon. Furthermore, the visualization system shows real-time performance parameters of the challenged network. When the challenge is applied on the map, the nodes in the polygon will be removed from the underlying OpenFlow network topology. Two controllers are running to monitoring the network and manage the packet forwarding; one is the layer 2 learning switch controller with emulated convergence time, while the other running our geographical routing protocol — GeoDivRP. We present the real-time packet delivery ratio for both of the controllers and demonstrate the effectiveness of our routing mechanism in SDN environment.
    418 Participants:
    420   * James Sterbenz,, The University of Kansas
     444==== GpENI, KanREN, US Ignite Future Internet Testbed & Experiments ====
     445Our demo is an interactive visualization system that shows how a given SDN enabled network behaves in the presence of area-based challenges. Our visualization system consists of a Google Map front-end hosted on a server that also enables event based communication between the front-end and the challenged network. The challenges are determined by the user using a real-time editable polygon. The visualization system shows real-time performance parameters from physical experiments defined by the user and carried out using our KanREN OpenFlow testbed. When the challenge is applied on the map, the nodes in the polygon are removed from the underlying OpenFlow network topology and appropriate measures taken to ensure minimal disruption. As performance metrics, we present the real-time packet delivery ratio as well as throughput for the TCP and UDP based application traffic used in the experiments. Furthermore, we have more recently focused on extensive enhancements to the Google map interface by including controls that allow the user detailed control on the state of the experiments and their varied configuration. We have also working on adding support for Mininet based experiments that would also the user to run OpenFlow based experiments on various topologies that are currently part of KU-TopView, a database of topology data from real physical and logical networks.
     449  * Yufie Cheng,, The University of Kansas
    431460<h1 style="text-align: center; color: #FFC0CB">
    432461<div class="alignleft" style="width:100%;height:5;border-top:10px solid #FFC0CB;"></div>
     464==== EON-IDMS ====
     466The Earth Observation Depot Network (EODN) is a distributed storage service that capitalizes on resources from the NSF-funded GENI and Data Logistics Toolkit (DLT) projects.  The Intelligent Data Movement Service (IDMS), a deployment of the DLT on the NSF-funded GENI cloud infrastructure, realizes EODN to enable open access, reduced latency, and fast downloads of valuable Earth science information collected from satellites and other sensors. Beyond basic storage capacity, the IDMS-EODN system includes mechanisms for optimizing data distribution throughout the depot network while also taking into account the desired locality of user data. Accelerating access enables better synchronization of disparate imagery sets and facilitates new meteorological and atmospheric research applications.
     469  * Ezra Kissel,
     473<h1 style="text-align: center; color: #FFC0CB">
     474<div class="alignleft" style="width:100%;height:2;border-top:2px solid #FFC0CB;"></div>
     477==== GENI Enabled Software Define Exchange (SDX)====
     479This demonstration will show a very early prototype for a GENI enabled Software Defined Exchange (SDX) which utilizes Network Service Interface (NSI) for network element control, and includes public cloud resources from Amazon Web Services (AWS) as part of GENI Stitched topologies. The work demonstrated here is driven by a vision for future R&E cyberinfrastructure that consists of an ecosystem of ad hoc and dynamically federated Software Defined Exchanges (SDXs) and Software Defined ScienceDMZs services. GENI technologies are leveraged in the form of the MAX Aggregate Manager which utilizes the GENI Rack Aggregate Manager (GRAM) software for GENI Federation functions. This MAX/GRAM AM utilizes the Open Grid Forum (OGF) NSI protocol to provision services across the network elements within the Washington International Exchange (WIX) located in McLean, Virginia and the MAX Regional Network.
     481 * Tom Lehman,, Univ of Maryland
     486<h1 style="text-align: center; color: #FFC0CB">
     487<div class="alignleft" style="width:100%;height:2;border-top:2px solid #FFC0CB;"></div>
    473 ==== Software Defined Exchange in the Regional Network ====
    474 ''This demo shows how Software Defined Networking can be applied to the regional network exchange to improve network traffic routing based on rich policy requirements. Visit us to learn how to use GENI to experiment with future network peering and service architectures.''
    476 Attendees interested in learning about Software Defined Exchanges should see this demo. The SDX allows direct expression of flexible network policies in an Internet Exchange Point. At the SDX, ISPs can apply actions on packets based on multiple header fields. This flexibility enables applications such as inbound traffic engineering, redirection of traffic to middle boxes, wide-area server load balancing, and blocking of unwanted traffic.
     528==== SDX at SoX: Software Defined Exchange in the Regional Network ====
     529The SDX provides a promising opportunity to change the way network operators come together to provide new services and richer implementation of policy. This demo provides an update on the GENI SDX project in the SoX regional network.
    479533  * Russ Clark,, Georgia Tech
    480   * Joaquin Miranda
    481   * Bill Eason
    549 ==== Making Internet Routing More Secure with RPKI ====
    550 '' This demo shows a working prototype of a security enhancement for Internet routing.''
    552 Attendees interested in current security threats to Internet routing and potential solutions should attend. The GT-RNOC and SoX are working on an NSF funded project to evaluate deployment options for the Resource Public Key Infrastructure (RPKI) and develop best practices for the research networking community as a first step toward securing the Internet's routing infrastructure. This work includes designing and evaluating the architectures for managing Resource Certificates and Resource Origin Authorizations (ROAs). The work involves deploying RPKI across 21 university networks connected to the SoX regional network based in Atlanta, GA. As a part of this project, we have created a prototype deployment using the GENI testbed to validate our approach.
     602==== Getting to know RPKI: A GENI-based Tutorial ====
     604The Resource Public Key Infrastructure (RPKI) is an important tool for improving the robustness of the Internet by making BGP more secure. This project provides a full RPKI deployment testbed so that network operators can gain experience configuring and operating RPKI in preparation for deployment in their network.
    556609  * Russ Clark,, Georgia Tech
    557   * Joaquin Miranda
    558   * Bill Eason
     610  * Samuel Norris,
     611  * Tito Nieves,