Internet DRAFT - draft-ietf-udlr-llencap
draft-ietf-udlr-llencap
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 08:56:10 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 05 Dec 1997 12:58:14 GMT
ETag: "2e7971-7e7e-3487fa66"
Accept-Ranges: bytes
Content-Length: 32382
Connection: close
Content-Type: text/plain
Network Working Group Emmanuel Duros
Internet-Draft INRIA Sophia-Antipolis
November 1997
A Link Layer Tunneling Mechanism for Unidirectional Links
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes a mechanism to emulate bidirectional
connectivity between nodes that are directly connected by an
unidirectional link. The "receiver" uses a link layer tunneling
mechanism to forward datagrams to "feeds" through a bidirectional
network.
1. Introduction
Internet routing and upper layer protocols assume that links are
bidirectional, i.e. directly connected hosts can communicate with
each other on the same link.
This Internet Draft describes a link layer tunneling mechanism which
allows nodes that are directly connected by an unidirectional link
(feeds and receivers) to send datagrams as if they were connected to
a bidirectional link. The document presents a generic topology with a
tunneling mechanism that supports multiple feeds and receivers.
Duros [Page 1]
Internet Draft LL tunneling mechanism Expiration date
The tunneling mechanism is implemented at the link layer of
unidirectional interfaces on every feed and every receiver. The aim
is to hide to higher layers, i.e. network layer and above, the
unidirectional feature of the link. The tunneling mechanism also
includes an automatic tunnel configuration protocol which allows
feeds and receivers to come up/down at any time.
The tunneling mechanism uses Generic Routing Encapsulation [rfcGRE]
and provides a means for carrying IP and ARP datagrams from receivers
to feeds.
The tunneling mechnism described in this Internet Draft was discussed
and agreed upon by the UDLR working group.
2. Terminology
Unidirectional link: A zero return bandwidth link, e.g. a satellite
link with a receive only hardware.
Feed: A router connected to an unidirectional link through a send-
only interface.
Receiver: A router connected to an unidirectional link through a
receive-only interface.
3. Topology
Feeds and receivers are connected via an undirectional link. Feeds
can only send data over this unidirectional link, and receivers can
only receive data from it. In the case of non transitive links, the
feeds have both send and receive capabilities, and receivers have
receive only capabilities. We focus in the rest of this document on
unidirectional links only.
A receiver has several interfaces, a receive-only interface and one
or more added communication interfaces. A receiver is a router.
A feed has several interfaces, a send-only interface and one or more
added communication interfaces. A feed is a router.
In the entire document we assume that feeds and receivers are
connected to the Internet. A receiver and a feed can then communicate
with each other using their bidirectional interface (Ethernet
interface, PPP connection, etc.).
Figure 1 depicts a generic topology with several feeds and several
Duros [Page 2]
Internet Draft LL tunneling mechanism Expiration date
receivers.
Unidirectional Link
---->---------->------------------->------
| | | |
|f1u |f2u |r2u |r1u
-------- -------- -------- -------- ----------
|Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A|
-------- -------- -------- -------- ----------
|f1b |f2b |r2b |r1b |
| | | | |
----------------------------------------------------
| Internet |
----------------------------------------------------
Figure 1: Generic topology
f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2)
unidirectional interface (send-only).
f1b (resp. f2b) is the IP address of a 'Feed 1' (resp. Feed 2)
bidirectional interface connected to the Internet.
r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver
2) unidirectional interface (receive-only).
r1b (resp. r2b) is the IP address of a 'Receiver 1' (resp. Receiver
2) bidirectional interface connected to the Internet.
4. Problems related to unidirectional links
Most protocols in the Internet assume that links are bidirectional.
In particular, routing protocols used by directly connected routers
no longer behave properly in the presence of an unidirectional link.
Indeed, receivers cannot send requests/responses or routing messages
to feeds through their receive-only interface.
The network layer has no knowledge of the underlying transmission
technology except, it considers its access as bidirectional.
Basically, for outgoing datagrams, the network layer selects the
correct first hop on the connected network according to a routing
table and passes the packet(s) to the appropriate link-layer driver.
Duros [Page 3]
Internet Draft LL tunneling mechanism Expiration date
Referring to Figure 1, Recv 1 considers Feed 1 (IP address f1u) as
belonging to a connected network. However, initiating a 'ping f1u' on
Recv 1 cannot get a response from Feed 1. Recv 1 network layer
delivers the packet to the driver of the receive-only interface,
which obviously cannot send it to the feed.
More generally, a datagram of any protocol which passes from the
network layer to the driver of a receive-only interface is simply
discarded.
5. Link layer tunneling mechanism
This document describes a link layer tunneling mechanism allowing
bidirectional communication between feeds and receivers in the
presence of an unidirectional link. This mechanism has been designed
to work for any topology regardless of the number of feeds and
receivers. In particular, the special case of a single feed and
multiple receivers is among the topologies supported.
This link layer tunneling mechanism operates underneath the network
layer. Its aim is to emulate a bidirectional link. It is transparent
to the network layer: the link appears and behaves to the network
layer as if it was bidirectional.
5.1. Tunneling mechanism at the receiver
The tunneling mechanism is inserted at the link layer of the
receive-only interface. As a datagram is delivered to the link layer
from the network layer, it is encapsulated. This encapsulation can be
performed in user space if a daemon can read the datagram from the
link layer.
The datagram is encapsulated behind an IP packet whose destination is
the IP address of a feed bidirectional interface (f1b or f2b). The
mechanism for a receiver to learn these addresses is explained in
Section 5.3. The type of encapsulation is described in Section 6.
The new datagram is passed to the network layer, which forwards it
according to its destination address. The destination address is a
feed bidirectional interface which is reachable via the Internet. The
datagram is then routed via a receiver bidirectional interface. The
We have to distinguish several cases as the datagram is to be
tunneled according to its destination address. If the destination
address is:
1) the IP address of a feed unidirectional interface: the datagram
Duros [Page 4]
Internet Draft LL tunneling mechanism Expiration date
is encapsulated, the destination address of the new datagram is
the feed tunnel end-point.
2) the broadcast address of the unidirectional link or the "all
feeds" multicast address: a copy of the datagram is encapsulated
and sent to every feed tunnel end-point.
3) an IP address that belongs to the unidirectional network but is
not a feed address: the datagram is encapsulated and sent to the
tunnel end-point of the default feed. The default feed the one
with the smallest IP number on the satellite link. This allows,
for instance, for receivers to ping each other.
4) an IP address different from the previous cases (any IP
address): the datagram is discarded, see Section 8.1.
At this point, the network layer passes a datagram to the link layer
of the unidirectional interface, which is encapsulated and sent to
one or all the feeds.
5.2. Tunneling mechanism at the feed
The feed listens to incoming encapsulated datagrams on its tunnel
end-point. A packet is received from the bidirectional interface,
traverses the IP stack, and goes into a decapsulation process.
The original datagram is decapsulated and passed to link layer driver
of the feed unidirectional interface. As a result, the datagram is
processed as if it was coming from the send-only interface.
If the datagram is an IP packet, it is delivered to the feed network
layer. Since the datagram was encapsulated, its IP header has not
been modified by intermediate routers. To the network layer, the
datagram appears as coming from the send-only interface.
The network layer forwards the datagram according to its destination
address. If the destination address is:
1) the IP address of the feed send-only interface or the
unidirectional link broadcast IP address: the datagram is kept
and delivered locally.
2) otherwise it is forwarded according the feed routing tables. A
receiver may ping another receiver on the unidirectional link,
its request is forwarded by the feed to the destination.
5.3. Dynamic tunneling configuration: the HELLO protocol
Duros [Page 5]
Internet Draft LL tunneling mechanism Expiration date
A receiver has to know the feed tunnel end-points in order to forward
encapsulated datagrams. Tunnels must be configured and maintained
dynamically in order to cope with the following events:
1) as a new feed comes up, every receiver should create a tunnel to
enable a bidirectional communication with it. Static tunneling
configuration is not appropriate, as new feeds can be connected
to the unidirectional link at any time.
2) as the unidirectional link is down, receivers must disable their
tunnels. The tunneling mechanism emulates bidirectional
connectivity between a feed and a receiver. Therefore, if the
unidirectional link is down, a feed should not receive datagrams
from the receivers. Indeed there are protocols which consider a
link as operational if they receive datagrams from it (e.g. the
RIP protocol [rfcRIP]).
3) as a feed is suddenly down, receivers must disable the
corresponding tunnel. This prevents unecessary datagrams from
being tunneled which would overload the Internet. For instance,
there is no need for receivers to forward a broadcast message
through a tunnel whose end-point is down.
The HELLO protocol provides a means for receivers to dynamically
discover the presence of feeds and maintain a list of operational
tunnel end-points. It is based on periodical feed announcements over
the unidirectional link which contain tunnel end-point addresses.
Receivers listen to these announcements, discover the presence of
feeds, and maintain a list of tunnel end-points.
5.3.1. The HELLO message
The HELLO protocol is a 'unidirectional protocol', messages are only
sent from feeds to receivers.
The packet format is shown in Figure 2. Field sizes are given in
octect. Fields contain binary integers, in normal Internet order with
the most significant octet first. Each tick mark represents one bit.
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version (1) | command (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| Feed unidirectional IP address (4) |
+---------------------------------------------------------------+
| Feed bidirectional IP address (4) |
+---------------------------------------------------------------+
Duros [Page 6]
Internet Draft LL tunneling mechanism Expiration date
Figure 2: Packet Format
Every datagram contains a version number, a command and two IP
addresses. The version number of the HELLO protocol is HELLO_VERSION
(constant definitions are given in Section 5.3.5). The command field
is used to specify the purpose of this datagram. Possible values of
the command field implemented in the version HELLO_VERSION of the
protocol are:
1 - JOIN A message announcing that the feed sending this message
is up and running.
2 - LEAVE A message announcing that the feed sending this message
is being shut down.
The last two fields must be set regardless of the command (JOIN or
LEAVE).
The feed unidirectional IP address (FUIP) field is the IP address of
the outgoing unidirectional interface of the feed which sends the
HELLO packet.
The feed bidirectional IP address (FBIP) field is the IP address of a
feed bidirectional interface reachable via the Internet. A feed may
have several bidirectional interfaces connected to the Internet, but
only one is selected as FBIP. The choice of this interface is outside
the scope of this Internet Draft. It is the feed administrator who
selects the most suitable interface to announce. This address will be
used by receivers as the tunnel end-point.
5.3.2. The HELLO protocol at the feed
The HELLO protocol runs on top of UDP. Packets are sent to the
broadcast address of the unidirectional link on port HELLO_PORT.
The source address of HELLO packet is set to the IP address of the
feed outgoing unidirectional interface.
The process in charge of sending HELLO packets fills every field of
the datagram according to the description given in Section 5.3.1.
As long as a feed is up and running, it periodically announces its
presence and bidirectional interface to receivers. It MUST send HELLO
packets containing a JOIN command every HELLO_INTERVAL on the
unidirectional link.
Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO
messages with the FUIP field set to f1u (resp. f2u) and the FBIP
Duros [Page 7]
Internet Draft LL tunneling mechanism Expiration date
field set to f1b (resp. f2b). Note that all FUIPs should have the
same network prefix: the unidirectional network address.
When a feed is about to be shut down, or when routing over the
unidirectional link is about to be intentionally interrupted, it is
recommended to:
1) stop sending HELLO messages containing a JOIN command.
2) send a HELLO message containing a LEAVE command to inform
receivers that the feed is no longer performing routing over the
unidirectional link.
5.3.3. The HELLO protocol at the receiver
Based on the reception of HELLO messages, receivers discover the
presence of feeds and keep trace of their corresponding tunnel end-
points. Every receiver maintains a list of active feeds which
contains pairs of (FUIP,FBIP).
When a receiver is started, it MUST run a process which listens to
incoming broadcast packets on port HELLO_PORT from its unidirectional
interface. The list of active feeds is initially empty.
Upon reception of a HELLO message, the process checks the version
number of the protocol. If it is different from HELLO_VERSION, the
packet is discarded and the process waits for the next incoming
packet.
After successfully checking the version number it is recommended to
check that the FUIP contained in the packet is the same as the source
address of the HELLO packet. Further action depends on the type of
command:
- JOIN:
The process verifies if the pair (FUIP,FBIP) contained in the
HELLO packet already belongs to the list of active feeds.
If it does not, the pair (FUIP,FBIP) is added to the list of
active feeds. A timer set to HELLO_LEAVE is associated with this
pair.
If it does, the timer associated with this pair is reset to
HELLO_LEAVE.
Referring to Figure 1 in Section 3, both receivers (recv 1 and
recv 2) have a list of active feeds containing two pairs which are
Duros [Page 8]
Internet Draft LL tunneling mechanism Expiration date
(f1u,f1b) and (f2u,f2b).
- LEAVE:
The process checks if the pair (FUIP,FBIP) contained in the HELLO
packet belongs to the list of active feeds. If it does, it is
deleted the list the corresponding timer is disabled. The LEAVE
message provides a means of quickly updating the list of active
feeds.
A timout can have two reasons:
1) a feed went down without sending a LEAVE message. As JOIN
messages are not sent from this feed anymore, a timemout expires
HELLO_LEAVE after receiving the last JOIN message.
2) the unidirectional link is down. Thus, no more JOIN messages are
received from the feeds. All the timeouts associated with pairs
(FUIP,FBIP) will have expired HELLO_LEAVE after receiving the
last JOIN message from the unidirectional link.
In both cases, the associated (FUIP,FBIP) pair is removed from the
list of active feeds. As either the feed does not route datagrams
over the unidirectional link or the link is down, bidirectional
connectivity cannot be ensured any longer between the receiver and
the feed (FUIP). As a result, the list only contains operational
tunnel end-points.
The HELLO protocol provides receivers with the list of usable tunnel
end-points (FBIP). In the following section, we describe how to
integrate the HELLO protocol into the tunneling mechanism described
in Sections 5.1 and 5.2.
5.3.4. Tunneling mechanism using the list of active feeds
This section explains how the tunneling mechanism uses the list of
active feeds to handle datagrams which are to be tunneled. Referring
to Section 5.1, it shows how feed tunnel end-points are selected.
Several cases are enumerated in Section 5.1 to determine where to
forward a datagram according to its destination address. If the
destination address is:
1) the IP address of a feed unidirectional interface: this is TRUE
if the address matches with a FUIP in the list of active feeds.
The datagram is encapsulated and sent to the corresponding FBIP.
2) the broadcast address of the unidirectional link or a multicast
Duros [Page 9]
Internet Draft LL tunneling mechanism Expiration date
address: a copy of the datagram is encapsulated and sent to
every FBIP in the list of active feeds. If the list is empty,
the datagram is discarded.
3) an IP address that belongs to the unidirectional network but is
not a feed address (i.e., it does not match any FUIP in the list
of active feeds): the datagram is encapsulated and sent to the
smallest FUIP found in the list. If the list is empty, the
datagram is discarded.
4) an IP address different from cases 1), 2) and 3): the datagram
is discarded.
5.3.5. Constant definitions
HELLO_VERSION is 1.
HELLO_INTERVAL is 10 seconds.
HELLO_PORT is 620. It is a reserved port, no other traffic must be
allowed.
HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. 30 seconds.
6. Generic Routing Encapsulation
The encapsulation format is determined by the type of data which is
to be tunneled. It must support the encapsulation of IP datagrams in
order to tunnel IP datagrams from receivers to feed tunnel end-
points.
The unidirectional network may support hardware addressing. Before
sending an IP datagram to a receiver, the feed must obtain the
hardware address of the receiver unidirectional interface. The
Address Resolution Protocol [rfcARP] is a 'method of Converting
Protocol Addresses (e.g. IP addresses) to Local Network Addresses
(e.g. Ethernet Addresses)'. It is a link layer protocol which assumes
that links are bidirectional. If the link is unidirectional, a
receiver cannot respond to an ARP request generated by a feed.
Using the tunneling mechanism described in the previous sections, a
receiver should be able to tunnel ARP responses to feeds. The
encapsulation format must also support the encapsulation of the ARP
protocol.
The Generic Routing Encapsulation (GRE) [rfcGRE1702] specifies a
protocol for encapsulating arbitrary packets within IP as the
Duros [Page 10]
Internet Draft LL tunneling mechanism Expiration date
delivery protocol. GRE suits well our requirements, as it allows
encapsulation of both the ARP and the IP protocol within IP.
6.1. Encapsulation format
A GRE packet is composed of a header in which a type field specifies
the encapsulated protocol (ARP, IP, IPX, etc.). See [rfcGRE1701] for
details about the encapsulation. In our case only the support of ARP
and IP MUST be implemented.
A packet tunneled with a GRE encapsulation has the following format:
the delivery header is an IP header whose destination is the tunnel
end-point (FBIP), followed by a GRE header indicating if the payload
is either an ARP message or an IP datagram. Figure 3 presents the
entire encapsulated packet.
----------------------------------------
| IP delivery header |
| destination addr = FBIP |
| IP proto = GRE (0x47) |
----------------------------------------
| GRE Header |
| type = ARP (0x806) or IP (0x800) |
----------------------------------------
| Payload packet |
| ARP or IP |
----------------------------------------
Figure 3: Encapsulated packet
6.2. GRE at the receiver
The link layer driver of the receive-only interface can pass two
types of datagrams to the encapsulation process. The link layer
datagram format is as follow:
----------------------------------------
| type |
| ARP (0x806) or IP (0x800) |
----------------------------------------
| data |
| ARP or IP |
----------------------------------------
Figure 4: Link Layer encapsulation
An IP datagram delivered from the network layer to the link layer is
encapsulated behind an IP type header. The link layer sending an ARP
Duros [Page 11]
Internet Draft LL tunneling mechanism Expiration date
response to a feed encapsulates the response behind an ARP type
header.
The encapsulation process checks the type of protocol of the datagram
read from the link layer. According to this, it obtains the
destination address from the datagram, encapsulates the datagram
behind a GRE header, and tunnels it following the requirements in
Section 5.3.4.
6.3. GRE at the feed
The decapsulation process receives the GRE packet and extracts the
original datagram. The process passes the datagram (type+data) to the
link layer driver of the send-only interface.
The link layer determines what type of data it received (IP or ARP)
and queues the packet for processing.
The tunneling mechanism using a GRE encapsulation provides a mean for
carrying IP and ARP datagrams from receivers to feeds. However the
ARP protocol as described in [rfcARP] cannot work efficiently in
spite of the link layer tunneling.
7. Address Resolution Protocol
The ARP protocol has been designed originally for 10MBits Ethernet
hardware where delays between directly connected hosts are very
small. A host can get a response to an ARP request within a
millisecond. For this reason, ARP is an on-demand mechanism, the ARP
protocol requests a hardware address as it needs it.
Our link layer mechanism emulates a bidirectional network in the
presence of an unidirectional link. However, there are asymmetric
delays between every (feed, receiver) pair. The back-channel between
a receiver and a feed has varying delay because packets go through
the Internet. Furthermore, a typical example of unidirectional link
is a GEO satellite link whose constant delay is 250 milliseconds.
As a result, a feed may get a response to an ARP request at least 250
ms later in some cases. If a feed has to forward packets at high data
rates to a receiver whose hardware address is unknown, it will drop
part of the packets. Indeed, the stream of packets is passed to the
link layer driver of the feed send-only interface. When the first
packet arrives, the link layer realizes it does not have the
corresponding hardware address of the next hop, and sends an ARP
Duros [Page 12]
Internet Draft LL tunneling mechanism Expiration date
request. While the link layer is waiting for the response (at least
250 ms), IP packets are buffered by the feed. If it runs out of space
before the ARP response arrives, IP packets will be dropped.
Therefore, the ARP protocol has to be modified to take into account
high latencies, as a simple on demand approach is not sufficient.
7.1. ARP at the receiver
It is interesting to note that the link layer of the receive-only
interface does not maintain an ARP cache table. The receiver always
tunnels datagrams which are sent to feeds via the Internet.
The receiver must be able to reply to ARP requests sent by feeds. As
the link layer receives the request, it prepares the ARP response and
passes it to the encapsulation process as described in Section 6.2.
An on-demand ARP mechanism is not sufficient because feeds cannot get
receiver hardware addresses quickly enough. Thus, ARP cache tables at
feeds should be then constantly updated/refreshed. For that purpose,
every receiver periodically sends encaspulated ARP responses to the
list of active feeds. The interval is ARP_INTERVAL (constant
definitions are given in Section 7.3). This mechanism can be
implemented in the encapsulation process.
7.2. ARP at the feed
A feed refreshes its ARP table every time it receives an ARP response
from a receiver. If the entry does not exist, it is created,
otherwise the ARP timer is reset to ARP_CLEAR.
An ARP entry in the cache table is deleted after ARP_CLEAR. This
happens when a receiver suddenly goes down and no longer sends
periodical ARP responses.
In spite of its possibly high latency, the classical on-demand ARP
mechanism is still necessary. After a feed comes up it may need to
forward a packet to a receiver. It is better to immediately initiate
an ARP request and obtain the response short after 250 ms rather than
within ARP_INTERVAL.
7.3. Constant definitions
ARP_INTERVAL is 1 minute.
ARP_CLEAR is 3*ARP_INTERVAL, i.e. 3 minutes.
Duros [Page 13]
Internet Draft LL tunneling mechanism Expiration date
8. Issues
8.1. Routing protocols
The link layer tunneling mechanism hides from the network layer and
above layers the fact that feeds and receivers are connected by an
unidirectional link. Communication is bidirectional but asymmetric in
bandwidths and delays.
In order to incorporate unidirectional links in the Internet, feeds
and receivers have to run routing protocols. They will work fine
because feeds and receivers consider themselves as directly
connected, and can exchange routing messages over the unidirectional
link.
However, routing protocols MUST be configured to take into account
the link unidirectionality. IP routing must match the real topology
of the Internet at network level. It is not the aim of the tunneling
mechanism to forward the IP traffic, it MUST only be used to forward
routing protocol messages from receivers to feeds. Routing protocols
at the receivers MUST prevent IP traffic from being forwarded to
their receive-only interface.
For example, using RIP [rfcRIP], receivers announce reachable subnets
to the feeds, but they must not take into account those announced by
the feeds.
8.2. Scalability
This Internet Draft does not discuss the case of a very large number
of receivers and/or feeds. In case of a large number of feeds, it
will probably be necessary to use multicast routing. Indeed, instead
of sending a copy of a datagram to every entry of the list of active
feeds, a single datagram could be sent on a reserved multicast group
the feeds would listen to. However this requires that the receivers
and the feeds are connected to the MBone.
9. References
[rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer,
November 1982
[rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S.
Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina,
cisco System, October 1994
[rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths,
Duros [Page 14]
Internet Draft LL tunneling mechanism Expiration date
Ltd., T. Li, D. Farinacci, P. Traina, cisco System, October
1994
[rfc1388] 'RIP Version 2 - Carrying Additional Information', G.
Malkin, Xylogics, Inc., January 1993
Author's address
Emmanuel Duros
INRIA Sophia Antipolis
2004, Route des Lucioles BP 93
06902 Sophia Antipolis CEDEX France
Email : Emmanuel.Duros@sophia.inria.fr
Phone : +33 4 93 65 79 42
Duros [Page 15]
