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

Versions: 00                                                            
Network Working Group                                     Emmanuel Duros

Internet-Draft                                    INRIA Sophia-Antipolis

                                                              March 1996







               Handling of unidirectional links with OSPF



                      <draft-ietf-udlr-ospf-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 OSPF
   [rfc1583] which make the communication over asymmetric links
   feasible.





1. Introduction



   OSPF is a 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.





2. Overcoming OSPF restrictions









Duros                                                           [Page 1]


Internet Draft       Unidirectional links and OSPF            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 communicate with the designated router to indicate that

   they are ready to receive packets and are synchronized with their

   neighbors.



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

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

   extensions.





3. Proposed solution



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

   symmetric and asymmetric networks (See Figure 1). Using OSPF, G1 will

   never 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. OSPF

   should be modified to take into account unidirectional links.





3.1. Authentication scheme



   All OSPF protocol packets (Hello, Database description, etc.) share a

   common header of 24 bytes. The OSPF packet header includes an

   authentication type field (8 bits), and 64 bits of data used by the







Duros                                                           [Page 2]


Internet Draft       Unidirectional links and OSPF            March 1996





   appropriate authentication scheme (determined by the type field).



   We suggest that all packets sent over the satellite channel should be

   authenticated, using either type 1 authentication (simple password)

   or, preferably, a stronger type of authentication.  The

   authentication code will be specific to the satellite network

   stations.



   Protocol packets sent over the satellite network will be

   authenticated and their process will be different as they are

   received by routers.





3.2. The Hello protocol



   We set up the feeds to the highest Router priority on the network in

   order to they become designated routers of their area.



   The Hello protocol normally ensures that communication between

   directly-connected routers is bidirectional. This should be modified

   to allow the Hello protocol to work asymmetrically between feeds and

   receivers connected to the satellite network.



   When sending Hello protocol packets over the satellite network, feeds

   authenticate them as "satellite packet" (set a type field and add a

   specific authentication field).



   Upon reception of these Hello packets, receivers examine the

   authentication code. They note that this packet was sent by a

   satellite feed. They add the packet [IP source] to a list of

   "potential neighbors".



   At pseudo-interval receveirs send Hello packets to the potential

   neighbors. These packets, however, are not sent to the multicast

   address "to all OSPF routers". A copy is sent to the unicast address

   of each potential neighbor. These packets are also authenticated as

   "satellite packet".



   When receiving these Hello packets which are authenticated as

   "satellite packet", feeds will process them even if they are routed

   by another interface.





3.3. Network link record



   The first step of the formation of the shortest path tree is done by

   considering links between routers and transit networks. The network

   links advertisement describes all the routers that are attached to a







Duros                                                           [Page 3]


Internet Draft       Unidirectional links and OSPF            March 1996





   transit network.



   We suggest to extend the network link record to supply further

   information concerning the connected routers. Instead of having just

   a list of connected routers, we may have a list of routers which can

   only send or receive packets (See Figure 2).





                0                               32

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

                |          Network Mask         |

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

                |   Number of Attached Routers  |

                |-------------------------------|- Repeated for

                |        Attached Router        |  each attached

                |-------------------------------|- router

                |               .               |

                |               .               |

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

                |     Number of Senders only    |

                |-------------------------------|- Repeated for

                |        Attached Sender        |  each attached

                |-------------------------------|- sender

                |               .               |

                |               .               |

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

                |    Number of Receivers only   |

                |-------------------------------|- Repeated for

                |       Attached Receiver       |  each attached

                |-------------------------------|- receiver

                |               .               |

                |               .               |

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



                             Figure 2





   Network Mask: The IP network mask for the network.



   Number of Attached Routers: represents the number of routers

      connected to the transit network which can send and receive

      packets. This field is followed by the list of router's ID.



   Number of Senders only: represents the number of routers connected to

      the transit network which can only send packets. This field is

      followed by the list of router's ID.



   Number of Receivers only: represents the number of routers connected







Duros                                                           [Page 4]


Internet Draft       Unidirectional links and OSPF            March 1996





      to the transit network which can only receive packets. This field

      is followed by the list of router's ID.



   Senders and receivers only are detected when a router notices that a

   packet is authenticated as "satellite packet" and also depends on

   which interface it receives it from.



   As implemented in OSPF, a graph is built with the information found

   in the network link record and the router link record. Unidirectional

   communications are represented by a single vertices and thus the

   shortest path tree can de determined handling unidirectional links.





3.4. Processing protocol packets



   All protocol packets (Hello, link state request/update, etc) sent by

   the feeds via the multicast link are authenticated (See section 3.1).



   From the list of "potential neighbors", receivers can find feed's IP

   addresses. They send packet protocols to the unicast address of each

   feed through the regular connection. These packets are also

   authenticated as "satellite packet".



   When receiving these packets which are authenticated as "satellite

   packet", feeds will process them even if they are routed by another

   interface.





References



   [rfc1583] J. Moy,"OSPF Version 2", Request For Comments (RFC) 1583,

             Proteon, Inc., March 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

















Duros                                                           [Page 5]