Figure
11. Use of Switchlets to virtualise ATM
switch control.Authors: Simon Crosby, Ian Leslie, Cambridge University Computer Laboratory
Jon Crowcroft, UCL Computer Science Department
Lionel Sacks, Chris Todd, UCL EE
The realisation of the Communications Centre joining
the strengths of Cambridge with those of UCL, and the ongoing
London Communications Centre involving Imperial College, Kings
College, QMW and UCL represents a unique concentration of research
skills and professional training facilities in communications,
certainly in Europe and probably World Wide. The support that
BT has given these initiatives and in particular the offer of
the London East Anglian Network (LEANET) as a potential active
experimental base represents a vital step forward.
Given the scale of LEANET and the implicit complexity
of proposed collaborative experimental work on that network, there
are a number of critical factors to consider.
Although these critical factors are demanding, UCL/CAM
believe their solution is eminently justified by the scale of
the research opportunity that collaboration on LEANET could provide
at this critical juncture in the evolution of the communications
business. The programme, which forms the basis of this proposal,
has been targeted at this opportunity and is far too large for
the envisaged two RAís to complete in 3 years, given their
other duties outlined above. To complete this programme, and
the one or two others that are ëa gleam in the eyeí
but will take shape soon, will require a critical mass of researchers
and the portfolio approach also outlined above.
The provision of new services on current and future
high speed networks will require network elements to be flexible
and easily controlled, because service components will require
specialised communications features to be implemented within the
provider network. The Asynchronous Transfer Mode (ATM) has been
widely hailed as a solution to the problem of supporting multiple
services, because it appears to offer the best prospects for solving
a particularly awkward problem in an integrated communications
environment, namely the accommodation of multiple services with
widely differing resource and performance demands.
Research in recent years has focused on the traffic
controls required to ensure that data transmissions from multiple
sources of different types each receive the appropriate level
of service from the network. Typically these controls are located
in the data path, and include scheduling techniques, policing
and shaping functions. Until recently, however, few researchers
had seriously considered the control plane aspects of the provision
of multiple services in broadband networks. Key to the provision
of new services and the support of existing and standards-based
services is the requirement for a powerful, and flexible network
control mechanism capable of meeting the needs of multiple network
services, such as native ATM connections, IP, IPv6, and specialised
services tailored to specific communications needs, including
video distribution, remote sensing or conferencing. ATM as a
multiplexing technique can provide resource management for new
services, however ATM as standardised by the ITU-T and ATM Forum
is inflexible and does not encourage the development of services
which require modes of communication or control which cannot be
expressed in the standardised UNI protocols. Unfortunately the
standardised protocols are not sufficiently expressive for the
needs of new services, and even support for IP, the service type
from which operators reasonably expect to earn a significant proportion
of their revenue in the near future, is poor and does not scale.
Fortunately, recent developments from research in
the area of "open signalling" (or more aptly, open control)
suggests that this problem can be overcome. The use of sophisticated
distributed systems architectures in the network control and management
infrastructure can drastically simplify the design and implementation
of truly multi-service networks. In addition, devolving the control
of switches to off-switch control processors allows the basic
switching functionality of the network to be exploited in innovative
ways, for example as used by Ipsilon's IP switching, or the Columbia
control architecture. The fundamental ability of ATM to perform
high speed switching with fixed-sized units of bandwith can thus
be exploited by new services.
The LEANET offers a unique opportunity to build a
large multiservice network based around a common switched core
network with fast and versatile provisioning of connection services,
and to test this in a realistic context with sufficient user load
processing and communications complexity. The convergence of differing
uses of telecommunications networks gives rise to 'layer' convergence
in management and service provisioning; with the consequence
that the responsibility for set-up, routing, error reporting etc
shift between the control plane and distributed management systems
and the division between these ëlayersí becomes ill
defined. It is clear that to build a complete service, each layer
of the system must work harmoniously with the others. This requires
more than the traditional stack-service based approach and 'Layer
Violation' must be managed and the QoS concepts can be seen as
a way to do this. In general, the LEANET test bed, as a complete
captive network with full access to all ëlayersí,
should provide an ideal context to look well beyond conventional
layering criteria and to allow new full service definitions to
be created; thus providing a knowledge base for future application
development in BT.
The proposed work will range from control to service
up and down the stack, and will use as a basis for its research
a technique developed at the University of Cambridge Computer
Laboratory which enables multiple network control architectures
(CAs), such as ITU standard Q.2931 signalling, TAG switching,
or Ipsilon IP switching to be supported on top of a single network.
New services may be built upon the architecture, and crucially,
virtual networks of any type can be created. UCL Computer Science
will bring their previous experience to bear to attack complexity
and manageability issues associated with IP(v6)/ATM service provision
with RSVP control in its own virtual network, and seek some understanding
of the very different Virtual Circuit World View and the IP World
View of the meaning of multicast; how switch/routers deal with
these different viewpoints is itself a significant research issue
for the programme. UCL CS are also interested in open service
provision, QoS in routers, IP traffic QoS, measurement and estimation
of traffic resource requirements, and end system requirements
for multimedia. UCL EE will be concerned with the quality of
the connectivity management with respect to eg the call / data
connection requests (e.g. connecting to data), (advanced IN type)
personal services and to the availability of status information
and in doing so will move beyond the recent experience gained
in a number of ACTS Projects to develop Quality of the Quality
of Service ie (Qo)2S concepts, in the context of an
ongoing risk management research project for BT; there are particular
issues here arising from the Cambridge virtual networks approach.
UCL EE would seek to define ëperipheryí agent platforms
to link for example advanced personal service generics with the
ënetwork service on demandí concepts of Cambridge
and thereby build on other recent research in EE dealing with
the complexity of mixed technology environments.
As discussed in Section 1, this proposed programme
of research which is detailed in Section 3, presumes a fully operational
LEANET. However it is assumed the the two RA post holders will
need to spend a significant portion of their time working jointly
with BT staff to enable a configuration that will support the
research programme, and subsequently to aid with the management
of LEANET as a multipurpose experimental platform. The proposed
programme builds on current research strengths in the Cambridge
and UCL groups concerned, and the summary demonstrates how individual
research interests in the three groups have been assembled to
compliment and be mutually supportive in the programme of work.
The UCL and Cambridge groups have prior experience of effective
interworking and a methodolgy for technical exchange.
The basic area of work is around the complexity and
manageability of IP(v6)/ATM service provision - we will help evaluate
the results of the network that BT build, with appropriate RSVP
control in its own virtual network, and the QoS support within
the virtual networks. The combination of the skills of UCL and
Cambridge in this line are extremely appropriate: UCL have the
IP/RSVP skills and the network and service management skills,
and Cambridge know how to build networks with guarantees, including
both security and integrity (performance) aspects (see activity
5.2.85.2.8).
High performance networks are moving towards a seamless
integration of switching and routing technologies. There are a
variety of proposed approaches including Ipsilon's flow labelling,
Cisco's tag switching, Toshiba and IBM have looked at other approaches
still. Each involves dynamic creation of state and state table
indexes for a flow (whether on demand, as in Ipsilon's case, or
per route as in Cisco's proposal). Each has scaling properties,
in terms of the amount of state, and the rate of change of state,
as well as in the number of messages and changes to the signalling
and routing protocols in the IP (RSVP) and ATM (Q.2931/Uni 4 etc)
(or other) layers. These scaling properties are dependent on
a number of actual traffic characteristics - e.g. location in
space and time of flows (how long a flow between a source and
a destination appears to last) (see activity activity 5.2.85.2.8).
Recent work on traffic classes and call admission
shows that for some classes, aggregate flows may be admitted with
higher acceptance probability, and then queued together with a
single index for efficiency. The gains here are mainly in the
area of switch/router memory (table sizes) and control messages
rather than actual network utilisation (although there are modest
gains there too).
Multicast means very different things in the Virtual
Circuit world and the IP world. How switch/routers approach this
is interesting, and differs widely (and depends on the underlying
switch facilities to a large extent as well) (see activity 5.2.65.2.6).
ATM and Integrated Services IP provide a variety
of traffic classes. [See ftp://cs.ucl.ac.uk/darpa/rsvp3.ps for
a detailed tutorial on this]. These classes do not define (prescribe)
how a provider decides what percentage of the network each class
is limited to. This is a matter for policy. How much we choose
to allow of CBR, VBR, ABR etc, or Controlled Load, Guaranteed
and Best Effort is a matter of the revenue each class generates,
the demand, the service facilities/limitations etc.
See "Task 2.2Task 2.2Task 2.2", Section
5.1.65.1.65.6 and "Task 2.3Task 2.3Task 2.3", Section
5.1.75.1.75.7.
Web servers are adding facilities for sizing documents,
and including policies and QoS information concerning the retrieval
of a document. [See http://www.cs.ucl.ac.uk/staff/jon/hipparch/hipparch.html
for details of a Project involving UCL working on Http ng and
other aspects of this problem] (see activity 5.2.75.2.7).
In any case, such a facility leads to the possibility
for scheduling flows (retrievals for near media on demand for
example), which can interact with traffic monitoring and so on.
We are interested in open service provision, QoS
in routers, IP traffic QoS, measurement and estimation of traffic
resource requirements, and end system requirements for multimedia
(see activity 5.2.65.2.6).
SDH, ATM and IP all have failure tolerance mechanisms
based in alternate trunk routing, PNNI, and a variety of distributed
dynamic IP routing schemes. Each has its appropriate timescale
and performance.
See "Task 3.1Task 3.1Task 3.1", Section
5.1.85.1.85.8 and "Task 4.1Task 4.1Task 4.1" section5.1.95.1.95.9
Much of the effort in IPv6 (RSVP) and some of the
ATM service definitions are concerned with the provision of high
Quality real time services, with defined/guaranteed QoS features.
The concerns there are principally in the quality of the provided
connection. An equal component for user satisfaction, which interests
EE, is the quality of the connectivity management; i.e. the accuracy,
speed (and availability) with which the service comes on line.
This applies to; call / data connection requests (e.g. connecting
to data), (advanced IN type) personal services and to the availability
of status information.
These aspects are dependent to many aspects of the
system used; network load, processing speed, network scale and
complexity. Proof of a system finally requires that it is tested
in a realistic context with user load, processing and (control)
communications complexity. This context would facilitate developments
across all service points and through all/most layers of the stack.
Thus it would be possible to produce full service definitions
as input for future service product definitions. These service
definitions could be assessed for integrity [the Quality of the
Quality of Service ie (Qo)2S] and implementation risk
frameworks developed (see activitie 5.2.85.2.8).
In the context of a network based information infrastructure,
4 principle roles would be considered. Each of these may require
versatile interactions with the network services in order to provide
consolidated information flows. These roles are; - The user terminal
/ application; This is the point from which requests originate
and the final destination(s) of data flows.
The information source(s); This may be an alternate
role of the user terminal (telephone/videophone) or other sources
ranging from multimedia material (web, vod) to stored textual/audio
messages (call minder, e-mail) - Intermediate / stream processing
services (network computing); services may be constructed by adding
processing to the data flow from information source to user terminal.
This may range from e-mail to audio conversion to in stream application
processing (video mixing, ms-word on demand, etc.). - Information
/ Knowledge brokers;
These provide high level location / number translation
services. Providing capabilities such as; (IN type) number translation,
personalisation of services, brokerage of information sources
/ instream processing, management of mobility, billing etc. Each
of these roles has a part to play in building service network
management requests. For this, each role must interact both with
the network service layer and with each other to agree QoS/performance
requirements for each part of a connection, routing requirements
and so on. Equally, interaction with users / subscribers / information
providers may need to be versatile in order to provide adequate
status/performance /billing/etc. information and to facilitate
high levels of personalisation.
In the context of a network system supporting mobile,
intelligent agents (MIA), it would be natural to define 'periphery'
agent platform to interface to the above roles. For the users
this would provide an interaction context for such technologies
as personal assistance and such like. Equally this context could
contribute to the needs of mobility (service tracking) and aid
users in the provisioning and maintenance of sophisticated, personal,
services (see activities 5.2.65.2.6 and 5.2.75.2.7).
See "Task 5.2Task 5.2" in section 5.1.115.1.11
and "Task 5.4Task 5.4Task 5.1" in section 5.105.1.135.1.13.
The separation between network, service provisioning,
Service management & Network management technologies is disappearing
as the services required to be supported become increasing more
complex. There is, in effect, a convergence in these areas arising
in turn from the convergence between telecommunications, data
networking and the content industries. The future demands on network
provisioning will be to provide a mixture of services with rapid
(re)configuration and high levels of user feed back (with more
complex services, understanding delivered performance becomes
more problematic; and more important for providing user satisfaction).
Current moves to accommodate these emerging network
service and management needs focus around open control platforms
such as those defined in TMN and/or TINA at differing levels.
EE & CS have developed systems for the automated control
and management (VPN provisioning, load balancing etc.)
of ATM - and sometimes SDH - technologies (in ACTS Projects: TRUMPET,
MISA, REFORM, VITAL, possibly WOTAN). These are yielding management
infrastructures which may be deployed to some extent for LEARNET.
Some of these (eg TRUMPET & MISA) are strongly concerned
with QoS based provisioning. The concepts developed in this area
will need to be ameliorated with those in the IP & ATM Switchlets
worlds in order to see the way forward to fully integrated service
provisioning at all levels.
Thus it is seen that the convergence of the differing
uses of telecommunications networks gives rise to 'layer' convergence
in management and service provisioning. Responsibility for set-up,
routing, error reporting and such like shift between control plane
and distributed management systems - with such divisions becoming
blurred. The LEARNET test bed, as a complete captive network with
full access at all layers, should provide an ideal context to
bring together these aspects.
New technologies sit between the requirements of;
standardisation - for open network provisioning - and versatility
- to be able to innovate and support rapidly changing service
requirements. A developing approach to tackling this dilemma has
involved the use of Mobile (intelligent / adaptive) Agents. In
this context, services are built up from co-operating agent units.
The agents are given an environment in which they can interact
both with each other (visiting agents) and with the local environment
(principally the network infrastructure, but also maybe users
personal environment, see above, to form fully integrated, personalised
services). Studies in progress in EE are looking at adding mobile
agent environments to the distributed control systems to be able
to add versatile services for users (see previous section) and
to aid in the increasingly complex network management & maintenance
tasks which exists in mixed technology (and high availability
requirement) environments; this research would be focussed into
PEARL (blobs of java / whatever executing in VM's on top of switchlets-provide
consistent management view of network and solve distributed problems.)
(see activities 5.2.55.2.5, 5.2.85.2.8).
This project aims to build infrastructure to support
the creation, on demand, of virtual networks positioned logically
over a single physical switching backbone. Although not predicated
on the use of any particular switching hardware, a good example
would be the use of Fore Systems ASX 200 switches for which Cambridge
already has a partial implementation of the facilities required
to build networks on demand. The work to be undertaken by Cambridge
will virtualize the resources the switch and present them to a
layer of control which enables multiple control architectures
to simultaneously manage portions of the communications resources.
The switch control will be achieved using an enhanced implementation
of the Ipsilon IP switch control protocol, GSMP, which can be
used to instruct the switch to set up, tear down, and manage ATM
Virtual Paths (VPs) and Virtual Circuits (VCs). GSMP can be used
to control the switch for any of several candidate control architectures,
including Q.2931, Ipsilon IP switching, or any of the proposed
variants on IP switching currently under consideration by the
IETF ION working group. It can also be used to implement radically
new control architectures; Cambridge has developed several such
CAs, one of which was developed under the BT-URI.
Figure
11. Use of Switchlets to virtualise ATM
switch control.
The goal of the Cambridge part of the LEANET project
is to facilitate the dynamic creation of virtual networks managed
by different CAs simultaneously on the same underlying ATM switch
platform. The technique used to achieve this is a concept developed
at Cambridge, which permits the hardware switching resources of
an ATM switch to be safely divided into multiple "switchlets",
each of which can be assigned a subset of the physical switch
resources. Figure 11Figure 1 shows the approach, with an external
implementation of the Prospero switch divider on a workstation
attached to the switch. It exports subsets of the underlying
ATM switching capacity to multiple control architectures, via
the Ariel switchlet interfaces. A second external controller
on a separate physical platform interfaces to one of the switchlets.
A given control architecture (such as ITU-T Q.2931, or IP routeing)
can be assigned a virtual network composed of a set of switchlets;
the virtual network represents a subset of the physical network
resources. Figure 22Figure 2 shows multiple virtual networks overlayed
on a single underlying switched ATM network. Each switchlet appears
to the control architecture which manages it to be a full ATM
switch, and is controlled in the same way as a real switch. A
Switch Divider Controller (under control of the network operator)
is responsible for dividing the resources of each switch between
the switchlets it supports (according to some policy), and it
can dynamically create and destroy switchlets in response to management
commands to create virtual "Networks on Demand" which
support the control archictecture of choice. Although the "networks
on demand" concept has been discussed theoretically, we have
not implemented it, and to do so would require tackling several
major research objectives. The Switch Divider Controller is also
responsible for policing the control actions exercised on the
switch control interface of each of its switchlets, before relaying
them to the physical switch. This ensures that the actions are
valid, legitimate and manipulate only the resources allocated
to that switchlet.
Figure
22. Virtual networks, each controlled
using a different control.
Key areas of interest which Cambridge intends to
pursue include the following:
Below, several areas of research which can be pursued
on LEANET are described in more detail. These are by nature very
open ended and not all can be pursued at the requested level of
resource, as discussued in Section 1. In tasks 6.1 and 6.2 we
provisionaly target the areas for the requested funding. We expect
the other areas to be addressed by other projects. However,
it should be clear that all of these areas of work will benefit
enormously from the LEANET infrastructure.
We will carry out measurements of the available systems
in the network.
Flow aggregation: We will look at the facilities
in the IP and tag layers for aggregating flows into a single table
entry.
Multicast: We will carry out measurement experiments
to ascertain the scaling properties of various switch/router facilities
for many-to-many flows such as those used to support multimedia
conferencing.
Renumbering/Flexibility: We will look (paper study)
at the facilities for dynamic renumbering of the network and end
systems (and groups of latter).
RSVP has interfaces to a policy database to implement
these decisions. We will examine how they can be used, and what
distributed functions exist for installing and maintaining and
checking policies for consistency.
We will look at the various queueing systems implemented
in switch routers (number of priority levels, stochastic systems
such as CBQ and Weighted RED, WFF, etc etc) and compare their
efficiency, and also their suitability in terms of deterministic
behaviour and so on, for billing (billing must be transparent
to the customer - the relationship between their flow behaviour
and its cost should be largely repeatable!).
Study interaction between long term traffic flows
and in-advance knowledge, and how this affects QoS and utilisation.
Study interactions between dynamic routing at various
levels, and manageability and QoS performance of each, and their
sum behaviour.
Study in amelioration between Network & Service
management QoS & configuration and 'open' signalling QoS control.
Concerns, for example in ATM, matching NM QoS per VP with UNI+
VC QoS definitions.
Definition of User & Application level QoS specification
and API to drive signalling level in a 'by use' way. Facilitating
highly personalised network-application usage.
Enabling of User / Peripheral intelligence &
the use of Switchlet based VPs. Define Agent environment for service
provisioning & mobility.
The switchlet concept will be applied to LEANET.
This will take the form of planning switch deployment, control
box deployment and strategies for allowing different control architectures
to control the switchlets. Eventually the Network on Demand service
will take over this role. Due to the limited resources (1 RA,
see below), this task should be viewed as a glue function, enabling
work already in progress to be carried on over a real network.
This is an enabling task which will allow collaborative research
to be pursued.
Bring the Network on Demand architecture up on LEANET.
This will be a realisation of the Network on Demand architecture
from the current URI effort. Although some components will be
available from the URI, this represents a deployment on a real
network. It will require considerable support. Although this
might still be regarded as glue, it is novel glue.
The activities defined for year 1 concern implementation
of basic infrastructure, planning and policy development for higher
level architectures and usage's. Year 2 should focus on some subset
of the possibilities identified in year 1 for implementation and
experimentation.
A continuous process through this should be the incorporation
of ideas and applications from other projects. A final objective
(depending on the state of other grants) may be, for example,
to undertake teaching some of the BTMSc over the system. Such
experiments would provide opportunities for proving both the technology
deployed at each level of the system as well as to validate some
of the performance measures developed.
_____________________________________________________________
END PEARL 1 Document
2-25/4/97-UCL/CAM-(CJT-UCL EE)
_____________________________________________________________