The objective of NRS is to find a practical solution to the problem of allowing users to request network capacity allocations - "reservations" - dynamically, including the ability to make "advance reservations" for sometime in the future. The aim is to pr
ovide a control mechanism for Quality of Service (QoS) guarantees between end-sites. The management of such network reservations is highly decentralised, with direct communication between the end-sites that require the reservations. This model reflects th
e way that end-systems communicate in
ad-hoc virtual communities, e.g. a remote collaboration between research groups that are geographically dispersed. This implies that the system must operate across a multi-domain environment. The following issu
es are being investigated:
- QoS request specification and management for end-users.
- Dynamic requests for capacity from end-users.
- Requests for advance reservations for sometime in the future.
- Micro-management of QoS at edge sites.
- Highly-decentralised, multi-domain, QoS management under local administrative controls.
The NRS project is not looking at router scheduling mechanisms, packet classification techniques, capacity planning
and provisioning or traffic engineering. We use where possible existing mechanisms (such as DIFFSERV) and equipment
and instead our research focus is on the way we manage the reservation state information at edge-sites and (if
required) in the provider networks.
Network sites A and B, located on opposite sides of the world, are connected by a high speed backbone core network. They use this network for transferring large files (or perhaps streaming real-time video). The admins of both sites have configured their
edge routers to mark a certain percentage of inter-site traffic with DIFFSERV EF tags. DIFFSERV aware routers will give priority to these packets. Assuming the core network is over-provisioned (at least with respect to DIFFSERV), the sites can be assur
ed their EF packets will not be dropped when there is congestion. They have a virtual pipe of a guaranteed capacity.
But how do they manage this capacity?
The size of the EF pipe is set to 10 Mbps. Two users at site A both wish to transfer large files to site B. But they are not aware of these other. They both transfer the files at 10 Mbps. The router cannot mark 20 Mbps of traffic as EF because this wo
uld violate the agreement with site B. Therefore half the traffic does not get marked. The users do not get any guarantee of how much bandwidth they will receive, or even that they will receive half each.
How can we avoid this situation? The admin at site A could chose not to enable EF marking automatically. Instead, users would be required to contact him and make a request to use the EF capacity. They would send him a specification of the flow and the
amount of bandwidth they require and he would check that the bandwidth was available. He would then telephone his counterpart at site B and confirm that the bandwidth is available at the other end also. Finally he would configure the router to identify
packets from this flow and mark them as EF.
This solution does not scale to large numbers of users, and does not allow bandwidth to be easily reserved ahead of time. So, we automate it. The job of taking bookings, checking bandwidth availability at both sites, and configuring the router at the ap
propriate time is done by NRS.
NRS is a project of the Networks Research Group in the Computer Science Department in collaboration with the High Energy Physics Group
at UCL.
The following people have all contributed to the NRS project:
NRS is funded as part of the GRS project by EPSRC.
