In an effort to support real-time multimedia applications in the Internet2, several Quality of Service (QoS) architectures are being investigated and developed. Distance learning and Virtual Reality, among others, are some of the main test-bed applications for the Internet2 technology.

This paper presents a model, based on QoS, which implements a communication infrastructure for a virtual classroom, where students and teachers, in spite of being geographically distributed, may share a highly interactive environment. Such applications are often characterized by a large number of participants and considerable multicast bandwidth requirements. It is therefore important to devise a transmission model, that while guarantying resources to all participants, is adequate for large scale use. The adopted reservation model, is different from the existing Internet resource reservation protocol, namely RSVP, in that it aggregates reservation information for an entire multicast group in order to avoid the need for registering individual reservations made by each participant. This way Internet routers will maintain the state of resources based on Multicasting Groups, instead of flows as currently used by RSVP. Furthermore, in an attempt to minimize the wasting of unused bandwidth resources reserved for a group communication, the new concept of floating reservations is adopted.

The Internet has defined an Integrated Services model (IntServ) which prioritizes a flow and delivers it within a time frame according to a previously established service agreement (SLA). Under this model, the only way to guaranty on time delivery is through the previous reservation of bandwidth resources to a given traffic flow. A major problem with such an approach, though, is its lack of scalability considering the possibility of having a large number of reservations at a router. At the present, routers form the backbone of the Internet and are mainly required to forward packets at high speed. It would therefore be unwise to overload these devices with reservation information. In order to overcome such a limitation, this work chooses to perform resource reservations on the basis of an entire group communication rather than to each of its individual flows.

As a result, all the flows of one multicast transmission would be aggregated in a unique reservation whose specifications are dimensioned and maintained by the sender.

Since the model was conceived to give support to transmissions where the downstream flows are much bigger than upstream ones (as is the case for distance learning), an optimization is performed on the proposed protocol. The proposed protocol makes upstream group reservation that may be used by group members in a sequential way (i.e. one at a time). Whereas the reservation made for the teacher or coordinator is a permanent one, the one made for the reverse traffic is a floating one and may be shared by all students. Access to the reserved bandwidth is controlled through the use of a token. In a distance learning application for example, a student wishing to participate should first solicit permission (the token) from the teacher or a person coordinating the multicast application. Note that the protocol emulates a simple mechanism similar to that adopted in the classroom. Once the transmitter receives the go ahead, in the form of a token, it then sends to all the multicast routers in the pre-established tree a control message asking them to switch the reservation state from floating to fixed so that the soliciting host (student machine) may use it to talk to the other group members.

A classification mechanism is used within network routers. The reservation for reverse traffic is known as floating since the router may use this resource to pass "best-effort" traffic as long as no multicast member requests it.

Similarly, a forwarding mechanism is defined where IP packet headers are marked to allow a router to differentiate between packets belonging to the reserved multicast bandwidth (ex. audio and video) from those that are best-effort (ex. e-mail and ftp).

Distributed applications such as training and distance learning have been presented like powerful candidates for use in an environment that implements differentiated services. The high levels of interaction between the members and the eminent multicast characteristic of the applications require a specific model that provide guarantee without, meanwhile, overloading the network. Consequently, a resource reservation protocol based on groups, called REMBAM (Reservation Model Based Multicast Group) is presented. To explain its model, a distance learning scenario is used. The main objective here is merely to propose an infra-structure that is necessary to turn feasible delay intolerant real time applications such as distance learning.

One may foresee that large numbers of virtual courses would be made available through the new Internet (Internet 2), giving student and participants more flexibility in terms of new choices of both material and teachers. For example, a student would study mathematics in a virtual course located in London and study French in another located in Paris. Such a scenario requires an architecture which may include:

1. A web site manager from a government education entity to control in real time the quality of such courses.
2. Only the students of these courses (see item a) would have their certification recognized by the government.
3. The lectures would occur in real time to preserve the student-teacher interactions.
4. The number of the students would be restricted.
5. A student may be able to consult , at any time, previous lectures by simply downloading these from a pre-established storage site using multimedia technology such as Video on Demand (VoD).
6. Payment incurred by reservations, transmissions, etc., made will be subject to pre-established service level agreements with information service providers.

The figure bellow shows a typical distance learning scenario.

Qos Specification

To control the reservation, a table is maintained at the routers containing multicast addresses, the required QoS and the type of reservation made (fixed or floating). A special bit and the multicast group address are used to distinguish IP packets belonging to a reserved multicast flow. New floating reservations may be aggregated to existing ones. The admission control mechanism used, is responsible for checking the available bandwidth each time a new reservation is requested by another multicast group. Note that floating capacity may not be allocated to a different group.

Classification

The protocol defines that only group packets that are actually marked may use the reserved bandwidth. The first bit of the field DSCP (Differentiated Services Code Point) of the IP packet is used by REMBAM. Packets marked with bit 1 will be forwarded to a special queue, while those marked with bit 0 will use the best-effort queue.

Reservation

The reservation would be made either as simplex or as full duplex (in one or both directions respectively). When used in the simplex mode, the downstream flow (from sender to receiver) may be fixed and/or floating depending on parameters provided by the sender in the RBRESV message and on number of members that confirmed participation. Upstream reservations are always of the floating type. The idea of creating a floating reservation saves bandwidth and is implemented in the following way:

a) When a member of the group wishes to transmit, (s)he sends a message, requiring the permission to do so;

b) The sender may authorize or put it in a waiting queue, guarantying that only one member may transmit at a time;

c) Permissions may be encoded using cryptographic techniques to protect against their misuse, theft, unauthorized access, etc.;

d) Router queue management algorithms calculate the level of floating reservation that needs to be locked (message RBLOCK) and then forward the real time data on to the newly established reservation receiver-sender (upstream). At this point the floating reservation is converted into a fixed one;

e) Once the transmission is over, the reservation is switched back to the floating status and may share its resources with the best- effort traffic again.