Network Working Group Emmanuel Duros
Internet-Draft Walid Dabbous
INRIA Sophia-Antipolis
November 1997
Supporting Unidirectional Paths in the Internet
<draft-ietf-udlr-general-00.txt>
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.nTermet (US East Coast), or
ftp.isi.edu (US West Coast).
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 by [ASBD].
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 comprises 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 the 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). This station has
therefore two IP addresses, one belonging to the satellite subnet
(SAT.x) and the other 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 nationwide areas and therefore
address very important sets of receivers.
That 'expandable topology' due to the potential increasing number of
receivers (simple host or routers) leads us to consider dynamic
routing solutions.
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 can not work properly, an ARP request sent by a feed
to a host that belongs to the satellite network can not expect a
response from receivers.
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.
Users send packets via the interface INT.y, incoming packets should
be routed to the default address SAT.x.
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 can not 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] and 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 can not 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 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 which 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 subntework 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, ftp://zenon.inria.fr/rodeo/udlr/draft-
ietf-rip-unidirectional-link-00.txt, March 96
[2] E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft-ietf-ospf-
unidirectional-link-00.txt, March 96
[3] W. Dabbous, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/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 4 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 4 93 65 77 18
Datatracker
Report a datatracker bug
draft-ietf-udlr-general-00
None
| Document | Document type |
Expired Internet-Draft
(udlr WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Walid Dabbous
,
Emmanuel Duros
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |