wiki:GEC10Stitching

Version 15 (modified by Aaron Helsinger, 14 years ago) (diff)

--

GENI Network Stitching

Session Leader

Tom Lehman, ISI
Aaron Helsinger, GPO

Time

Wed 3:30 - 6 pm

Dial In

866-453-5550 Participant pin: 6513886#

Description

This meeting will strive for consensus on a software architecture for network stitching in GENI. A key architectural question for GENI has been how to connect the resources provided by multiple aggregates into a coherent network. The key objective is to enable automated and realtime network stitching for slices which span multiple aggregates. Ethernet VLANs have been identified as the initial network technology to provide slice level inter-aggregate connections and isolation. However, there are many architecture and design decisions still required. These include, how do you select the VLAN IDs to use and inform all necessary aggregates? How do you handle external networks which may be in between two GENI Aggregates of interest? Is the network stitching service a shared service which coordinates across aggregates, or are aggregates responsible for coordinating amongst themselves, or a hybrid model? How is stitching related information described and shared ?

Over the years the community has discussed this in various forums, and multiple implementations are in use in the community. However, it is now critical to define an architecture and design which will enable networking stitching to be generally available within GENI. In recent weeks that discussion has become more focused and several key stakeholders have debated various alternatives. This meeting will include a presentation of a proposed GENI network stitching architecture and alternatives, and an open community discussion on these issues.

Proposal

The Stitching workshop, led by Tom Lehman of ISI, outlines a draft architecture for stitching together slices which span multiple aggregates. This proposal is intended to be compatible with at least ProtoGENI, Orca and OpenFlow approaches to stitching. This draft architecture would be fleshed out over coming months, aiming for a demonstration at GEC12.

The proposal envisions two pieces. First the proposal describes aggregate-to-aggregate touch-points in a common RSpec format so that a topology service can support reasoning about potential network paths across GENI. Second a path computation service and a stitching workflow function (which may be centralized, at the client, or within each aggregate) can coordinate reservation of network paths.

This work initially focuses on stitching via VLANs, but is designed for future extension to other technologies as necessary.

Agenda

  • Introduction - Aaron Helsinger (10 mins) slides​
  • Proposed Architecture - Tom Lehman (40 mins) slides​
  • Invited Discussion - Rob Ricci (15 mins) slides​
  • Invited Discussion - Jeff Chase (15 mins) slides​
  • Invited Discussion - Rob Sherwood (15 mins) slides​
  • Discussion - All (45 mins) slides​
  • Summary and Wrap Up - Aaron Helsinger (10 mins) slides​

Community Agreement from the meeting

The session concluded with community agreement on three points:

  • GENI stitching will follow the described architecture
  • Details will be worked out
  • Next steps as outlined below

Next steps

  • Schema: Jon Duerig of ProtoGENI is iterating on a PG-compatible stitching schema that preserves ION compatibility.
  • Functions: The community will continue discussing key points, particularly working out how chain & tree interoperate, and working though some use cases.
  • API to be proposed for adoption at GEC11
  • Interoperability demonstration at GEC12

Selected points from the discussion

  • Don't make use of all functions mandatory.
  • Functions are not necessarily new architectural boxes
  • Tom suggested some functions could have an implementation which exists as a central GENI service (eg Topology Service), available to all for use as desired. Although use would not be required.
  • The architecture should not force CFs to redo work they've already done
  • We must support both chain and tree workflows
    • Can they work together? Is 1 a subset of the other, modulo security?
  • How much direct negotiation between aggregates is required? This adds complexity, but without VLAN translation may be necessary.
  • How prevalent should we expect translation to be? do we optimize for it?
  • Work out some use cases. For example, make sure a large topology that loops back (A -> B -> A) is explicitly worked through as an example and supported.
  • Updating of information in the topology service is a question: keeping it up to date is hard, but 'static' data may change very often
    • perhaps support both a push&pull AM auto-update mechanism?
  • At the high level of this discussion, all speakers expressed their support for this effort and basic design

Background Reading

First, read the Wiki page and figures
Second, read ​GENI Network Stitching Architecture - Overview
Other documents have further details

Further Reading

Attachments (7)