Protogeninetworkaccess

Network access for nodes in ProtoGENI

It became clear when we were discussing how to implement the "control net" on protoGENI nodes, that I was conflating a couple of things. There are three aspects to the network in a protoGENI experiment:

• The data plane. This is the "topology" where interesting stuff goes on. It is by its very nature, "unroutable" in the IP sense: today because we are using unroutable IP space for the links, tomorrow because we might not even be using IP within the topo. In Emulab and Emulab-derived systems, the data plane is made up of dedicated links. In VINI, it is an explicit overlay on the Internet. In PlanetLab, the Internet itself is the data plane or is a user-constructed overlay.

• External access to the data plane. How does data get in and out of the topology from the Internet? In Emulab, this can happen at any (physical) node in the topology because all nodes have publically-visible, routable IP addresses. Ditto for PlanetLab. In other Emulab-derived systems like DETER, everything has to be proxied via the "ops" node. In VINI, I believe there are explicit ingress and egress nodes, coupled with VPNs and NATs to ensure correct routing.

• The control plane. This is how the configuration, control and monitoring of an experiment takes place. Every node is connected to some "control net" to allow this. In Emulab, there is a separate (from the data plane) LAN that is used. However, while separate, this LAN is also used for external access to the data plane. In VINI and PlanetLab, the Internet is the control plane.

So what does this mean for protoGENI now and GENI down the road? Well I was assuming the Emulab-esqe two networks, control net and experimental (data) net. The former would be (directly) Internet accessible, the latter would not. However, giving a routable IP to every virtual node on every physical node is not feasible and sharing a physical node's single IP address and port space is made difficult when virtual nodes run in their own network name space (ala VINI and protoGENI).

But maybe this isn't needed. For access to the data plane, explicit ingress and egress points may be sufficient (and even necessary), hence not all virtual nodes need direct Internet access. For the control plane I think the general feeling is that, at least for awhile, it will need to be an IP addressable network. But does it need to allow direct access to every node (component) from the Internet? For Emulab, VINI and PlanetLab, this is the case. However, at least for Emulab, this is not fundamental; e.g., DETER has an unroutable control network. The Emulab-provided control and monitoring infrastructure is accessed via one or more visible servers. So one could envision an overlay control network--IP today, something else tomorrow--and thus avoid the problem.

Note: Jon points out that "the control net" and "public IP access" don't have to be the same thing. ie. we could run the control net over some tunneled/NATed thing, and have programs make themselves available to the public Internet on a separate interface.

So what are we going to do in protoGENI? Well, as the discussion above suggests, there is possibly not a need for a per-node public IP address on every virtual node; that facility currently serves two purposes and those two purposes are likely best handled by distinct, possibly non-IP, mechanisms.

That said, a short-term goal is still to try to accomodate this familiar per-node IP, since it is what Emulab and PlanetLab users know. However there is some difficulty in providing this, due to the semantics of NetNS, which is used by Trellis (the current VINI kernel), and that we plan on using for our wide-area nodes.