next up previous
Next: Loading application-specific code Up: im99 Previous: Basic operations


Recursively partitioning networks

The primary operations are expected to be sufficiently expressive for a large class of applications. Some applications, however, have very specific needs so, in order not to restrict them, we propose to give these applications a number of resources which are theirs to use as they please (i.e. without imposing on them connections of any predetermined type). This is also useful for certain network management tasks. For example, it has been suggested in [#!Schill:97a!#] to partition resources in the (virtual) network, so that immediate reservations are shielded from advance reservations (and vice versa). For this purpose the Sandman allows a client to make (possibly advance) reservations for something called a netlet, which is a small virtual network in a larger virtual network.

Netlets consist of (a share of) an arbitrary set of resources within the encompassing virtual network (VN). For example, for a switch port we specify a netlet element consisting of the switch name, port number, direction (i.e. in or out), number of channels (e.g. VCIs in ATM) and bandwidth. These elements need not be adjacent as one netlet may consist of multiple unconnected sub-partitions (see Figure [*]).

Figure: Netlet in virtual network
\includegraphics[width=3in]{vnets.eps}

Netlets can be created recursively, so it is possible to create netlets in netlets. This enables applications to repartition resources almost unrestrictedly. In fact, the encompassing VN of section [*] can itself be thought of as a netlet (the null-level netlet). Repartitioning network resources merely extends the idea of switchlets into the MCA. This has a number of advantages. We briefly mention two:

1.
Policing differentiating. VNs must be policed, because misbehaviour in one VN (null-level netlet) ${\cal N}_0$ should not affect any of the other VNs. Given null-level policing, however, we can decide not to police at a higher-level netlet, because even if connections in the netlet misbehave, the problems will be limited to ${\cal N}_0$ only and not propagate to the outside world. (Note that the final responsibility of shielding different domains from each other, lies with the switch divider-this is why recursive partitioning in the MCA does not obsolete the partitioning by the divider.)

We can now differentiate the policing policy in the network, e.g.: given that there is hard (in-band) null-level policing, we can decide to police specific netlets only very loosely (e.g. by periodically taking measurements from switches to see if they have exceeded their allocated bandwidths) and certain other netlets not at all. In fact, the looseness may vary from netlet to netlet. In other words, netlets are light-weight VNs (in this sense, the relation between a higher-level netlet and a VN is similar to that between a thread and process).

2.
Partitioning. Using netlets, it is easy to separate immediate and future reservations as proposed in [#!Schill:97a!#].

At the start of the reservation interval, the netlet resources are allocated to the application which requested them. Using simple operations the client can set up and tear down end-to-end connections in netlets. At the end of the interval, the MCA automatically tears down all connections belonging to the netlet and releases its resources. However, since the resources of a netlet are said to belong to a specific application (and nobody else), the application should be able to manipulate these resources in any way it wants to, not just by setting up connections between endpoints. For this, applications need control at a finer level of granularity than end-to-end. For example, we want to enable applications to set up a connection across an individual switch from a specific input (port, vpi, vci) to a specific output (port, vpi, vci). This allows applications to build their own connection types and setup mechanisms. We call such low-level operations tertiary operations.


next up previous
Next: Loading application-specific code Up: im99 Previous: Basic operations
Herbert Bos
2001-12-11