Network Working Group Emmanuel Duros Internet-Draft INRIA Sophia-Antipolis March 1996 Handling of unidirectional links with OSPF 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]