A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
BTI
Project Number:
AC362
Project Title:
BTI
Deliverable Type*:
P
CEC Deliverable Number:
A0362/BTI/WP3/DS/R/P/301/B1
Contractual Date of Delivery to the CEC:
30.12.1999
Actual Date of Delivery to the CEC:
30.12.1999
Title of Deliverable:
Conclusions from Evaluation of all Applications running on
the Network
Work package contributing to the Deliverable:
WP30
Nature of the Deliverable:
R
Authors:
A. Azcorra (UC3M), D. Fernández, A. B. García (UPM),
Z. Papir, P. Pacyna, J. Gozdecki (UKR),
I. Mcay (CCIR)
E. Bertelsen (UNI-C),
J. Carapinha, J. Vieira (PTIn),
Abstract:
This deliverable contains a summary specification of the work needed to port the applications to work over IPv6
and RSVP. It also describes the development and main characteristics of the IPv6, MARS and RSVP over ATM
protocol stack that has been developed for Windows NT 4.0.
The intention of this deliverable is to serve as guidelines for other application developers intending to port their
application to an IPv6 plus RSVP environment.
Keyword List: RSVP, IPv6, ATM, multicast, QoS aware Applications,
* Type: P - Public, R - Restricted, L - Limited, I - Internal
**Nature: P - Prototype, R - Report, S - Specification, T - Tool, O - Other
Page 1
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
Executive Summary
This deliverable contains a summary of the developments and experiments carried out inside WP3 during
the second year of BTI project. It includes a summary specification of the work needed to port the
applications to run over IPv6 and RSVP. It also describes the development and main characteristics of the
IPv6, MARS and RSVP over ATM protocol stack that has been developed for Windows NT 4.0 to support
the applications running over this operating system.
The intention of this deliverable is to summarise the work done and to serve as guidelines for other
application developers intending to port their application to an IPv6 plus RSVP environment.
The deliverable is organised as follows. The first section describes the IPv6, MARS and RSVP integrated
protocol stack developed by the Technical University of Madrid (UPM) under Windows NT. It describes
its main characteristics, its internal organisation, some implementation details and concludes summarising
the problems faced during its development.
The second section describes the development and porting of the VideoServer application done by The
University of Mining and Metallurgy of Krakov (UKR). It summarises the main characteristics of the
application, how it was modified to include IP6, multicast and RSVP support, how the user of the
application controls the QoS, and some conclusions and guidelines.
The third section describes the porting of VIC and RAT applications to support IPv6 and RSVP under
Windows NT operating system carried out by the Centre for Communication Interface Research (CCIR) of
the University of Edinburgh.
The fourth section, describes the experiments carried out by the Danish Computer Centre for Research and
Education (UNI-C) using and porting MBONE applications to IPv6 and RSVP over several UNIX
platforms.
Finally, the fifth section describes the porting of Data Conference applications carried out by PT Inovação
(PTIn, old CET) and the Technical University of Madrid (UPM). This section shows the reservation model
used for Data Applications and reports about the details and problem found during the migration.
Page 2
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
Contents List
1. IPV6, MARS AND RSVP PROTOCOL STACK FOR WINDOWS NT 4.0
5
1.1.
5
IPv6 over ATM driver
1.2.
RSVP daemon
1.2.1.
Migration to Windows NT
1.2.2.
Adaptation to winsock2 architecture
1.2.3.
Interfaces with IPv6 stack: routing and I/O
1.2.4.
Traffic Control Interface
7
7
8
8
9
1.3.
9
Conclusions
2. PORTING VIDEOSERVER APPLICATION OVER IPV6 AND RSVP
11
2.1.
The Server
12
2.2.
Adaptation to IPv6
13
2.3.
Adaptation to RSVP
13
2.4.
User control of the QoS
15
2.5.
Others
15
2.6.
Conclusions
16
3. PORTING VIDEOCONFERENCE APPLICATION OVER IPV6 AND RSVP IN
WINDOWS NT ENVIRONMENT
17
3.1.
Adaptation to IPv6
17
3.2.
Adaptation to RSVP
17
3.3.
Conclusions
18
4. PORTING VIDEOCONFERENCE APPLICATION OVER IPV6 AND RSVP IN
UNIX ENVIRONMENT
19
4.1.
The MBone applications
19
4.2.
Adaptation to IPv6
4.2.1.
The IPv6 environment used
4.2.2.
Adaptation of the applications
19
19
20
4.3.
21
Adaptation to RSVP
Page 3
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
4.4.
Conclusions
21
5. PORTING DATA APPLICATION OVER IPV6 AND RSVP
23
5.1.
Adaptation to IPv6
5.1.1.
Server Adaptation
5.1.2.
Client Adaptation
24
24
25
5.2.
Adaptation to RSVP
5.2.1.
Reservation Model
5.2.2.
Server Adaptation
5.2.3.
Client Adaptation
25
25
25
26
5.3.
26
Conclusions
6. REFERENCES
28
Page 4
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
1. IPv6, MARS and RSVP protocol stack for Windows NT 4.0
Due to the unavailability, either in the market or in the research area, of a protocol stack solution including
all the functionally required for the BTI project, UPM effort in WG3 was reallocated to develop an
integrated protocol stack named PATAM (IPv6 over ATm Adaptation Module with RSVP support).
PATAM is a Winsock2 compatible protocol stack running on Windows NT, the operating system chosen
by BTI application developers and trial organisations.
PATAM includes an IPv6 stack able to run over Ethernet and ATM networks with multicast support, and
an RSVP over IPv6 implementation with traffic control support over ATM interfaces. Access to all
PATAM services is made through standard winsock2 programming interfaces.
In particular, PATAM implements IPv6 over ATM support according to [RFC2491] ("IPv6 over NBMA
networks") and [RFC 2492] ("IPv6 over ATM networks"), including IPv6 multicast support by means of
MARS client functionality according to RFC2022] ("Support for Multicast over ATM networks"). It is
based on a modified version of Microsoft Research's IPv6 implementation for Windows NT [MSRIPv6]
(which only supports Ethernet interfaces) with the addition of a completely new IPv6 over ATM driver
developed by UPM. MARS client functionality has been based on NIST's MARS implementation [MARSNIST] for LINUX operating system.
PATAM includes also RSVP for IPv6
over ATM support according to IETF
Internet Integrated Services model
described in [RFC2205] [RFC2210], WinSock 2 API
[RFC2379], [RFC2380], [RFC2381]
and [RFC 2382]. It is based on the
Winsock2
well-known
ISI's
RSVP Transport SPI
implementation for UNIX operating
system [RSVPD], which has been
migrated to Windows NT and adapted
to offer a winsock2 interface and
interact with MSR's IPv6 stack.
QoS aware Applications
Winsock2.dll
RSVP
MSR IPv6
The whole stack integrates under the
IPv4
Winsock2
based
networking
LAN
Tunnels
architecture of Windows NT. QoS
aware applications use the standard
ATM NIC Drivers
API [WS2-API][WS2-Annex] to access
either IPv6 or RSVP services offered
by the stack. Figure 1 depicts the
Figure 1: Protocol Stack Architecture
general architecture of PATAM
integrated stack. The next subsections describe with more detail the two main parts of the protocol stack:
the IPv6 over ATM driver (PATAM) and the RSVP protocol daemon.
PATAM
1.1.
IPv6 over ATM driver
Figure 2 shows the detailed architecture of the IPv6 over ATM driver, including its relation with other
modules of the integrated stack. PATAM is a user-mode multithreaded driver that implements all the
necessary functions to carry IPv6 packets over ATM networks using dynamic circuits (SVCs) and with full
multicast support. The driver is made of several components:
Page 5
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
MSR IPv6 Stack
PATAM
RSVP
daemon
Traffic
Control
Module
IPv6 Access (IPAM)
Packet Forwarding
Flows
Database
MARS
Client
Classifier
Receiver
Scheduler
ATM Access Module (ATAM)
FORE ATM SP
Figure 2: IPv6 over ATM driver Architecture

Flows Database. This module manages all the information about the Best Effort (BE) and Controled
Load (CL) IPv6 flows maintained by the driver. Each time a new IP flow is created, either unicast or
multicast; BE or CL, a new entry in the Flows Database is created, storing all the information
necessary to classify and schedule the sending of packets belonging to that flow.

IPv6 Access Module (IPAM). This module manages the communications with the IPv6 stack. Each
time an IPv6 packet is received through any of the ATM circuits, IPAM passes it to the IPv6 stack; and
each time the IPv6 stack has a packet directed to the ATM interface, it is received by IPAM, that
delivers it to the classifier and scheduler modules.
One of the most important design decisions was
to develop PATAM as a user-mode driver, that
is, a driver running outside the kernel of the
operating system. That decision was taken due
to the fact that the development of a real kernelmode driver is an extremely difficult and timeconsuming task that was out of the scope of the
project.
Applications
USER
Winsock2
KERNEL
In order to communicate the IPv6 stack (which
is a kernel-mode device driver) with PATAM, a
proxy-driver [Gallen97] was used. Figure 3
shows the detailed architecture used in IPAM
module.
PATAM
MSR IPv6
FORE
ATM SP
ATM
Proxy Driver
The IPv6 stack was modified to include a new
Figure 3: IPAM Detailed Architecture
module (atm.c) that emulates an ATM
interface. When the IPv6 stack sends a packet
through this ATM interface, a call is made to the proxy driver, which redirects the packet out of the
kernel to PATAM driver. In the same way, when an IP packet arrives to PATAM through an ATM
circuit, an internal event is signalled, making the ATM module to take the packet form PATAM by
means of a call through the proxy driver.
Page 6
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network

Packet Forwarding Module. This module is in charge of sending and receiving IPv6 packets to and
from ATM network. It includes all the functions needed to classify IPv6 packets according to the
different flows in the database and schedule their transmission.

ATM Access Module (ATAM). This module manages the ATM circuits associated with IPv6 flows. It
is in charge of creating and releasing SVCs, adding or deleting leafs to multipoint circuits and, in
general, reporting other modules about any event related to ATM circuits. It accesses ATM network
services using the standard winsock2 API defined in [WS2-Annex] for ATM. This interface allows the
creation of UBR and CBR point-to-point and multipoint circuits. By now, no support for ABR is
available.
PATAM has been tested with ForerunnerLE ATM cards. As it uses a standard API to access ATM
services, there should be no problem using it with other ATM cards. However, during the development
and testing of PATAM over different ATM networks, a lot of interoperability problems were detected
and reported, some of them due to bugs or oddities in NIC drivers and some other due to
incompatibilities between switches and cards. Due to these problems, the tuning of ATM parameters
used in this module has required a big effort.

MARS Client Module. It implements MARS Client functionality according to [RFC 2022]. All
requests to send and receive to or from IPv6 multicast addresses and all the communications with the
MARS server of the IP LIS are managed by this module. As mentioned, this module was developed
starting from a public LINUX implementation [MARS-NIST] of a MARS client for IPv6. This
implementation was modified to support IPv6 and later migrated to Windows NT and adapted to work
over PATAM architecture.

Traffic Control Module. It manages the communications with the RSVP daemon for the creation and
release of Controlled Load flows and their correspondent CBR ATM multipoint circuits. It is described
with more detailed below.
1.2.
RSVP daemon
The RSVP functionality developed by UPM for BTI project includes a complete RSVP engine according to
current standards [RFC2205] [RFC2210]. The main features are:




Standard Winsock2 API according to Winsock2 Protocol Specific annex 10.
IPv6 support (no IPv4 support is provided).
Support for both Ethernet and ATM interfaces.
Interaction with PATAM driver to offer actual Traffic Control implementation over ATM
subnetworks, supporting styles FF and SE, and IntServ's Controlled Load reservations.
 Host (not router) implementation.
 Native IPv6 encapsulation.
1.2.1. Migration to Windows NT
To develop the RSVP engine (or daemon) it was decided to start from the well-known implementation of
ISI (Information Sciences Institute, University of Southern California), which works on UNIX platforms.
This daemon has been migrated to Windows NT (with the initial help of UNI-C) and completed in order to
provide actual Traffic control support for ATM subnetworks.
Figure 4 shows the module architecture used in PATAM to support RSVP functionality. The main block is
the ISI's RSVP daemon, migrated from UNIX to Windows NT and adapted to work under winsock2
Page 7
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
architecture. It was also modified to interact with MSR IPv6 stack's. The main tasks carried out in the
migration area were:




The development of an RSVP API Library, to convert from ISI's native RAPI interface to winsock2
RSVP API.
The implementation of an ATM
Traffic Control Module in RSVP
QoS aware Applications
daemon to interact with the Traffic
Winsock2
Control module of the PATAM driver.
RSVP API library
The modification of MSR's IPv6 stack
Internal message
to create a new low-level API to allow
based API
the sending and reception of RSVP
RSVP daemon
packets over native IPv6 (raw sockets
(rsvpd)
were not available in IPv6 stack), and
to access interface and routing
Adaptation module
information.
Traffic
The migration of the core engine
Control
in
itself, adapting it to the WindowsMSR-IPv6
ATM module
specific
asynchronous
event
notification.
Figure 4: RSVP Architecture in PATAM
1.2.2. Adaptation to winsock2 architecture
To offer the standard Winsock2 RSVP API to applications a standard Service Provider (SP) Library has
been developed, together with the necessary installation tools which register the RSVP Service Provider as
a standard Winsock2 provider.
In order to communicate the SP library (dynamically linked from the application) with the RSVP daemon
an internal interface must be used. It has been decided to perform this communication through a TCP/IPv4
socket, maintaining as much as possible the same protocol that the original ISI’s implementation used for
the same purpose (over a UNIX socket). This reuse of the internal protocol of ISI reduces the need of
modifying internal code of the RSVP daemon, and also the probability of introducing new errors into it. On
the other hand, it forces some deviations respect the Winsock2 standard API, which have been properly
documented.
1.2.3. Interfaces with IPv6 stack: routing and I/O
An RSVP module has to access IP functionality at a lower level than a standard application. Regarding
pure input/output (I/O), at least raw IPv6 access must be provided (unless UDP encapsulation is to be used,
which is something probably not included in future specifications). But there is also necessary for RSVP to
know what interfaces the system has, on which interface a PATH message arrives or through which set of
interfaces a multicast packet should be forwarded according to the routing information used by IP. All this
makes it necessary to provide RSVP with a lower level IPv6 interface than usual applications.
Since standard IPv6 Winsock2 interface does not offer the low level features that RSVP needs, a more
advanced internal standard interface to IPv6 has been used: TDI (Transport Driver Interface). Also, the
MSR’s IPv6 stack has been modified to offer the required functionality. The TDI calls have been
encapsulated to offer to the core processing the higher level interfaces it already used:
 I/O: A System Independent Interface to Network and Transport Layers is provided.
 Routing: The daemon already used a generic Routing Support Interface that also has been maintained.
Page 8
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
1.2.4. Traffic Control Interface
ISI introduces a Link Layer Dependent Adaptation Layer (LLDAL) between core RSVP processing and the
actual TC (the latter may present, for example, the TC interface specified in RFC 2205), offering a higher
level interface to TC (LLDAL interface). It also provides a LLDAL and an (almost) empty TC
implementation suitable for Ethernet interfaces.
In BTI the LLDAL interface has been maintained, and a new ATM-specific LLDAL (pertaining to the
daemon) and TC (actually implemented within PATAM) have been developed. In the daemon side, a TC
stub has been created to communicate with the TC module of PATAM (through an UDP/IPv4 socket). This
TC stub offers to the ATM LLDAL the interface of the TC of PATAM, which is a simplified and adapted
to ATM version of the TC interface specified in RFC 2205. This simplified interface can be summarised as
follows:
 Daemon (actually, LLDAL) may ask the opening of a multipoint QoS circuit with one leaf (i.e. Next
Hop) or the adding of a leaf to an existing circuit when new reservations must be placed. It also may
ask the closing of specific leafs or circuits when tearing reservations down.
 PATAM may notify the closing of leafs/circuits to the daemon.
Figure 5 summarises the modules involved in the TC for the two types of interfaces supported. BTI work
has been focused on the remarked modules.
RSVP
daemon
PATAM
Core RSVP Processing
LLDAL interface
Internal TC
interfaces
LLDAL Eth
Dummy
TC
TC
module
LLDAL ATM
ATM TC
Stub
(Open/close
circuits/leafs)
UDP/IPv4
Figure 5: Traffic Control Architecture in PATAM
1.3.
Conclusions
Although the timeframe for the development and integration of the protocol stack was very tight (in fact,
the decision to go for this solution was taken at the beginning of 1999, with few months left for this
complex job), the big effort dedicated to the task concluded with a successfully running solution. That
solution fulfilled the requirements imposed by BTI network scenario and applications running on Windows
NT (videoserver, videoconference and data applications), and made possible the experimentation with the
whole BTI system during usability testing phase.
The effort invested to carry out the protocol stack development was very high. In fact, it was much higher
than foreseen, due to several reasons:

Instabilities of ATM drivers. This was one of the main problems we faced during development,
integration and testing phase. The access to ATM services through winsock2 API was found to be
buggy, not very well documented and very frequently was the cause of computer crashes ("NT blue
screens"). Several bugs were reported to the manufacturer, but unfortunately, no solution arrived
before the end of the project.
Page 9
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network

ATM Interoperability problems. During the testing phase, a lot of effort was invested to tune all ATM
parameters (Information Elements) used in ATM circuits to get a combination of values able to work
over all BTI scenarios. It was noted that, depending on the destination of a call (a router, a PC, etc) and
the type of ATM switches being passed, some combination of parameters work or failed. Any time a
new version of ATM drivers was tested or anytime a new network scenario (with, for example,
switches from other manufacturers) was used, it was necessary to repeat all the tuning work.
The use of ATM protocol analyzers was found very useful to isolate and solve these kind of problems.
However, in some situations, some inconsistencies were detected between the two protocol analyzers
used at UPM, complicating even more the solution of the problems.

Developments inside Windows NT Kernel. Although the decision to develop a user-mode driver
minimized the developments inside Windows NT kernel, the modifications needed were still very
important (2.200 new lines added to the IPv6 protocol stack), and required a lot of effort due to the
difficult conditions in which device drivers are developed.

Advance APIs in IPv6 implementation. The lack or partial support in the IPv6 stack of the advanced
APIs needed to integrate RSVP (for example, APIs to send and receive raw packets with interface
knowledge or to know the number and addresses of IPv6 interfaces in the system) complicated the
development, as we had to modify ourselves the IPv6 stack to add some of these interfaces.

State of the art environment. Apart of the technologies mentioned above, most of other components
being used (router, access network, IPv6 and RSVP support in servers, etc) showed problems and
instabilities. For example, some bugs were discovered in IPv6 support in ISI's RSVP daemon; or some
problems were detected in multicast support of IPv6 stack. Besides, software versions of some of the
components changed during the project; or, in other cases, it was necessary to test several different
versions to select the best for BTI project environment.
In summary, most of the problems found were due to the use of state-of-the-art implementations of the
technologies being integrated in BTI project. Even some technologies we though at the beginning that
should be stable enough (like the use of SVCs in ATM networks) were found to be unstable.
Finally, we would like to mention some interesting lines to continue the work described here:

ABR support. Due to the lack of ABR support in the winsock2 ATM API used in the project, the
implementation of Controlled Load services over ABR ATM circuits could not be finish. We think this
is a very interesting and promising line of continuation of the work being described here.

Integrated QoS interface. As mentioned, the protocol stack provides two different interfaces: one is
used to access IPv6 stack to send and receive data, and the other to access RSVP services to make
reservations. Inside winsock2 community, a lot of effort was invested to integrate both interfaces, in
order to offer applications an integrated API with QoS support [WS2-GQOS]. We think that the use of
an integrated API would simplify greatly the adaptation of applications.
Page 10
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
2. Porting VideoServer Application over IPv6 and RSVP
Video Retrieval Application implements a concept of a digital video library - a storage and management
system for digitally encoded video, capable of synchronous streaming the video content towards the users
on request.
Unique features of the Video Retrieval Application include the ability to process compound queries
submitted by users in order to find a particular film, allow the users to browse the film database, request
additional information on a specific topic, and finally submit a request to start video streaming. During the
streaming the application allows the user to perform trick-mode functions typical of a VCR.
Figure 6: Video Retrieval Applicaiton - user interface
The application consists of two parts: the server and the client. The server offers two interfaces: user
interface consisting of four web-based pages facilitating server browsing (see Figure 6), and the content
manager interface which consists of five pages to enable efficient content management (Figure 7).
The application is able to support several simultaneous point-to-multipoint sessions and to control the QoS,
i.e. to maintain quality of the video during the network transmission.
Figure 7: Video Retrieval Applicaiton - content manager interface
The Video Retrieval Application uses IPv6 as a network layer protocol and takes advantage of IPv6
multicast. Network resources are controlled with the RSVP protocol. The resources are reserved in
Page 11
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
response to requests generated automatically by the application on behalf of a user, or manually by the user
himself.
As such Video Retrieval Application constitutes a service that may be used in many fields, including
distant-learning, home-shopping and entertainment.
The application proved to be a valuable tool to validate the advanced capabilities of the network developed
within the BTI Project. In the context of network performance testing its unique features are closely related
to the generic features of the video-on-demand service, like:
 the requirement for high bitrates to carry video bitstream,
 the requirement for low transmission delay in order to achieve high level of interactivity, and
 the requirement for low packet jitter because of high sensitivity of the video to network congestion,
caused by the requirement of a synchronous playback.
We believe that the network that is able to meet the above requirements is likely to be able to support also
other, less demanding applications.
This chapter briefly summarizes major findings and conclusions drawn after the development of the Video
Retrieval Application. The details on the implementation can be found in Milestone 3.2.3 “ Specification
and implementation of the server”.
2.1.
The Server
The server consists of several software components, which are briefly described below.
The video server enables storage and streaming of digital video films towards the user or groups of users
on request. It works in pair with the application server.
The application server provides a consistent user interface for service users and a content manager
interface for content management i.e. for the administrator of the service. The application server performs
session control. It also interfaces the video server: initiates certain actions on the video server and gets the
status of the video server. The application server is implemented as a web server (Apache), equipped with a
set of scripts that perform service-specific actions.
The data acquisition module provides means to specify object of interest by a user and retrieves a detailed
information about the object from the database. The results of a query are then further processed and
presented to the user with help of the application server.
The database stores information on available video titles, and their technical properties.
The information is organised in a SQL database running on a RDBMS platform (Postgres). It includes
information that may be interesting to the user and some meta-data that maintains the integrity of the whole
server installation.
The video server, the application server, acquisition module and the database reside and execute on a
common hardware platform (Sun Enterprise) in the Sun Solaris 2.5.1 environment. The operating system
has some specific system-level software installed. The most important are: Solaris IPv6 2.5 and ISI RSVP
daemon 4.2a4 modified to support IPv6. This specific system-level software is used by the applicationlevel module, developed by UKR to take advantage of the advanced network capabilities. The module is
responsible for: resource reservation (rsvp signalling), IPv6 communication between the application client
and the server, announcement and management of multicast sessions in the application (Figure 8). Software
configuration of the Video Retrieval Application and the location of the software components with
reference to the protocol stack is presented on Figure 8.
Page 12
Hardware
platform
Operating
system
Preinstalled
software
Application
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
Video
database
Video
Application
RSVP
Sender
Database
system
Web
server
Video
Server
RSVP
deamon
Postgress
Apache
ver. 1.3
OVS
ver. 3.0.4
ISI RSVP
ver. 6.4
RSVP
software
PiM-SM
software
ver. 4.2a4
Solaris 2.5.1 with
IPv6 , ver 5.3
ARP,
MARS
and
NHRP
server
TBC 2000
kernel
Sun E250
TBC 2000
(Eurydyka)
Application server
(video sender)
OVS
player
RSVP
receiver
Router
plug in
ver. 3.0.5
Web browser
IPv6 and
router
specific
software
RSVP
deamon
Based on ISI RSVP
Microsoft Internet
Explorer
ver. 4.0
Windows NT with MSRIP6
and IPv6/ATM driver
PC with ATM25 and Ethernet
network interfaces
Application client
(video receiver)
Figure 8: Software configuration of the Video Retrieval Application
2.2.
Adaptation to IPv6
The application is capable to support up to ten simultaneous point-to-multipoint video sessions. The pointto-multipoint communication is implemented using IPv6 multicast. Session management functions of the
server, are responsible for allocating IP sessions. Each session is capable to carry one video flow. The
‘session’ is treated as a triple of the form: (dest. addr, dest. port, proto). All sessions use ff0e:10::10:10
multicast address and are differentiated by the port numbers. The transport protocol is UDP.
The clients perform explicit join multicast session when they want to connect a session, and perform
explicit session quit in order to disconnect from a session. The list of ongoing (running) sessions is known
because it is multicasted over a special, well known multicast address (ff0e:10::10:1) used exclusively for
the purpose of session announcement.
During the development and migration of the Video Retrieval Application to IPv6 there were many
problems, but these were mainly resulting from the incompleteness of the available implementations of the
protocols (IPv6/RSVP) rather than from conceptual problems of misunderstanding or misinterpretation of
the new features of these protocols. We believe that these shortcomings will be eliminated soon by the
protocol implementers, and as such are out of scope of this document.
One issue that was encountered with respect to IPv6 was the need, and initial difficulty, to handle several
types of IPv6 addresses: globally-aggregable unicast addresses, link-local addresses and site-local
addresses, and a slightly different address management rules than the rules that apply in typical IPv4
addressing. The major difference results from the fact that IPv6 addresses are dynamically assigned (via
neighbour discovery protocol) rather then statically configured into the operating system.
A conclusion from this may be that the address auto-configuration feature, though very beneficial from the
user’s point of view, may cause some problems for the developers of IPv6 enabled network applications.
2.3.
Adaptation to RSVP
The approach incorporated in the application follows the Integrated Services model as defined by IETF.
Resource Reservation Protocol (RSVP) is used in the application to exploit the Quality of Service (QoS)
capability of the network at the IP layer. The application implements procedures for Controlled-Load
service.
The service model assumes a single source of video traffic (video server) and numerous video clients that
are able to connect to the server, browse the database, receive digital video content and render it on the
terminal.
Page 13
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
Usage of the application involves two phases of activity: content selection phase and video streaming
phase. The two phases significantly differ in the type and volume of information that is exchanged between
the client and the server.
During the content selection phase the user exhibits much activity by submitting multiple queries to the
database. It involves two-way, transaction-oriented communication with an abruptly changing demand for
resources. Resulting downstream traffic, towards the user, is bursty. The video streaming phase produces
very low traffic in the upstream direction (towards the server), which results mainly from occasional
invocation of trick-mode functions. At the same time high volume of delay-sensitive video traffic is sent
downstream. The nature of communication in the Video Retrieval Application is such, that it is reasonable
to apply different resource management rules for the two phases.
One option for the content selection phase is to treat the resulting traffic as best effort. Alternatively, the
application may reserve a pre-defined amount of bandwidth, assuming that the user will use the bandwidth
by means of active human-server interaction. The decision about how to treat the traffic during content
selection phase will depend on the implementation details, including type and volume of information
produced in response to a single query. In Video Retrieval Application the best-effort approach was chosen,
assuming that the duration of the content selection phase is short when compared to the video streaming
phase. This approach also avoids an additional burden of resource management.
For the video streaming phase, there is no doubt that video flow should be subject to resource reservation.
This is due to a relatively high bandwidth requirement of video traffic and a bad effect the congestion has
on video quality (discontinuities, glitches). The most appropriate reservation style for video flow is Fixed
Filter (FF) with simplex reservation, i.e. from the server to the clients.
Two software modules: one for the application server and one for the application client perform resource
reservation functions by the application (Figure 9).
Application server (SUN)
Proxy
client
HTTP Protocol
(Ipv4 unicast)
Sess. Sig.
(Ipv4 unicast)
Video player
plug-in
Session announcement
and management
(Ipv6 multicast, best-effort)
Video
(Ipv4 unicast)
NIC card
Proxy
server
Sess. Sig.
(Ipv4 unicast)
WWW
Server
Video flow
(IPv6 multicast with RSVP)
Video
(Ipv4 unicast)
NIC card
Oracle
Video
Server
Application client (PC)
Internet
Explorer
4.0
Figure 9: IPv6 and RSVP in the Video Retrieval Service
On the server, RSVP functions are performed by the proxy_server module (rsvp_sender executable
programme). It is launched whenever a user makes a choice and initiates video content streaming. The
proxy client (rsvp_receiver.exe) module is launched automatically on the users' machine when the user
starts the client part of the Video Retrieval Service. The two modules communicate, make a reservation and
participate in forwarding of video flow from the server to the client.
The two modules (RSVP_sender and RSVP_receiver) use Fixed Filter reservation style. Encapsulation of
the RSVP messages straight into IP datagrams (raw encapsulation) ensures that the proposed solution
follows the RFC standards.
Page 14
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
2.4.
User control of the QoS
The server works as a video content repository and the application server. Each film available for the
application users has associated its own ‘film label’. The label is implemented as a record in the database.
The record is called a ‘film label’ because it contains all parameters of a film. The parameters include
information, which is interesting/useful to the user, and some technical parameters used internally by the
application. QoS information contained in the film label is the Tspec.
The administrator of the server (via the content manager interface) sets default values for these parameters
for each film, when the film is uploaded to the server. The parameters are derived from the prior MPEG
encoding process and set such, that enough resources are reserved when a user requests that film at default
(high) quality.
The application server retrieves the TSpec information from the database when a user’s request for a film
arrives at the server. TSpec information is used to generate an RSVP PATH message that is then sent down
to the user’s PC terminal. By default, the PC terminal accepts the proposed reservation parameters and
responds with a RSVP RESERVE message. This approach ensures that the [inexperienced] user is offered
with the video content at satisfactory QoS.
Alternatively, the user may select a “TSpec manual” operation mode, in which he will have the possibility
to accept or change the arriving default and trace the RSVP reservation progress. These parameters are then
sent to the application server in a RSVP RESERVE message.
An important, but complex problem, is the selection of the traffic specification parameters for the
reservation (Flowspec), so that to meet the desired target visual quality of a movie at a user terminal - so
called subjective visual quality. This is mainly because there are only rough guidelines on how to do that. It
is well known that in order to achieve high quality of video, the reservation parameters should correspond
to the parameters that were used during the video encoding process providing that no additional traffic
shaping is performed in the application. It is also hard to derive how should these settings be altered in
order to achieve graceful degradation of subjective video quality. This is because there is no analytical
formula expressing the subjective quality as a function of [a set of] resource reservation parameters. Should
such a formula exist, it would have to account for properties of the video content, QoS service type and the
properties of the transmission channel ( e.g. PDU size). The question of the impact of the QoS parameters
settings on MPEG encoded video is a well-known problem, but still an open issue.
Selection of too low Flowspec parameters for the transmission will produce excess traffic, that may be
discarded during congestion periods. As stated above, this will impact the visual quality of the video but
under specific conditions may also impact the in-band session signaling of the application. For this reason,
it is adviceable to implement session management as a separate bi-directional flow.
2.5.
Others
One of the key concepts of the Project was to use the existing software components (possibly off-the-shelf
products) as building blocks to develop advanced and useful applications. This reusability indeed helped to
avoid developing applications from a scratch and enabled construction of advanced software in a
reasonable time span at a lower cost.
However the incorporation of the third-party software into the application was not seamless. Conclusions
from this approach were drawn, and are listed below as a set of hopefully useful hints for other developers
planning to try similar approach. Here they are:
 Decide on the hardware platform and the operating system in which the application will run.
This should be done after a very elaborate study of the features and limitations of the hardware and
software platform and third-party software components that will be used.
 Verify the dependencies of the application on third-party software components.
 Study carefully the features listed in the third-party software specification. Study their descriptions and
verify if your understanding and expectations match the description.
Page 15
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
 Apply limited trust in third party software, in particular when the software is provided without the
source code and there are no means to introduce adaptations.
 Verify usability of the features: check experimentally whether fully implemented and check their
performance. Try it in the target network environment or, if not possible, try to mimic the real network
conditions in a local lab.
 If the software comes in source, check the quality of the code and check if you have the tools in case
you need to introduce alterations.
 If the software comes in binary form only, verify the interfaces it provides (API) to control the
software, check the level of control, e.g. response time, reporting of the status information, etc.
 Verify the level of support the third party software vendor can provide in case of any difficulties.
 Try to determine in much advance potential problems with incorporating the third-party software.
Evaluate how these may affect the design of the application and consider alternative solutions or
workarounds.
2.6.
Conclusions
The objective of WP 3.2 was to develop a stable and useful Video Retrieval Service using publically
available implementations of network protocols.
However, the development of such an advanced service, employing video as a primary means of
information exchange in an advanced BTI network exhibited much difficulty. During the development
state-of-the-art protocol implementations were used. Among them:




pre-release implementation of IPv6 for Solaris,
pre-release implementation of Microsoft Research IPv6 for WinNT,
experimental implementation of ISI RSVP for Solaris,
experimental RSVP implementation for Win’NT ported for the purpose of BTI by DIT-UPM from ISI
RSVP,
 IPv6-to-ATM adaptation driver (PATAM) developed for the purpose of BTI by DIT-UPM for WinNT.
In this context, UKR is proud to say that the objective of WP 3.2 was achieved.
Page 16
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
3. Porting VideoConference Application over IPv6 and RSVP in
Windows NT Environment
3.1.
Adaptation to IPv6
The Multicast conferencing software packages ‘VIC’ (‘videoconferencing’) and ‘RAT’ (‘Robust Audio
Tool’) have been adapted to have IPv6 functionality, using some degree of the IPv6 code already available
(but non-functional) in each. The source code for RAT version 4.0.0 was acquired from UCL and the IPv6
functions made functional as many networking API calls had to be converted from UNIX-specific to
Winsock-specific. In addition, much of the Winsock-specific code that did exist did not work and required
modification to work with the IPv6 library and header files from MSR (Microsoft Research). The RAT
source code at UCL features a new separation of the TCP/IP network communication code from the Tcl/Tk
(and C language) interface code – using a separately compiled common library.
The VIC source code (version 2.8ucl4) was also acquired from UCL. This version differs from the RAT
codebase in that the networking code (an older version than that appearing in RAT) and the interface code
are tightly coupled with one another, with no working IPv6 code either (only a few Unix-specific
functions). In general, the separately defined Win32 and Winsock specific sections in the RAT and VIC
source code could not be compiled and needed a great deal of work to work with NT, Winsock 2 and the
MSR IPv6 protocol stack.
There were very few IPv6-specific issues requiring changes to the RAT and VIC Tcl/Tk interface code,
other than changes to the functions which display a session participant’s IP6 address – a few of these were
IPv4 specific and others (especially in the C-language functions) suffered from run-time crashes due to
string variables being defined as only having enough length for IPv4 strings and not IPv6 strings.
3.2.
Adaptation to RSVP
With regards to the ‘PATAM’ drivers and RSVP Daemon from UPM being used on the BTI project,
various versions of both VIC and RAT were created over time as the specification of the RSVP
functionality of PATAM and the RSVP Daemon also changed over time. Earlier versions of VIC and RAT
had to maintain knowledge of the current senders to a multicast session to create and tear-down
reservations as participants came and went. The final versions of VIC and RAT use the simpler assumption
that all the participant senders in an RSVP session (identified as the multiple Tspec’s in a FlowDesc in an
INFO_PATH message) are to have a reservation made for them.
Both the VIC and RAT tools had similar additions to the interface to accommodate RSVP functionality.
Although the visual appearance in both is similar, the locations of changes to the source code to enable
them are very different between both tools. Both the BTI versions of VIC and RAT feature two additional
‘status bars’ at the bottom of the main window – the upper one displaying RSVP status, decisions made and
RSVP reservations attempted. The lower status bar displays incoming RSVP messages from the RSVP
service provider on the client PC to the application (such as INFO_PATH, INFO_PATH_TEAR,
PATH_ERR). The Tcl/Tk interface also sounds a ‘bell’ (ASCII character seven) upon an incoming RSVP
message to the application (the client PC needs to have the local ‘speaker’ channel un-muted on the current
sound mixer device).
The main windows of both VIC and RAT also feature a ‘RSVP ON/OFF’ checkbox which controls
whether any of the normal VIC or RAT functions have also to perform relevant RSVP functions. For
example, if the checkbox is ‘ON’, then a press of the ‘Transmit’ button in VIC will also call the RSVP
function to call an IoCtl function with RSVP_SENDER information filled in. With this checkbox set to
‘OFF’ then both VIC and RAT act as normal – the only RSVP-specific functionality called being the initial
RSVP registration with Winsock. Upon a successful reservation, the portion of the main window behind the
two RSVP status bars turns green.
Page 17
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
Initially VIC had the functionality to change a reservation for the transmission from the local machine
based on the current codec, frames-per-second and ‘quality’ settings. It was initially the case that the
‘transmission rate’ slider control on the ‘transmission’ window caused a new reservation request with a
new Tspec for every few Kbps of change – in order that the reservation requests closely match the level of
the current transmission. Later versions of the BTI version of VIC remove such functionality as it can
easily confuse the BTI RSVP setup at the network level. Now, as long as the ‘RSVP ON/OFFF’ checkbox
is ticked, any start of transmission will use the transmission rate pertaining at the time in the RSVP request,
irrespective of any later change in transmission rate. In this case, for a different RSVP Tspec to be used in
the reservation request, the current transmission should be stopped and then started again, leaving the
RSVP functions to use the newer transmission rate setting.
3.3.
Conclusions
Both the VIC and RAT applications have been successfully compiled to run under the BTI-specification
operating system, namely NT Workstation 4.0 and Winsock 2.0. Much effort was needed to make both VIC
and RAT compile and run with IPv6, despite them being advertised as having IPv6 functionality. Later
releases of VIC (the latest was released by UCL in the last month) purport to support IPv6 again, updated
to use the same common networking library as RAT. This has not been investigated due to time constraints
as at the time of writing. The two resultant MBONE tools have RSVP functionality over IPv6 which can be
switched on or off via a simple checkbox at the main window level.
By way of advice to any future project wishing to follow a similar path towards the creation of RSVPaware multicast IPv6 tools, the UCL codebase for both VIC and RAT must be commended as an excellent
source of nearly-complete video and audio conferencing tools. The only drawback with this resource is the
lack of commercial-level support (much is now done on a voluntary basis) and the Open-Source license
leaving restrictions on certain commercial applications using such a codebase. Also, there can be very
many changes between minor version increments, many of which undo changes in a previous release. Such
public-spirited initiatives as these and many other ‘MBONE’ (multicast backbone) tools are a boon for a
programmer wishing to produce a leading-edge, non-commercial multicast tool very quickly (especially
over IPv4), but less use when a commercial-quality product is required.
Page 18
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
4. Porting VideoConference Application over IPv6 and RSVP in
UNIX environment
In early discussions within the BTI project it was clear, that the main emphasis was on working with
Windows-based applications (at that time either Windows 95 or Windows NT 4). This was, however,
complicated by the fact that there were not – and are still not – commercial products available that
implement IPv6 and RSVP in any of the Windows operating systems.
Initially the hope was that such products would be released in time for use by the project, but this turned
out not to be true. The project decided to keep the option open for working with Unix-based applications,
and one partner – UNI-C – was assigned the task of porting the Unix-based multicast conferencing
applications widely used on the global MBone IPv4 multicast network. This work was initiated because of
the availability of IPv6 support for several Unix systems already at the starting time of the project's lifetime
as well as the availability of RSVP software for Unix.
In the end, this solution was not adopted by the final BTI application, as the project decided to provide its
own ATM and RSVP support for the Microsoft Research IPv6 protocol implementation as described in
chapter 1.
In this chapter we summarise the work with the MBone applications and the experiences gained.
4.1.
The MBone applications
The work started with the multicast based conferencing applications that were – and still are – widely used
on the global IPv4 multicast test backbone, the MBone. In the BTI project, some of these applications were
also selected in their Windows applications as the foundation for the videoconferencing application
described in chapter 3.
These applications are:



sdr, the Session Directory
vic, the Video Conference tool
vat, the Visual Audio tool
which were the ones that we worked with. There are a number of additional Mbone applications:



rat, Reliable audio tool (which was the audio tool chosen for the Windows development in BTI)
wbd, WhiteBoard
nte, Network Text Editor.
The sdr application is implemented in traditional C, whereas vic and vat are written in C++, with the user
interface implemented using TCL/Tk.
4.2.
Adaptation to IPv6
4.2.1. The IPv6 environment used
At UNI-C a LAN-based IPv6 environment was already present which was expanded and maintained during
the lifetime of the BTI project.
This network consists of several LAN segments (one dedicated to IPv6 experiments and later also the main
LAN at UNI-C Århus) that were connected with the IPv6 backbone of the Danish Research Network and
Page 19
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
consequently to the 6Bone with Telebit TBC 1000 and 2000 routers, later supplemented by host based
tunnel services and for a while by a Cisco 3620 router running Cisco's IPv6 prototype software.
The hosts that were used during the project comprises (based on hardware that was already available):


Sun SparcStations running Solaris 2.5.1, Solaris 7, and NetBSD,
PC's running NetBSD, FreeBSD and Linux.
The Solaris 2.5.1 machine also serves as a DNS server for the IPv6 domain at UNI-C and as a Web server
for access by 6Bone users and by local IPv6 access, including BTI.
As of Solaris 7, IPv6 is still not part of the base OS, but is available as an easily installed patch. It seems
that IPv6 will be part of Solaris 8, which is in beta testing at the time of writing.
The Linux kernel sources now come with IPv6 as part of the standard release.
For FreeBSD and NetBSD, we had access to several source based 3rd party IPv6 implementations:



INRIA
KAME
NRL
During the BTI project we had several machines running with the INRIA and KAME implementations, and
now the KAME implementation seems to become the basis for an integration of these three IPv6
implementations, known as the Unified IPv6 implementation for the *BSD's. The software is now available
for NetBSD, FreeBSD, OpenBSD, and BSD/I, and in the near future, it will become a standard part of
several – if not all – of these Unix variants.
The IPv6 environment used here, we do not, however, have an ATM network infrastructure, and all
development and testing has consequently been done in a LAN environment. This means that these
machines cannot directly be used as terminals in the BTI access network, but they would have been
interoperable with terminals in the BTI access network, if the BTI network is connected to the 6Bone.
4.2.2. Adaptation of the applications
One of the reasons for working with several IPv6 implementations on several Unix variants is to verify the
portability of applications using the Basic Socket API across different systems. For applications not
needing low-level access to the IP stack, the traditional socket interface has been extended to support IPv6
in the "Basic Socket Interface Extensions for IPv6", which was published in April 1997 in RFC 2133, and
the upgraded in March 1999 with RFC 2553.
In addition to the Basic Socket API, the IETF has also published the "Advanced Sockets API for IPv6" in
RFC2292 of February 1998, which is being discussed and updated by the ipngwg working group of IETF,
latest in the Internet Draft "draft-ietf-ipngwg-rfc2292bis-01.txt" which is work in progress published in
October 1999. This API is needed for applications that need access to raw sockets, interface identification,
more IPv6 Extension Headers, etc.
The socket interface is the basic programming interface to network and other I/O programming on Unix
systems and on several other systems. We expect that the socket is the most widely used network
programming interface besides Winsock with is used with Microsoft Windows.
The applications were adopted by replacing all instances of sockaddr_in, the IPv4 specific socket address
structure, and usages of long/int to store IPv4 addresses, with a new union type encompassing sockaddr,
sockaddr_in and sockaddr_in6. This work was done before RFC 2553 had endorsed the sockaddr_storage
type, which would have served the same purpose. With that in place, it is only very few places in the code
that need to know and differentiate between IPv4 and IPv6. It has not been necessary to use any features of
Page 20
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
the Advanced Socket API.
The conversion was quite straightforward albeit somewhat tedious because of the problem of identifying all
uses of long/int to carry an IPv4 address.
Some additional minor adaptations had to be made, in particular related to the DNS resolver API used for
querying the name servers when conversion between host names and addresses of different kinds were
needed.
Our modifed version of the applications work with NetBSD, FreeBSD (Kame or INRIA IPv6 stack), Linux
(RedHat 6.0), Solaris 2.5 and 7 based on a common source text. The only conditionals in the code have to
do with which headers are available/required for IPv6 support, and some differences in libraries required
for linking.
4.3.
Adaptation to RSVP
The code base we selected was the ISI tools that included RSVP support, so except that we had to adapt the
RSVP code for IPv6 the same way as the rest of the code, it did not pose any problems.
The main reason that this was so simple compared to the work done with adapting the Windows versions of
the same or similar applications is that in the LAN environment, the applications don’t manage the actual
QoS implementation them selves. Instead they just have to do the RSVP signalling by sending and
receiving RSVP messages and keeping the appropriate state. On the terminal’s own LAN we just have to
expect that there is sufficient bandwidth available, while the reservations in the transit network has to be
handled by the transit routers.
If we could have access to an RSVP-enabled router infrastructure, we would also have been forced to solve
some of the problems faced by the Windows based applications, e.g. deciding how calculate the RSVP
reservation parameters given the net bandwidth requirements by the applications and to decide whether the
overhead for IP headers and ATM packet assembly should be calculated by the applications or the network
elements.
4.4.
Conclusions
Based on the work described here, we can draw the following conclusions:

It is possible to set up a stable network infrastructure using a mixture of IPv4 and IPv6 on LAN
segments connected locally or remotely by routers or by host based tunnels including tunnel based
connections to the global 6Bone IPv6 network.

As part of this work we could also give feed-back to the KAME and INRIA projects about the
portability of their software including bug reports and in some cases fixes when their software was
expanded and upgraded. Finally we were able to participate to some degree in the ipngwg and ngtrans
IETF working groups throughout the project period.

This network infrastructure was available for unicast as well as for multicast traffic, although there is
still not a global multicast connectivity. While setting up this network infrastructure we were also able
to give some feed-back to Telebit about their IPv6 and PIM implementations.

The applications were adapted to work with IPv6, and actually they are able to use IPv6 and IPv4
simultaneously on different connections as they select the protocol depending on the address to
communicate to.

The applications were already supporting RSVP, and our work here was quite limited, but testing and
network snooping confirms that the RSVP messages were exchanged as expected.
During the project period the development of several of the MBone applications was more or less dormant,
Page 21
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
which has reduced the possibilities of getting the updates done by the projects integrated into the base
versions of the applications. Recently it seems that UCL has revived the work with some of the
applications.
This simplification of using a LAN based environment (at the cost of total QoS) is probably the main
reason that the work with the Unix based applications was much less problematic than the work on the
Windows based applications by the other WG3 partners of BTI, where the full ATM integration was
needed in the terminals.
Page 22
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
5. Porting Data Application over IPv6 and RSVP
Data Applications used in BTI project were based on the co-operative work software environment
developed by UPM for LEVERAGE ACTS project [LEVERAGE]. This environment is made of four data
conferencing applications: shared editor, shared whiteboard, shared web browser and chat tool; all of them
integrated in a virtual workspace that allows users to create virtual meetings and interact synchronously by
sharing documents.
Figure 10 represents the communication architecture of Data Applications. Clients run over PCs with
Windows NT or 95/98 and connect to a server daemon called the Session Manager (SM), which runs over
a UNIX server.
Clients are made of several modules [Fernandez98]:




Session Desktop (SD), which is the user-interface to the system;
Applications, shared editor, chat, etc,
Administrative Database, which maintains all the information about users; and
Session Manager Agent (SMA), which is in charge of the communications between the client and the
server, and deals with all the session management tasks in clients.
Figure 10: Data Applications Communication Architecture
The task of porting Data Applications to IPv6 and RSVP was divided between PT Inovação, who was in
charge of porting the server part, and UPM, who was in charge of porting the client side. In the case of the
server, apart from making the IPv4-to-IPv6 code adaptation, an additional task was carried out that
consisted in the selection and testing of a suitable RSVP over IPv6 UNIX platform to run the server.
The starting point for the selection task was the ISI RSVP daemon over IPv4 running on Linux Red Hat
5.1, 2.0.35 kernel version, which had been used in BTI phase 1. Three options were then investigated –
Linux kernel 2.2.5-15, Solaris 2.5.1 and Solaris 7.
The outcome of this investigation was the selection of Solaris 2.5.1 as the platform for the migration to
IPv6, as it proved to be a stable solution with an easier compilation and configuration process than the other
alternatives. Furthermore, the fact that WP3.2 had successfully implemented ISI RSVP over IPv6 on
Solaris 2.5.1 for the development of the video retrieval server reinforced that choice.
Page 23
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
As a result of the task, the following server platform was selected:
Software Package
Solaris
RSVP API
IPv6
5.1.
Version
2.5.1
5.02
Prototype 5.3, Sep22,1997
Adaptation to IPv6
5.1.1. Server Adaptation
To adapt the SM server code to support IPv6, a set of changes were carried out on the network interface
following [RFC2553]. This RFC describes the socket address structure to carry an IPv6 address, new
address conversion functions and new socket options. These extensions provide the access to the basic IPv6
features required by applications using TCP and UDP, including multicast. In addition, [RFC2292]
describes extensions for advanced IPv6 features, for example, the utilisation of raw sockets.
The SM application had been originally implemented with IPv4/TCP sockets. The adaptation of this
application to support IPv6 consisted of changing it to IPv6/TCP sockets as defined in the RFC 2553. No
changes were needed in the syntax of the API RSVP, as the RSVP stack used by SM has been implemented
for unifying IPv4 and IPv6.
The following tables indicate the main adaptations needed.
Core socket functions
First Group
Remark
Functions to pass address to socket
bind()
No changes in the syntax of these functions because the address is carried to
socket in a structure which is an argument of these functions.
connect()
Second Group
accept()
getpeername()
getsockname()
Address conversion
functions
inet_addr()
inet_ntoa()
Name-to-address
translation functions
gethostbyname()
Functions to return address from the socket
No changes in the syntax of these functions. The address is received through
an element of a socket structure.
Remark
Changes to inet_pton()
Changes to inet_ntop()
Remark
Should be updated to getipnodebyname() but the IPv6 distribution that was
used does not support this function. Instead, gethostbyname2(), as defined in
[RFC 2133] (obsoleted by RCF 2553) was used.
Struct and constants
struct sockaddr_in
struct in_addr
Remark
Changes to structure sockaddr_in6
Changes to in6_addr
INADDR_ANY
Changes to in6addr_any
AF_INET
Changes to AF_INET6
Page 24
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
5.1.2. Client Adaptation
The migration of the client part to IPv6 was made in three steps. First of all, the architecture was modified
to send and receive all the data traffic from applications through the connection between the SMA and SM.
Originally every application had its own independent data channel. But, in order to be able to make a joint
RSVP reservation for all the traffic generated by all the applications being used in a session, the client was
modified to route all the traffic through the TCP connection that every client establishes with the SM to
interchange control traffic.
Secondly, the low-level communication libraries of SMA were migrated to use Winsock 2 programming
interface. That migration was obliged by the fact that the IPv6 stack used in BTI (MSRIPV6) is not
available through winsock 1.1, which was the API used originally by Data Applications.
Finally, the SMA was migrated to IPv6. Apart from some small problems found due to some bugs and
oddities in IPv6 stack (mainly in routines related to address management) the migration was smooth,
mainly because of the similarities between IPv4 and IPv6 sockets in Winsock 2.
5.2.
Adaptation to RSVP
5.2.1. Reservation Model
As mentioned earlier, the communication between clients and server is done using TCP connections. Thus,
in order to add QoS guaranty to Data Applications, RSVP unicast sessions have been used, following the
reservation model described below.
For each client (meaning SMA) and server (SM) pair, two RSVP unicast sessions are defined: one for the
traffic going from client to server (that is: Sserver= IPs/Ps [TCP], being IPs and Ps the well known address and
TCP port to which the clients connect), and another for the traffic coming from the server to the client (that
is: Sclient= IPc, Pc [TCP]).
When a user creates or joins a session, it begins sending PATH messages to the server (S server). As soon as
the server receives these PATH messages, it (1) begins to send PATH messages to the client (S client), and
(2) issues a reservation for Sserver. Later, when the client receives the PATH messages from the server, it
issues a reservation for Sclient. Eventually, both reservations will be established, and all the traffic of the
session will be sent/received with QoS guaranty.
If there is only one server with N clients connected 1, this means that the server participates as a sender in N
unicast sessions (Sclient1, Sclient2, etc; one session per client) and as a receiver in the session that defines its
own endpoint TSAP (Sserver). Accordingly, each client participates as a sender in session S server and as a
receiver in the session corresponding to its own TSAP (Sclientx).
5.2.2. Server Adaptation
The server part of the data applications is implemented as a single process running on Solaris platforms.
The RSVP engine chosen for this environment is the one developed by ISI, since it has direct support for
Solaris. Thus, the RSVP API offered to the server is the RAPI [RAPI] defined by ISI in its documentation.
The server has to maintain one session for each connected client and one more session with its own IP
address and TCP port. The actions that the server performs in order to establish the convenient reservations
can be summarised as follows:
1
This is the case in BTI escenario. LEVERAGE environment was able to support several sites interconnected, each
one with its own Session Manager.
Page 25
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
 Register as a receiver in Sserver, the session corresponding to its well-known TSAP,
 When a client connects, register as a sender to that client's session: S client = (IPc, Pc). The Tspec
is determined by the QoS parameters sent by the client.
 When receiving a Path notification from a connected client (on session S server), issue a
reservation call asking for a CL reservation with the same parameters as the Tspec the Path
carried.
 Eventually, for each client connected (for each session Sclient), it will receive a Resv notification
indicating that the client asked for a reservation that has been conceded.
The adaptations needed to support RSVP over IPv4 in Session Manager daemon following the model
described above were made for Milestone 2 of the project. As the RSVP stack and API used by SM has
been implemented unifying IPv4 and IPv6, practically no syntax changes were needed to have RSVP
working over IPv6, apart from the IPv4-to-IPv6 changes mentioned in the previous section.
5.2.3. Client Adaptation
Clients applications (in particular, SMA module) access RSVP services through the RSVP Winsock 2
based API offered by the integrated protocol stack developed by UPM for BTI project.
The SMA is in charge of making one reservation on behalf of all the individual applications, which will
share it. This is a consequence of having changed the model of communications between clients and server,
making all the data go through a single TCP socket instead of using one socket per interactive application.
Besides, it simplifies the interface to choose the parameters of the reservation since the user has to estimate
the total traffic that all its applications will generate, instead of doing so for each application. Basically the
user interface gives three preconfigured QoS options (low, medium and high rate transmission) , a custom
dialog box (to choose any rate) and the possibility of not asking for QoS (in this case no RSVP activity will
be generated from the client’s side).
The actions clients perform can be summarised as follows:
 SMA registers to session Sserver as a sender, with a Tspec according to what the user asked,
and as a receiver to session Sclient (its local TSAP).
 When it receives a Path notification from the server (for session Sclient), it issues a CL
reservation with FF style.
 Eventually it will receive a Resv notification showing that the server asked for a reservation
(session Sserver).
The migration of SMA to use RSVP over IPv6 was not difficult. As the SMA was previously modified to
support RSVP over IP4 (in particular, for Milestone 2 of BTI project on November 1998), and the
interfaces used to access RSVP over IPv4 (using Intel's PC-RSVP) and RSVP over IPv6 (using UPM's
rsvpd) were very similar (both are winsock2 based), the modifications needed were minimal. Most of the
changes were related with the address format used in function calls, messages and user-interface. However,
due to the fact that Data Applications use unicast reservations and TCP connections, some new bugs not
found when testing other applications were encountered during the testing phase.
5.3.
Conclusions
The migration of Data Applications to IPv6 and RSVP was, in general, achieved without important
problems. As the network model of the system was simple, and we started from a version that already
supported RSVP over IPv4, the changes made to the code to adapt it to IPv6 were not important. In fact, the
number of lines of code modified was small.
However, we faced several problems during the integration and testing phases, mainly due to the inmaturity
of protocol stacks being used. On the server side, the main problems come from the interaction between the
Page 26
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
RSVP daemon and the IPv6 implementation. Under some circumstances, some RSVP packets were lost,
making some reservations fail. On the client side, some bugs were detected in the protocol stack (for
example, one important problem that affected only TCP connections, and not UDP packets). Finally, some
more problems were detected when testing the complete application over the whole scenario (made of
client PCs, ATM access network, IP router, Ethernet and server).
As the protocol implementations mature, and all these bugs and instabilities disappear, the migration of
applications like the one presented here should be simple and smooth.
Page 27
A0362/BTI/WP3/DS/R/P/301/B1 Conclusions from evaluation of all applications running on the network
6. References
[RFC2491]
IPv6 over Non-Broadcast Multiple Access (NBMA) networks.
G. Armitage, P. Schulter, M. Jork, G. Harter. January 1999.
[RFC2492]
IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork.
January 1999.
[RFC2022]
Support for Multicast over UNI 3.0/3.1 based ATM Networks. G.
Armitage. November 1996.
[MSRIPv6]
Microsoft Research's IPv6 implementation. Available on:
http://www.research.microsoft.com/msripv6.
[MARS-NIST]
NIST's MARS client implementation. Available on:
http://snad.ncsl.nist.gov/hendaz/NIST-MARS
[RFC2379]
RSVP over ATM Implementation Guidelines. L. Berger. August 1998.
[RFC2380]
RSVP over ATM Implementation Requirements. L. Berger.
August 1998.
[RFC2381]
Interoperation of Controlled-Load Service and Guaranteed Service
with ATM. M. Garrett, M. Borden. August 1998.
[RFC2382]
A Framework for Integrated Services and RSVP over ATM. E.
Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk.
August 1998.
[RSVPd]
Information Science Institute's RSVP daemon. Available on:
http://www.isi.edu/rsvp.
[WS2-API]
Windows Sockets 2 Application Programming Interface. Revision 2. August 7,
1997.
[WS2-Annex]
Windows Sockets 2 Protocol-Specific Annex. Revision 2.0.3. May 10, 1996.
[Gallen97]
Creating User-Mode Device Drivers with a Proxy. Galen C. Hunt, University of
Rochester. First USENIX Windows NT Workshop. Seattle, Washington, 1997.
[WS2-GQOS]
Winsock Generic QOS Mapping. Yoram Bernet, Jim Stewart, Raj Yavatkar, Dave
Andersen, Charlie Tai, Bob Quinn, Kam Lee. Windows Networking Group.
[LEVERAGE]
LEarn from Video Extensive Real Atm Gigabit Experiment (LEVERAGE). ACTS
project 109. http://www.dit.upm.es/leverage.
[RFC2205]
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden,
Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997.
[RFC2210]
The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997.
[Fernandez98]
Specification of Cooperative Work Services. David Fernández, Luis Bellido. Deliverable
921 of LEVERAGE ACTS project. Available in http://www.dit.upm.es/leverage.
[RFC2553]
R. Gilligan, S. Thomson, J. Bound, W. Stevens, RFC 2533, “Basic Socket Interface
Extensions for IPv6”, March 1999.
[RFC2292]
W. Stevens, M. Thomas, RFC 2292, “Advanced Sockets API for IPv6”, February 1998.
[RFC2133]
R. Gilligan, S. Thomson, J. Bound, W. Stevens, RFC 2133, “Basic Socket Interface
Extensions for IPv6”, April 1997.
[RAPI]
RAPI -- An RSVP Application Programming Interface. R. Braden, D. Hoffman. Internet
Draft.
Page 28