Internet DRAFT - draft-ietf-ospf-unidirectional-link
draft-ietf-ospf-unidirectional-link
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 06:06:45 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 09 Aug 1997 05:19:59 GMT
ETag: "2e796b-285a-33ebfdff"
Accept-Ranges: bytes
Content-Length: 10330
Connection: close
Content-Type: text/plain
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]
