Network Working Group                                     Emmanuel Duros

Internet-Draft                                         Christian Huitema

                                                  INRIA Sophia-Antipolis

                                                           November 1997





               Handling of unidirectional links with RIP



                     <draft-ietf-udlr-rip-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.net (US East Coast), or

   ftp.isi.edu (US West Coast).





Abstract



   This document defines the modifications which can be applied to RIP
   [rfc1723] which make the communication over asymmetric links
   feasible.





. Introduction



   RIP is one of the first dynamic routing protocols used in the

   internet known as Internal Gateway Protocol. It was designed to work

   on networks where adjacent gateways communicate using the same link

   in both directions. Links may be asymmetric, e.g., have different

   delays and throughputs in different directions, but they have to be

   duplex.





. Overcoming RIP restrictions









Duros & Huitema                                                 [Page 1]

Internet Draft        Unidirectional links and RIP         15 March 1996





   A satellite network comprises two sets of stations, feeds that can

   both send and receive packets, and receivers that can only receive

   packets.



   Feeds must be allowed to forward over the satellite links the packets

   which are bound to subnets accessible through other feeds or through

   receivers.



   Receivers will never send any packet via the satellite link. They

   must however send reports to the feeds to indicate the subnets for

   which they are ready to receive packets.



   If the network included only feeds, RIP could be used almost

   unchanged. Usage by a mix of receivers and feeds requires some

   extensions.





. Proposed solution



   In our example we assume that G1 and G2 (Gateways) are connected to

   symmetric and asymmetric networks (See Figure 1). Using RIP, G1 does

   not consider G2 as a neighbor because the link is unidirectional and

   therefore will send packets to the regular connections (route N3).





                               route N1

            N2      ----                      ----      N5

        ---========>|G1| ===================> |G2|<==========---

                    ----      update msg      ----

                     /\                        /\

                     ||   ------------------   ||

                      ====|  regular       |====

                       N3 |    connections | N4

                          ------------------

                               Figure 1





   To avoid such behavior, G1 should consider G2 as a neighbor. RIP

   should be modified to take into account unidirectional links.



   RIP messages are composed of a succession of 20 bytes segments. The

   first segment may be an authentication code. All other segments are

   subnet-distance pairs. We propose to associate a specific

   authentication with the satellite network. The handling of this code

   will be different by feeds and receivers.





3.1. Handling by receivers







Duros & Huitema                                                 [Page 2]

Internet Draft        Unidirectional links and RIP         15 March 1996





   Upon reception of a RIP packet, receivers examine the authentication

   code. They note that this packet was sent by a satellite feed. They

   will ignore all subnet-distance announces contained in this packet,

   but they will add the source address of the packet [IP source] to the

   list of "potential feeds".



   At pseudo-regular intervals, the receivers will send to the potential

   feeds a RIP packet that will be authenticated as a "satellite

   packet". This packet, however, will not be sent to the regular

   multicast address of all the RIP routers. Instead, a copy of this

   packet will be sent to the unicast address of each feed.



   This procedure assumes that there is another route, beside the

   satellite link, by which the receiver can send packets to the feed.





3.2 processing by feeds



   Processing of RIP packets by feeds is almost unchanged, except the

   following :



   - all packets sent over the multicast link are authenticated.

   - all packets that are authenticated as satellite packets are

   processed even if they routed by another interface.





References



   [rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional

             Information", Request For Comments (RFC) 1723, Xylogics,

             Inc., November,1994.





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





   Christian Huitema

   INRIA Sophia Antipolis

   2004, Route des Lucioles BP 93

   06902 Sophia Antipolis CEDEX France



   Email : huitema@sophia.inria.fr



Duros & Huitema                                                 [Page 3]