Internet DRAFT - draft-ietf-rip-unidirectional-link
draft-ietf-rip-unidirectional-link
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 07:03:27 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 09 Aug 1997 05:20:00 GMT
ETag: "2e796d-1745-33ebfe00"
Accept-Ranges: bytes
Content-Length: 5957
Connection: close
Content-Type: text/plain
Network Working Group Emmanuel Duros
Internet-Draft Christian Huitema
INRIA Sophia-Antipolis
March 1996
Handling of unidirectional links with RIP
<draft-ietf-rip-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 RIP
[rfc1723] which make the communication over asymmetric links
feasible.
1. 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.
2. 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.
3. 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]
