"BT University Research Initiative"
 Contents BT URI  NCAM  NetOS 

 Introduction BT URI  NCAM  NetOS 
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.

 Background BT URI  NCAM  NetOS 
Experiments at the University of Cambridge Computer Laboratory have already investigated this technology with a number of commercial ATM switches. The advantages switchlets provide over conventional virtual networks based on permanent virtual paths (PVPs), is the ability to supply a control architecture to control each switchlet. This control architecture could be ITU standard signaling, ATM Forum PNNI or an experimental control architecture. However, in all cases it can exert control at switches in the middle of the service network, not just at the edges as in the PVP case.

The BT URI on Management in Multi-service Networks includes (preliminary) Cambridge-Imperial work on policy interpretation for network management control. Network management control can be broken down into two kinds of policies: Authorisation polices and obligation policies. Authorisation polices defined what actives an agent can perform while obligation policies define what active s an agent must or must not perform. Authorisation polices allow the system administrator to control access to various resources in the system. An authorisation policy for a network might be that a manger can only get access to the video conferencing network every other Tuesday from 2pm to 4pm. Obligation polices can be used to define how the bandwidth of the service is to be allocated under various conditions. For example: if a customer wants to use the network and there is no bandwidth preempt some experimental bandwidth. This is called a positive obligation policy because it defines what must occur under certain conditions. A negative obligation policy defines what must not occur if some condition is true. For example: when the bandwidth available drops below a certain threshold then no new research bandwidth can be allocated. Using authorisation and obligation polices one can define quite complex policies to setup and manage the virtual network. Using commercial ATM switches and a switchlet based Managed Virtual Network Service with support for complex policy will provide an environment for rapid experimentation both with applications and network control.

 Papers BT URI  NCAM  NetOS 
 Collaboration BT URI  NCAM  NetOS 
Our work complements that of the other URI partners in the following ways:
  1. Since each virtual network will run its own control architecture (CA) and the CA of choice for the ISP (eg BT-NET) will be IP switching of some variant, managment of the IP layer in a way which is consistent with that vetted by the IETF will be crucial. The proposed UCL work will deliver a draft standard for management of the end-system IP stack. Included in the management protocol is a facility for managing resources, which are required for the delivery of QoS guarantees. A virtual network running IP switching will provide the ability to manage resources on a per flow basis, and it is important that the management of those resources matches end system needs. The UCL ISP management stack may be a good candidate for the managment of resources on an IP switching virtual network and we will track it accordingly.

  2. Our work will provide the mechanisms required to manage the subdivision of the resources of an ATM switch into switchlets. Crucial issues which must be addressed include the way in which the resources can be divided, and the policy used to schedule competing needs for switching resource between the switchlets. The Imperial College work on policy expression is of direct relevance, and will be used in developing the management interface to the switch divider. Key to the success of the expression of resource constraints is the ability to expresss QoS requirements in a policy language. We will closely track the Imperial work in this regard.

  3. Lancaster binding models: The entire Lancaster approach to service provision is a natural candidate for exploiting our proposed work. The Information Services Supermarket (ISS) is in itself a control architecture, of a highly customised nature, which could be provided as a particular service over a virtual network of switchlets. The advantage of the Cambridge approach is that we can support the ISS as a control architecture in one virtual network, whilst simultaneously supporting standards based ATM control in another, and IP switching in yet another virtual network. We see our work as entirely complementary to theirs, which builds on work at Columbia in the xbind project.
 Cambridge Deliverables BT URI  NCAM  NetOS 
Our work complements that of the other URI partners in the following ways:
  • Networks on Demand Architecture Document 30.6.97

    This document will describe the architecture to be implemented over the remainder of the project. The architectural issues have already been explored with BT, and will be broadly in line with the original aims of our part of the URI work, however the introduction of the switchlet concept as the best way to deliver the MVNS has significantly changed the approach to managing services in the network. We will explore the requirements on policy expression, security and functionality required in the management interface, drawing on the on-going work at IC on policy expression.

  • Networks on Demand Initial Implementation and Report 30.12.97

    We will deliver an interface implementation which allows the network manager to dynamically create virtual networks of various types. The type of the network is dicated by the type of control architecture which it uses to control communications. The implementation will include a Reservation Scheduling/Policy Module which allows the operator to schedule the creation of virtual networks of a given type and manage their resources. Drawing on the IC work on policy expression, this module will include facilities for management of resources using authorisation and obligation policies. The module will ensure that the scheduled use of the physical network is feasible, and will ensure that network management is undertaken only by those authorised to do so.

    A second part of the work will be a (graphical) user interface to facilitate the control of switches and switchlets. The policy module will interact with this user interface to present a unified policy/managment interface to the virtual network service.

  • Xbind Port To Switchlets (Implementation and Report) 30.3.98

    At Opensig Spring 97, held in Cambridge, it was suggested that the xbind control architecture for open networks should be 'pushed' through standards bodies as a candidate for open service provision in ATM networks. We would like to investigate the xbind architecture more fully, by porting the xbind 'virtual switch' to a switchlet interface. This will give us a CORBA compliant open interface to the virtual network service, on top of which the Lancaster ISS can be directly implemented (it is our understanding that their work builds on the xbind interface). In addition it will give us and BT the ability to assess the utility of this interface, gain understanding of it, and perhaps assist with any proposed standardisation effort.

  • ISS over switchlets (interoperability report) 30.6.98

    We have as our goal with the xbind work the ability to support the Lancaster ISS as a control architecture on top of the virtual networks provided by our work. We see the collaboration with Lancaster as a major benefit -- we hope that it will be possible to run the Lancaster ISS together with other control architectures simultaneously on top of a single ATM network, with guaranteed resources allocated to each. Issues of compatibility of the CORBA ORBs used by each party must be addressed, and we will liaise with Lancaster in this regard. Should it prove simple to port their work, we will do so. Alternatively, we will report on the interoperability issues experienced whilst attempting to port their work to the virtual network environment.

  • Performance study of NOD 30.12.98

    A crucial issue relating to the acceptability of open control of ATM networks is the performance of the system with regard to the rate of connection/flow setup. At Opensig Spring 97 a talk identified CORBA implementations as being key determinants in this regard. Cambridge will be using for its work a highly optimised CORBA2 compliant ORB for which we have access to the source code. We will undertake a detailed performance study of the open control interface, the management interface and the xbind virtual switch interface to the virtual network, commenting on issues which will need to be resolved in a commercial strength implementation of the MVNS.

  • Management of Open Networks using Mobile Code 30.6.99

    Rob Davison of BT expressed an interest in the use of mobile (or down-loadable) code for network management and configuration. We see this as an interesting use of the open control approach, and compatible with our proposed work on the MVNS. We need to learn more about the current network management problems which BT experiences in this regard, and to combine our current implementation of the Hollowman (a control architecture which allows mobile 'connection closures' to be used to control a virtual network) with the requirements of BT in terms of managing switches in a unified way.

  • NOD Version 2 Demonstration, Evaluation and Report 31.9.99

    Building on the first implementation, and the experimentation and development which will follow it, we will deliver a final demonstration, evaluation and report on the feasibility of the use of the MVNS for service provision.

$Id: index.html,v 1.3 2000/01/17 14:25:34 rmm1002 Exp $