[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Discussion for the UDLR Bof
Dear all,
As you saw in the previous mail on the list, we have
a slot for the Bof on Firday 28th morning.
We would like to have your input on the general problem
of supporting unidirectional paths in the Internet.
Here after a note that describes our view of the problem.
Could you please comment on this. Specially on section 3.1.
regards,
Walid Dabbous
---------------------
Emmanuel Duros INRIA Sophia-Antipolis
Walid Dabbous June 1996
Supporting unidirectional paths in the Internet
1. Introduction
Many distributed applications may benefit from a high bandwidth
connection to the Internet. However, this requires high bandwidth
links between remotes sites.
A low-cost solution to deliver high bandwidth services over wide
geographical areas via the use of broadcast satellite networks has
been proposed in [CSHCN].
However, this solution is based on low cost receivers with zero
bandwidth return. Connection over the satellite link is therefore
unidirectional. The integration of these satellite
networks with the Internet requires changes in common routing
protocols.
2. A new architecture
The advantage of a satellite network is to provide high bandwidth
services independent of the user's location over a large geographical
area.
A satellite network includes two types of stations: feeds, which can
both send and receive packets, and receivers, which can only receive
packets.
Every receiver is composed of a satellite dish oriented toward a
geostationary satellite, connected via an interface either to a
user station (in this case the access method is referred to as basic
access) or to a router (in this case the access method is referred to
as subnetwork access). The user station has another interface, and the
router has one or more extra interfaces, connected to the Internet.
Note that the cost of the hardware is made up of the cost of the satellite
dish and of the reception card.
Information is sent from feeds to satellites and then broadcast to
all the receivers that belong to the satellite coverage.
Installing feeds in strategic positions over the Internet will create
shorter paths and packets will be routed via a satellite network
that offers a higher bandwidth.
2.1 Basic access
Basic access corresponds to the case when each receiver has a satellite dish.
The user's station is also connected to the Internet via a
telephone/modem (e.g. PPP connection). The station has
therefore two IP addresses, one belonging to the satellite subnet
(SAT.x), the other belonging to the regular connection subnet (INT.y).
See Figure 1.
___ ___
\__\OO\__\ Satellite
^^ vv Network
/ \
uplink / \
/ \
/ \
Feed / \
---- / SAT.x V ---- User's
---======>|R1| |H1| station
---- ----
/\ /\ INT.y
|| ||
Server \/ || (PPP connection)
---- ------------------------- ||
|S1|<==>| regular |<==/
---- | connections |
-------------------------
Figure 1: Basic access
All requests to a remote server are sent via the phone line and
responses from the server should be routed by a feed on the satellite
network.
2.2 Subnetwork access
Subnetwork access corresponds to the case when a subnet router has
a satellite dish. See Figure 2. This router is then
interconnected to the Internet via regular connections and to a
subnetwork (such as R2 in Figure 2).
___ ___
\__\OO\__\ Satellite
R1: Feed ^^ vv Network
R2: Receiver / \
/ \
uplink / \
/ \
/ \
---- / V ---- -------------
---======>|R1| |R2|<===>| Subnetwork|<===---
---- ---- -------------
/\ /\
|| ||
Server \/ ||
---- ------------------------- ||
|S1|<==>| regular |<==/
---- | connections |
-------------------------
Figure 2: Subnetwork access
In that configuration only one satellite dish is required in order to
serve a whole subnetwork. The management is also located in only one
place, namely in the router.
3. Solutions
For the basic access and the subnetwork access we propose solutions
in order to handle unidirectional links.
3.1 A dynamic routing
Satellite networks are able to cover large geographical areas and therefore
address very large sets of receivers.
That 'expandable topology' due to the potential increasing number of
receivers (simple host or routers) leads us to not consider static
routing.
Feeds must learn dynamically receiver's media address (case of basic
access) and routes from receivers (case of subnetwork access).
Some modifications should be applied to protocols in order to handle
unidirectional links. For example, the protocol ARP [rfc826] assumes that
links are bidirectional, and it expects a communication between directly
connected host. In the same way, routing protocols assume that communication
between neighbor
routers is bidirectional to exchange routing information. The
configuration in Figure 2 is therefore not supported.
3.2 Basic Access
The ARP protocol cannot work properly, because a receiver that
belongs to the satellite network cannot respond to an ARP request sent
by a feed over the satellite network.
The reponse should be sent via regular connections to the feed.
Routing for that type of user's station is different from classical
routing. Indeed, the station has two IP addresses : SAT.x (belongs to
the satellite network) and INT.y (e.g. PPP connection to an Internet
service provider), as depicted in Figure 1.
All requests carry the address SAT.x and responses with the
media address are sent over the INT.y interface.
3.3 Subnetwork access
We consider here feeds and receivers as IP routers (R1 and R2 in
Figure 3). The general problem is : how can a receiver announce
routes to feeds since it cannot communicate directly with them ?
Our work is mainly based on the study of the most common routing
protocols that will be used by feeds and receivers such as RIP
[rfc1723], OSPF [rfc1583] and DVMRP [rfc1075] for multicast
routing.
Unlike receivers, feeds can broadcast routing messages via the
satellite network. A feed will expect to receive messages (e.g. a
response to a request on a specific interface) from all its
interfaces. Since a feed cannot receive messages from the satellite
network, routing protocols will consider that there is no reachable
networks beyond it.
In order to announce routes to feeds by receivers, routing messages
must be sent to the unicast address of each feed. This assumes that
receivers can communicate with feeds via regular connections (See
Figure 3).
___ ___
\__\OO\__\ Satellite
R1: Feed ^^ vv Network
R2: Receiver ~/ \
/ \
uplink / \
/ \
/ \
---- / V ----
---======>|R1| |R2|<=======---
---- ----
/\ /\
|| ----------------- ||
====| regular |====
| connections |
-----------------
Figure 3
Moreover, both the feed's and receiver's interfaces connected to the
Internet (regular connection) hardly ever belong to the same
subnetwork (due to the long distances between feeds and receivers).
Routing protocol daemons check, in order to ensure security, that the
sender's address of a message belongs to the same subnetwork as the
interface that received it. Therefore routing information will not
be taken into account since the packet will be rejected.
We have just described some problems that occur when trying to handle
unidirectional links by common routing protocols. Specific problems
related to RIP [1], OSPF [2] and DVMRP [3] are described in other
documents. They are available at ftp://zenon.inria.fr/rodeo/udlr/
4. Conclusion
Improving user connectivity to the Internet at low cost seems
possible, e.g. both for basic access or subnetwork access.
However handling unidirectional links by standard routing protocols
(RIP, OSPF, DVMRP) is not trivial and currently not supported. It
requires changes in the current protocol specifications. Fortunately
these changes should not lead to new versions of routing protocols
(RIP and DVMRP) and should be transparent for routers not connected
to satellite networks.
References
[ASBD] V. Arora, N. Suphasindhu, J.S. Baras, D. Dillon
Asymmetric Internet Access over Satellite-Terrestrial Networks
http://www.isr.umd.edu/CCDS/research/AIA/sld001.htm
[1] C. Huitema, E. Duros, draft-ietf-rip-unidirectional-link-00.txt,
March 96
[2] E. Duros, draft-ietf-ospf-unidirectional-link-00.txt, March 96
[3] W. Dabbous, E. Duros, draft-ietf-dvmrp-unidirectional-link-00.txt,
March 96
[rfc823] David C. Plummer, "An Ethernet Address Resolution Protocol",
Request For Comments (RFC) 826,November 1982
[rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional
Information", Request For Comments (RFC) 1723, Xylogics, Inc.,
November,1994.
[rfc1583] J. Moy,"OSPF Version 2", Request For Comments (RFC) 1583,
Proteon, Inc., March 1994.
[rfc1075] S. Deering, C. Partridge, D. Waitzman, "Distance Vector
Multicast Routing Protocol", November 1988.
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 93 65 78 15
Walid Dabbous
INRIA Sophia Antipolis
2004, Route des Lucioles BP 93
06902 Sophia Antipolis CEDEX France
Email : Walid.Dabbous@sophia.inria.fr
Phone : +33 93 65 77 18
- ------- End of Forwarded Message
------- End of Forwarded Message