[Docs] [txt|pdf] [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-ospf-unidirectional-link-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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/