User Tools

Site Tools


arch:light-federation

Lightweight federation of CONFINE testbeds

Abstract

This is a very rough and incomplete proposal for the federation of CONFINE testbeds. The federation of two testbeds A and B consists on the cross-registration of A in B's registry and B in A's registry, which allows a slice in one testbed to use nodes in the other testbed. A user in a federated testbed can only register slices and slivers in its own testbed, although slivers can point to nodes in other federated testbeds. When a user in testbed A contacts one of its registry servers to create a sliver in a node in testbed B, a local version of the sliver pointing to B's node is registered in A, and a remote version of the sliver pointing to A's slice is registered in B. Changing and deleting the sliver works in a similar way. The identifiers of remote slices and nodes in slivers have the peculiarity of carrying a prefix with a local name for the remote testbed.

Introduction

This specification covers the federation of pairs of CONFINE testbeds, each one with its own (possibly distributed) registry having its own name spaces for users, nodes, slices, etc. That means that both testbeds may for instance have nodes with the same identifier (the node@registry:/id member in CONFINE REST API resource descriptions), but they will be different nodes.

Testbed registration

Two-way federation between testbed A and testbed B requires two one-way registrations of A in B and B in A. Registering testbed A in testbed B allows slices in B to have slivers in nodes in A. To register testbed A in testbed B the following information is added to B's registry:

  • a name for testbed A in B
  • a base URI for A's registry API (possibly with a server certificate)
  • a name for testbed B in A

Besides that, A's registry servers must be configured to accept a client certificate that will enable the client to access A's registry API and create remote slivers for slices in B, and to manage these slivers.

When cross-registering A and B, A's names in A and B must match and vice versa.

For instance, a testbed operator of B may register testbed A by adding a new entry to the base@registry:/federated_testbeds array, like this:

// PATCH https://testbed_b/api/
 
[
  { "op": "add", "path": "/federated_testbeds",
    "value": {
      "name": "testbed_a",
      "api_base_uri": "https://testbed_a/api/",
      "api_cert": "(... API server certificate ...)",
      "my_name": "testbed_b",
    }
  }
]

Then B's testbed operator allows A's client certificate to manage slivers of slices in testbed_a. Conversely, an operator of A registers testbed B like this:

// PATCH https://testbed_a/api/
 
[
  { "op": "add", "path": "/federated_testbeds",
    "value": {
      "name": "testbed_b",
      "api_base_uri": "https://testbed_b/api/",
      "api_cert": "(... API server certificate ...)",
      "my_name": "testbed_a",
    }
  }
]

And A's operator allows B's client certificate to manage slivers of slices in testbed_b.

Sliver creation

A user in a federated testbed A can still only register slices and slivers in A's testbed registry, so user authentication stays local to each testbed. However, the user can contact one of A's testbed registry servers to add a new sliver for an existing slice in A while providing a node URI from another federated testbed registry B. In this case, A's registry server (or a delegated component) contacts a registry server in B, authenticates using the client certificate, and registers a remote sliver pointing to A's slice on behalf of the user, then it registers a local sliver pointing to B's node. Changing and deleting the sliver works in a similar way.

Thus in the testbed where the slice is defined, the sliver using a remote node appears normally in sliver description and lists, but it uses the string "REMOTE_TESTBED2_NAME:REMOTE_NODE_ID" instead of NODE_ID for the remote node ID. Similarly, in the testbed where the node is, the sliver from a remote slice appears normally in sliver description and lists, but it uses "REMOTE_TESTBED1_NAME:REMOTE_SLICE_ID" instead of SLICE_ID for the remote slice ID.

The mechanism to locate nodes in other federated testbeds falls out of the scope of this specification. For instance, a user in testbed A may follow the API base URIs of other testbeds in base@reistry:/federated_testbeds:

// GET https://testbed_a/api/
// Link: <https://testbed_a/api/slivers/>; rel="http://confine-project.eu/rel/registry/sliver-list"
{ // ...
  "federated_testbeds": [
    { "name": "testbed_b", "api_base_uri": "https://testbed_b/api/",  // ...
    },  // ...
  ],  // ...
}
 
// GET https://testbed_b/api/
// Link: <https://testbed_b/api/nodes/>; rel="http://confine-project.eu/rel/registry/node-list"
 
// GET https://testbed_b/api/nodes/
[ // ...
  { "uri": "https://testbed_b/api/nodes/12345", "id": 12345,  // ...
  },  // ...
]

Then the user registers a new sliver pointing to B's node:

// POST https://testbed_a/api/slivers/
{ "slice": { "uri": "https://testbed_a/api/slices/97531" },
  "node": { "uri": "https://testbed_b/api/nodes/12345" },  // ...
}

A's registry server notices that the node's URI belongs to the federated testbed named testbed_b, as indicated in A's own registry:

// GET https://testbed_a/api/
// Link: <https://testbed_a/api/slivers/>; rel="http://confine-project.eu/rel/registry/sliver-list"
{ // ...
  "federated_testbeds": [
    { "name": "testbed_b",
      "api_base_uri": "https://testbed_b/api/", "api_cert": "...",
      "my_name": "testbed_a", "my_cert": "..."
    },  // ...
  ],  // ...
}

A's server (or some delegated component) accesses B's api_base_uri to get B's sliver resource list URL, then it registers a new remote sliver pointing to A's slice and B's node (the same description that the user just sent), authenticating itself with the proper client certificate for B:

// GET https://testbed_b/api/
// Link: <https://testbed_b/api/slivers/>; rel="http://confine-project.eu/rel/registry/sliver-list"
 
// POST https://testbed_b/api/slivers/ (with client certificate)
{ "slice": { "uri": "https://testbed_a/api/slices/97531" },
  "node": { "uri": "https://testbed_b/api/nodes/12345" },  // ...
}

B's registry server notices that the slice's URI belongs to the federated testbed named testbed_a, as indicated in B's own registry:

// GET https://testbed_b/api/
{ // ...
  "federated_testbeds": [
    { "name": "testbed_a", "api_base_uri": "https://testbed_a/api/",  // ...
    },  // ...
  ],  // ...
}

And it creates the corresponding remote sliver description:

// GET https://testbed_b/api/slivers/12345-testbed_a-97531
{ "slice": { "uri": "https://testbed_a/api/slices/97531", "id": "testbed_a:97531" },
  "node": { "uri": "https://testbed_b/api/nodes/12345", "id": 12345 },
  "id": "testbed_a:97531@12345",  // ...
}

After successful creation of the remote slice in B's registry, A's registry server registers the corresponding local sliver description:

// GET https://testbed_a/api/slivers/testbed_b-12345-97531
{ "slice": { "uri": "https://testbed_a/api/slices/97531", "id": 97531 },
  "node": { "uri": "https://testbed_b/api/nodes/12345", "id": "testbed_b:12345" },
  "id": "97531@testbed_b:12345",  // ...
}

Subsequent sliver operations work in a similar way by first attempting to change the remote sliver on behalf of the user.

Please note the prefixed node and slice IDs in both local and remote sliver descriptions.

Node operation

Since remote slivers appear normally in sliver listings, they are handled by nodes in much a similar way as local slivers are. Nodes must however be careful to detect remote slices (e.g. by their prefixed IDs) and tell them apart local from local one, especially to avoid clashing identifiers when retrieving slice, group, user and template descriptions. In case of publishing them back through the node API, IDs of remote resources should be properly prefixed.

Nodes may use the certificates in base@registry:/federated_testbeds to authenticate their connections to other testbeds' APIs.

Open issues

  • If slices can span several testbeds, it makes sense to have remote slivers accessible by connecting both testbeds' management networks using gateways. However, Addressing in CONFINE should be revised to avoid clashes between local and remote slices with the same IDs having slivers in the same nodes, e.g. by using bytes at the beginning of the host part of IPv6 management addresses to encode a federated testbed ID. Federated testbeds may thus become independent resources in the API instead of items in base@registry:/federated_testbeds.
  • Slice-wide resources which are applied in slivers may cause some conflicts. For instance, a VLAN tag allocated for isolated sliver interfaces to a slice in one testbed may already be in use by another slice in a federated testbed. If the two slices are to use the same node a conflict may occur, and one of them may fail to be allocated, or both may use the same tag, possibly violating slice isolation in the node and with neighbouring nodes. Additional mechanisms should be put in place, like asking federated testbeds whether they are using a candidate VLAN tag to be allocated to a slice on deployment.
  • Identifiers for slices and nodes in the registry API can either be integers (local) or strings (remote). This may make the storage and processing of descriptions more difficult.
  • Remote slices and nodes are detected by their prefix, which must match the one registered in base@registry:/federated_testbeds. This limits the number of entry points to federated testbeds.
  • Because of remote sliver registration, registry servers acquire some “active” behaviour, instead of the “passive” one associated with the pull strategy. However remote tasks may be delegated to some other simple component getting requests from local registry servers and issuing them to remote ones.
  • Federation works in explicit pairs, there is no support for transitive or hierarchical federation, where federating testbeds A and B offers A access to all testbeds federated with B.
arch/light-federation.txt · Last modified: 2014/11/04 16:14 by ivilata