Linktypes

This page is out of date and incorrect!

Below are preliminary ideas for how to deal with link types. They are not yet implemented.

There are two different notions that we want to encapsulate with link types. First, we want to provide information about what layer and networking technology a link uses to transmit packets. Second, we need to provide the user with information about how their experimental traffic will be encapsulated.

Link types are more complicated than node types because we may need to map a virtual link on multiple physical links. Where this happens, the link types must all be the same. If VLANs are to be used, for instance, then all physical links along the way must support encapsulating the traffic with a VLAN.

Each advertisement contains a set of types on each link. This is the set of encapsulating technologies which are allowed to send along that type. These might be things such as OpenVPN, GRE, EGRE, VLAN, etc.

Each advertisement also contains a set of type classes which contain a set of types. Type classes may not contain other type classes, but they need not be mutually exclusive or partition the types. The type classes may represent additional information which describes a part of the space. For instance, 'ethernet' or 'ip' may describe sets of encapsulation technologies which allow experimental traffic using those protocols. 'tunnel' may be a type class which describes the set of tunnel technologies.

Each request contains zero or more set of type or type class names per link. If there are no type or type class names, that leaves the choice of encapsulation type unconstrained. If there is at least one type or type class names, then the CM must choose a single type among those specified by the user and also among each link.

The set of allowed types for the virtual link is composed of the intersection of allowed types for each physical link that virtual link is mapped to. The set of allowed types for each physical link is the union of every type class set referred to by the user which are supported by that physical link in the advertisement and the set of types the user explicitly specifies which are supported by that physical link.

In a request, any link which spans two ComponentManagers may only have a single link type and may not have a type class. This is a temporary constraint until we figure out how to properly do coordination between CMs regarding selection of the encapsulation technology.

Example Advertisement Fragment:

<link ...>
  <link_type name="VLAN" />
  <link_type name="EGRE" />
  <link_type name="GRE" />
  <link_class name="ethernet">
    <type name="VLAN" />
    <type name="EGRE" />
  </link_class>
  <link_class name="tunnel">
    <type name="EGRE" />
    <type name="GRE" />
  </link_class>
  ...
</link>

In the above example, there are three link types supported on this physical link: VLANs, EGRE tunnels, and GRE tunnels. There are two overlapping classes, one of which are those encapsulations which support traffic at the Ethernet layer, and the other describing tunneling encapsulations.

Example Request Fragment:

<link ...>
  <link_type name="VLAN" />
  <link_class name="tunnel" />
  ...
</link>

In this request, the user is asking for either a VLAN or any tunnel between the endpoints.