Emerging ATM networks will have to fulfill a number of conflicting
needs. Perhaps the most striking conflict is the difference between a
service network to support "real" users and an experimental
network where both experimental applications and experimental network
control are supported. Clearly, the experimental traffic, which may
be ill-defined and disruptive should be isolated in some way from
service traffic. Of course, the partitioning of different types of
service traffic, for example IP and native ATM services, is also
desirable. This proposal is aimed at solving this conflict by
providing a service from which users can request the dynamic provision
of virtual networks. We call these "Networks on Demand" (NOD). The
networks may be created and destroyed by users providing that they are
authorised to do so and that they stay within the policies determined
by the "real" network operator. Thus we are interested in a
managed service that provides virtual networks to the users of the
network. This is in contrast to a service that manages virtual
networks on behalf of some user, and fundamentally different to the
current use of the term "virtual network" meaning a set of virtual
paths, because our scheme facilitates control of subsets of the
network resources in different ways, by each different virtual
network.
There are at least two aspects to partitioning. The first is the
control of resource contention, for example link capacity or switch
buffers. We propose to solve contention by strict policing and
sensible buffer/queuing arrangements in the ATM switches. The second
is a partitioning of traffic into different virtual networks with each
virtual network having its own management and control (signaling)
system. This approach has additional benefits of security and
robustness.
A user should not be able to alter the connections in a virtual
network to which they are not attached. While the two types of
partitioning can be regarded as orthogonal, it is hard to imagine
doing the second without doing the first. The virtual path concept of
ATM allows these partitioning functions to be performed in a
straightforward manner. A virtual network can be constructed (by the
operator) by configuring a set of semi-permanent virtual path
connections with resource dedicated to these paths. One way to
administer the allocation of resources is with the well-known leaky
bucket technique.
A Managed Virtual Network Service, on the other hand, is a facility to
allow users (with appropriate authority) to create, modify and destroy
virtual networks, on demand. It enforces policy on which users are
allowed to use which underlying resources (and virtual path address
space) and under what conditions. A key aspect of the system is the
authentication of users and the security of the operations. Different
users will of course have different roles. The managers of the
underlying network resource would likely configure a number of virtual
networks which would be long-lived. A video conferencing network
might be an example. Research projects might wish to configure
virtual networks which might last only as long as a particular
experiment. This might be as short as a few hours.
The resource given to experimental virtual networks might be
recoverable on a pre-emptive basis by other users, but this would need
to be prevented other than in exceptional situations. An automated
Managed Virtual Network Service is clearly attractive, but its
provision raises issues that it is intended to solve: it will by
nature be an experimental service in its early inception. We propose
to approach this using the technique of 'switchlets' developed at
Cambridge outside the URI work. This requires the devolution of
switch control from switches into a distributed computing environment.
Within the distributed computing environment, the resources of any
switch can be partitioned into logical 'switchlets'. Switchlets can
be logically interconnected in an arbitrary topology to form sets of
distinct virtual networks. One resource available at switches is
clearly virtual path address space; we would imagine that each virtual
path would belong entirely to one or other virtual network. A second
resource is bandwidth - switchlets with guaranteed bandwidth will be
able to hand out resources with QoS guarantees to their
connections/flows, whether they be IP, signalled ATM or proprietary
communications. In order to successfully devolve control from the
switch, we may use a control protocol (or switch API) for
communication between the switch control software and the control
processor on the physical switch. Note, however, that it is not
necessary to run the control architectures off the physical switch.
As long as the switch control interface is 'open' in the sense that
external controllers can use it to issue commands to, and manage the
switch, then that is sufficient for our purposes. Hence, any ATM
switch which supports external control via some published interface,
for example GSMP, is suitable for our purposes.
|