Internet DRAFT - draft-ietf-dvmrp-unidirectional-link
draft-ietf-dvmrp-unidirectional-link
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 02:15:41 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 09 Aug 1997 05:19:58 GMT
ETag: "2e7969-1e5e-33ebfdfe"
Accept-Ranges: bytes
Content-Length: 7774
Connection: close
Content-Type: text/plain
Network Working Group Emmanuel Duros
Internet-Draft Walid Dabbous
INRIA Sophia-Antipolis
March 1996
Handling of unidirectional links with DVMRP
<draft-ietf-dvmrp-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 DVMRP
[rfc1075] which make the communication over asymmetric links
feasible.
1. Introduction
DVMRP is a distance-vector-style routing protocol for routing
multicast datagrams through the internet. It was designed to work on
networks where adjacent gateways routing multicast datagrams
communicate using the same link in both directions. In case links are
unidirectional, DVMRP can not be used without modifications.
2. Overcoming DVMRP restrictions
Duros & Dabbous [Page 1]
Internet Draft Unidirectional links and DVMRP March 1996
A satellite network comprises two sets of stations, feeds that can
both send and receive multicast packets, and receivers that can only
receive packets.
Feeds must be allowed to forward over the satellite links the
multicast 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 routing messages to the feeds to supply routing
information, recently changed routes or responses to requests.
If the network included only feeds, DVMRP could be used 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) and support
multicast routing. G3 and G4 also support multicast routing and are
connected to symmetric networks.
route N1 ----
N2 ---- ----<==========>|G3|<==---
---======>|G1| ===================> |G2| ---- ----
---- update msg ----<===>|G4|<==--
/\ /\ ----
|| ------------------ ||
====| regular |====
N3 | connections | N4
------------------
Figure 1
G1 will send routing messages to G2 multicast to address 224.0.0.4..
G1 will never receive messages from G2 via route N1, DVMRP must be
modified to take into account that asymmetry.
3.1. Adding information to DVMRP datagrams
DVMRP datagrams are composed of two portions: a small, fixed length
IGMP header, and a stream of tagged data. The stream is composed of
commands. We suggest to modify a command in order to provide a way to
authenticate a route taken by a datagram as part of the satellite
Duros & Dabbous [Page 2]
Internet Draft Unidirectional links and DVMRP March 1996
network.
The Flag0 command provides a way to set a number of flags.
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 5 | | value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Meaning of bits in value:
Bit 7: Destination is unreachable.
Bit 6: Split Horizon concealed route.
Default: All bits zero.
Bits 0 to 5 are unused, for our needs we propose to set the bit 5,
this specifying that the link is unidirectional. By default bit 5
would be unset.
Any DVMRP datagram sent by multicast feeds over the satellite network
will be authenticated.
Any multicast router connected to the satellite network (feeds and
receivers) have to support that functionality when they process
routing datagrams. Other multicast routers will simply ignore this
extra flag and the process of DVMRP datagram will not be affected.
3.2. Handling by receivers
Upon reception of a DVMRP packet, receivers examine the flag0 command
and note that this packet was sent by a satellite feed (bit 5 set).
They add the packet address [IP source] to a list of "potential
feeds".
Receivers behave "as if" their virtual interface connected to the
satellite network can transmit packets. This way, the shortest
reverse path tree can be computed by the receivers with the metric
associated to the satellite link.
At pseudo-regular intervals, receivers will send to the feeds a DVMRP
packet. This packet, however, will not be sent to the multicast
address of the feed. A copy of this packet will be sent to the
unicast address of each feed found in the list of "potential feeds"
through regular connections.
Duros & Dabbous [Page 3]
Internet Draft Unidirectional links and DVMRP March 1996
Every FULL_UPDATE_RATE seconds routers normally send out DVMRP
messages to all of their virtual interfaces with all of their routing
information. Receivers will propagate routing information about the
destination addresses "reachable" via the virtual interfaces
connected to the satellite network. Thus, routers (i.e. G3 and G4,
see Figure 1) can compute the shortest reverse path tree to the
source address of a multicast packet even if there is no real path.
This procedure assumes that there is another route, beside the
satellite link, by which the receiver can send packets to the feed
(See Figure 1).
3.3. Processing by feeds
Any routing message sent over the multicast link (satellite network)
is authenticated adding the Flag0 command and setting the bit 5.
All incoming unicast packets are processed even if they were not
tunneled or sent to a multicast address.
References
[rfc1075] S. Deering, C. Partridge, D. Waitzman, "Distance Vector
Multicast Routing Protocol", November 1988.
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
Walid Dabbous
INRIA Sophia Antipolis
2004, Route des Lucioles BP 93
06902 Sophia Antipolis CEDEX France
Email : Walid.Dabbous@sophia.inria.fr
Phone : +33 93 65 77 18
Duros & Dabbous [Page 4]
