Skip to content
This repository has been archived by the owner on Oct 26, 2022. It is now read-only.

Topology embedding extensions #3

Open
ibaldin opened this issue May 12, 2015 · 2 comments
Open

Topology embedding extensions #3

ibaldin opened this issue May 12, 2015 · 2 comments
Assignees

Comments

@ibaldin
Copy link
Contributor

ibaldin commented May 12, 2015

See the attached picture for diagrams. We would like the topology embedding algorithm to extend to the following cases:

  1. connecting a broadcast link in one rack to a broadcast link in another. Right now this can be emulated by using node groups, but a more general solution would allow for heterogeneous nodes to be attached to a bcast link, then linked to another one in another rack.
    2.Dealing with two stitchoports in a request that come from the same stitchport URL, but different vlan tags. This likely requires introducing a virtual port in the request (so it propagates into the manifest).
  2. Being able to attach stitchport(s) to a bcast link. Probably similar to 1 and 2 above.
  3. Being able to not specify the VLAN tag on a stichport, instead having Net AM return the selected tag out of the available range. This supports GENI stitching (tag 'any' in RSpec).
  4. Be able to attach storage to broadcast links.
  5. For shared storage, do not create extra interfaces (and assigned extra IP addresses) to a node that attaches to multiple ISCSI volumes from the same site.
@ibaldin
Copy link
Contributor Author

ibaldin commented May 12, 2015

Item 1 resolved as abstracted embedding where the user specifies what needs to be connected, not how. This is done through 'generalized nodegroups' concept where each node can be treated as a node group attached to a broadcast link. The embedding takes care of figuring out when to use point-to-point vs. multipoint connections

Item 2 above has been confirmed to work for GENI stitching. Introduced virtual stitchports to support this.

Item 3 resolved similar to Item 1

Item 5 similar to 1

@ibaldin
Copy link
Contributor Author

ibaldin commented May 12, 2015

Here is a corner case that probably should work somehow, or at least generate an error eg_renci_pub.txt. In it there is a slice with two VMs in one rack that are connected to a shared VLAN (907 at RCI in this case) in that rack and both have links to a VM in another site (BBN). The resulting slice ignores the static VLAN and does not generate an error.
Either we don't handle it, or we handle it (by, perhaps requiring that there is inDomain statement in the shared VLAN to make embedder's job easier) or by inferring that if all VMs connected to a link have the same domain and a specific tag is being asked for, it MUST be the shared tag. Or something else. Anyway, interesting case.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants