Changes between Version 9 and Version 10 of GEC19Agenda/ProgrammableWAN


Ignore:
Timestamp:
03/26/14 11:37:12 (10 years ago)
Author:
tmitchel@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC19Agenda/ProgrammableWAN

    v9 v10  
    3333
    3434
    35 The goal of this session is to discuss the current and future capabilities of the GENI Programmable WAN: that is, what GENI does and can provide to experimenters to create a custom topology whose networking can be programmed. The current plans are to establish the "GENI OpenFlow Network" with stitching capability to support this capability. But in addition the community is and should be providing other services to provide experimenters with different kinds of programmable WAN capabilities including software switches, pre-allocated resources, different connectivity technologies.
     35The goal of this session is to discuss the current and future capabilities of the GENI Programmable WAN: that is, what GENI does and can provide to experimenters to create a custom topology whose networking can be programmed. The current plans are to establish the "GENI !OpenFlow Network" with stitching capability to support this capability. But in addition the community is and should be providing other services to provide experimenters with different kinds of programmable WAN capabilities including software switches, pre-allocated resources, different connectivity technologies.
    3636
    3737The session will frame the discussion in terms of the program goals, then some current and possible future directions in these areas.
     
    5252The session consisted of six presentations on a range of topics around the broad theme of programmability of networked topologies.
    5353
    54 Marshall Brinn introduced the session with some brief framing comments on what is meant by "Programmable WAN". He stressed that being able to allocate custom network and resource topologies is a critical part of GENI, but that the 'deeply programmable' is just as critical to the program's goals and self-definition. In a deeply programmable WAN, the network topology must contain programmable switches (or forwarding elements) at which traffic routing decisions can be made, traffic can be modified or filtered, usually by means of an external controller. He pointed out that there are current ways to achieve such programmability in GENI (e.g. the GENI OpenFlow Network using stitching, ION and possibly mesoscale links) or using click routers or OVS switches, each with their own strengths and limitations for particular experimenter requirements.
     54Marshall Brinn introduced the session with some brief framing comments on what is meant by "Programmable WAN". He stressed that being able to allocate custom network and resource topologies is a critical part of GENI, but that the 'deeply programmable' is just as critical to the program's goals and self-definition. In a deeply programmable WAN, the network topology must contain programmable switches (or forwarding elements) at which traffic routing decisions can be made, traffic can be modified or filtered, usually by means of an external controller. He pointed out that there are current ways to achieve such programmability in GENI (e.g. the GENI !OpenFlow Network using stitching, ION and possibly mesoscale links) or using click routers or OVS switches, each with their own strengths and limitations for particular experimenter requirements.
    5555
    5656Nick Bastin of Barnstormer Softworks reported on his recent progress on the VTS (Virtual Topology Service) effort. He demonstrated a prototype of this capability at demo night, showing the creation of OVS-based switches and connecting them to GENI resources (allocated in a subsequent allocation). In this way, a fully programmable, segregated network space is provided. There were many comments reflecting  hopes and interest in the promise of this approach. There is still considerable work to be done, particularly in the areas of tooling (new tools or integration with existing tools) to make this an easy-to-use capability for experimenters. VTS requires bare-metal PC's to work and there was some discussion about how to best allocate resources to this task: the PC's on the IG and EG racks are probably too weak in network throughput and too strong in CPU to be good matches. This is a topic still to be discussed and resolved. Currently, OVS supports two disk images: OVS 2.0.1 and OF 1.0; Nick plans to add additional disk images in upcoming VTS releases.
     
    5858Eric Boyd of Internet2 discussed upcoming plans for AL2S deployment and the Flowspace Firewall. Their intent is to allow experimenter-provided controllers to register with the firewall and allow these controllers to control traffic only on that experimenter's traffic. He described the Flowspace Firewall as containing two main goals: "VLAN Slicer" (i.e. using VLAN tags to dispatch traffic to the right controller as needed) and "Resource Protector" (i.e. not allowing OF commands from the controller that would go outside the VLAN limitations, or to limit the frequency or number of flow-mods a controller can present). Eric described the policies and procedures for vetting a proposed experimenter controller, including discussions and interviews between I2 and the experimenter, running the controller on a test configuration and then deploying within Flowspace Firewall.
    5959
    60 Rick McGeer of US Ignite gave a demonstration and presentation on GEE, the GENI Experimenter Environment. The goal of this tool is to provide an experimenter with a simple environment for running and controlling distributed programs. The infrastructure runs on PlanetLab slices and provides a python-based compute environment. The next things to be added are a slice-shared messaging and storage service. Rick said their goal was to be able to do "Hello World" in five minutes, but in fact he demonstrated a distributed map update application using GEE in 2:39. The capability is, by intent, limited to satisfy a broad but not complete set of experimenter requirements: anyone needing what GEE doesn't provide is encouraged to move on to "the real GENI".
     60Rick !McGeer of US Ignite gave a demonstration and presentation on GEE, the GENI Experimenter Environment. The goal of this tool is to provide an experimenter with a simple environment for running and controlling distributed programs. The infrastructure runs on !PlanetLab slices and provides a python-based compute environment. The next things to be added are a slice-shared messaging and storage service. Rick said their goal was to be able to do "Hello World" in five minutes, but in fact he demonstrated a distributed map update application using GEE in 2:39. The capability is, by intent, limited to satisfy a broad but not complete set of experimenter requirements: anyone needing what GEE doesn't provide is encouraged to move on to "the real GENI".
    6161
    62 Joe Mambretti of ICAIR presented recent work on "Peta-scale Science Prototype Services Facility and Programmable WANs". He discussed the concept and details of high-performance software-defined exchanges that allow SDN controlled traffic to flow across different administrative domains. He describe a range of such exchanges and demonstrations/experiments that his StarLight facility has participated in that have provided high-throughput programmable connections across wide-area (often international) domains.
     62Joe Mambretti of ICAIR presented recent work on "Peta-scale Science Prototype Services Facility and Programmable WANs". He discussed the concept and details of high-performance software-defined exchanges that allow SDN controlled traffic to flow across different administrative domains. He describe a range of such exchanges and demonstrations/experiments that his !StarLight facility has participated in that have provided high-throughput programmable connections across wide-area (often international) domains.
    6363
    6464Jerry Sobieski of NORDUnet discussed his recent work with the GEANT EU network testbed and how they approach cross-domain programmability, control and coordination. He discussed, also, the evolving NSI standards for resource allocation, monitoring and control: there was brief discussion pointing out the clear parallels between NSI and GENI API's and that there may be common benefit by trying to align these two different technology bases. Jerry described a set of EU testbed configurations and experimental topologies with different programmable traffic management and QoS.