[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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