INTERNET-DRAFT Y. Guinamand
P. Charron
Document: draft-ietf-udlr-dvmrp-conf-00.txt Alcatel Space
Expires: April 2002 November 2001
Configuration of DVMRP over a UniDirectional Link
<draft-ietf-udlr-dvmrp-conf-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes the configuration of the dynamic multicast
routing protocol DVMRPv3 over a unidirectional link (UDL) such as a
satellite network. Routers connected to the UDL implement a link-
layer tunneling mechanism, as defined in the RFC 3077 [UDLR], in
order to exchange routing information.
Table of Contents
Status of this Memo............................................... 1
Abstract.......................................................... 1
1. Introduction................................................... 2
2. Network architectures.......................................... 2
2.1. Connectivity via the access router of the LAN.................. 2
2.2 Connectivity via PPP............................................ 3
2.3 Connectivity on the same LAN with passive DVMRP mode............ 4
3. DVMRP over a UDL............................................... 5
3.1.1 Requirements................................................. 5
3.1.2 Consequences................................................. 6
3.2 Broadcast and prune mode........................................ 6
3.3 DVMRP scalability issues and passive mode....................... 7
Guinamand & Charron [Page 1]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
4. Domains of application.......................................... 8
4.1 Reliable multicast.............................................. 8
4.2 Teleteaching.................................................... 8
5. References..................................................... 8
6. Author's Addresses............................................. 9
7. Full copyright statement....................................... 9
1. Introduction
Multicast routing on a UDL such as a satellite network seems very
complex because the receiver can not send its routing information to
the feed.
The RFC 3077, which describes a link-layer mechanism to emulate the
full bidirectionality of all nodes connected by a unidirectional
link, allows to connect natively receivers and feeds, emulating the
behaviour of a LAN.
Feeds and receivers can therefore easily exchange their routing
information.
This document describes routing over UDLs in three different network
architectures connecting feeds to receivers and explains how DVMRP
should be configured for each case, considering the characteristics
of the UDL and of the return link.
2. Network architectures
Feed and receivers are connected via a UDL which is a satellite link.
A geostationnary satellite link features a UDL between the feed and
the receivers, a minimum throughput of 2048Kbps up to 48000Kbps and
250ms delay from the feed to the receivers.
A satellite link is extremely well suited for multicast IP. The large
coverage associated to multicast allows to connect the feed to a huge
number of receivers using a modest amount of bandwidth.
The feed is directly connected to DVB/MPEG II [ETSI EN 300 421]
transmission equipments.
Receivers integrate a DVB-S/MPEG satellite reception card (receive-
only interface) with a MAC address of 48 bits, similar to an Ethernet
card.
This reception card supports unicast, broadcast and multicast mode.
The feed and receivers implement the RFC 3077, hence making the UDL
totally transparent for the IP layer.
2.1. Connectivity via the access router of the LAN
In this architecture, the receiver has one receive-only interface and
one Ethernet interface.
Guinamand & Charron [Page 2]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
The receiver uses the Ethernet interface to connect to the LAN on
which workstations and one access router are connected.
GRE traffic is sent to the Feed Bidirectional IP (FBIP) via the
access router of the LAN.
The access router doesn't require any multicast routing abilities.
UniDirectional Link (UDL)
---------->------>-------
| |
---------- ---------
| Feed | | Recv |
---------- ---------
| FBIP |
| |-[WS] -------
^ | | LAN |
| |-[WS] -------
| |
---<----INTERNET-----<-[X]
^
|
|
Access Router
Figure 1 : Connectivity receiver/feed via the access router of the
LAN
2.2 Connectivity via PPP
In this architecture, the receiver has one only-receive interface,
one Ethernet interface and one PPP interface.
The receiver uses the Ethernet interface to connect to the LAN on
which workstations are connected.
The receiver routes IP traffic encapsulated within GRE packets to
FBIP through the PPP interface.
Guinamand & Charron [Page 3]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
UniDirectional Link (UDL)
---------->------>-------
| |
---------- ------------------
| Feed | | Recv | Modem |
---------- ------------------
| FBIP | | PPP connection
| |-[WS] |
| | -------
^ |-[WS] | ISP |
| -------
| |
| |
^ INTERNET
| |
| V
-----<--------------------<----------
GRE traffic
Figure 2 : Connectivity receiver/feed via PPP
2.3 Connectivity on the same LAN with passive DVMRP mode
In this architecture, the feed has its Ethernet interface connected
on the same LAN as the receiver Recv1.
Recv1 has one receive-only interface and one Ethernet interface.
The objective of Recv1 is to send routing information to the feed to
prevent the feed from considering that the satellite network is a
leaf.
This way, the feed sends its routing information because it has one
permanent neighbor.
Recv2 is a router that can switch between the active and the passive
mode (as described in section 3.3) which solves scalability issues,
i.e. it allows a huge number of receivers to listen to the multicast
sessions.
Guinamand & Charron [Page 4]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
Unidirectional Link (UDL)
-------->---------------->-------
| | |
---------- --------- -----------------
| Feed | | Recv1 | | Recv2 | Modem |
---------- --------- -----------------
| FBIP | | | PPP connection
| | -------- |
------------------ LAN of Recv 2 -------
| LAN | ISP |
| -------
| |
[X]----------- INTERNET ------------------
Figure 3 : Connectivity receiver/feed on the same LAN with passive
DVMRP mode
3. DVMRP over a UDL
3.1 Feeds and receivers
DVMRPv3 is running on the feed and on receivers.
While the feed and the receivers are considered to be on the
same LAN, the Designated Querier and Forwarder on the UDL are
elected as defined in respectively IGMPv2 [IGMPv2] and DVMRPv3
[Pusa00].
UniDirectional Link (UDL)
----->---------------------------------
| | |
| | |
-------- --------- ----------
[Feed 1]--------[ Recv1 ]-----[ Recv 2 ]
-------- --------- ----------
| | |
| | |
-----------------------------------------
| Mbone |
-----------------------------------------
Figure 4 : Feeds and receivers over a UDL
3.1.1 Requirements
- The feed is elected as the Designated Querier.
The feed is the closest element from all receivers in term of
transmission duration.
To ensure that all queries are well centralized on the feed, it must
be elected as the Designated Querier.
Guinamand & Charron [Page 5]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
- In the architecture described in section 2.3, the feed has to be
elected as the Designated Forwarder.
Let's consider a source connected on the BiDirectional Link (BDL).
If a receiver was designated as a Forwarder, the receiver would
encapsulate data into the UDLR tunnel and data would be reinjected in
the UDL by the feed.
To prevent such a situation, the feed has to be elected as the
Designated Forwarder.
- All active receivers are considered as DVMRP neighbors.
3.1.2 Consequences
- The feed has the smallest IP address on the UDL.
(Querier election mechanism as described in IGMPv2)
- In the architecture described in section 2.3, i.e. the feed is the
cheapest route between the LAN and the UDL.
(Designated forwarder election mechanism as described in DVMRPv3
section 2.4)
- The feed is the default MBone connection for the satellite network.
- All active receivers have a return link channel up.
A receiver configured in passive mode routing without a return link
channel won't be able to contribute to any multicast sessions and
won't route multicast traffic coming from the UDL to its LAN.
3.2 Broadcast and prune mode
DVMRP is based on "broadcast and prune" mode, ie the DVMRP router
initially floods datagrams out of all dependent downstream interfaces
and then stops flooding when it has received prune messages from all
downstream routers.
On a UDL, it is primordial to ensure that the upstream router
receives all prune messages from its downstream routers.
If a prune message is lost, useless traffic continues to be forwarded
and hence wastes bandwidth.
The network architectures described in sections 2.1 and 2.2 show that
the links connecting receivers to feeds are very different than links
connecting a LAN.
Indeed, these links cross many routers in the Internet, which
increases dramatically the loss rate and therefore the probability to
loose a prune message.
For this reason, prunes must be retransmitted using binary
exponential back-off during the lifetime of the prune if traffic is
still arriving on the upstream interface.
The algorithm is described in [Pusa00], section 3.5.5
Guinamand & Charron [Page 6]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
Example:
Add "rexmit_prunes on" for the UDL interface of each receiver in
the mrouted configuration file (implementation of DVMRPv3)
3.3 DVMRP scalability issues and passive mode
DVMRP routers multicast Probe messages to locate each other.
As a DVMRP router sees Probe messages from its DVMRP neighbors, it
records the neighbor addresses in its routing table.
The fact that all receivers are DVMRP neighbors on the UDL increases
dramatically the DVMRP traffic and the size of routing tables with
the exchange of DVMRP Reports.
Example:
The mrouted implementation of DVMRPv3 supports only 64 neighbors.
A solution is to configure the DVMRP routers in passive mode.
In this configuration, the downstream router won't send any DVMRP
Probes or DVMRP Reports.
A UDL such as a satellite network is a flat architecture in which the
feed may have more than 64 neighbors.
The Probe messages sent periodically by DVMRP routers keep the PPP
connection alive until there is no more a member of a multicast
session behind a receiver.
Some modification of the implementation of DVMRPv3 making the router
act passive can allow the connection of more than 64 receivers and
can hence save the cost of a return channel.
Receivers will route multicast datagrams from the UDL to the LAN on
which they are connected without sending any information to the
upstream router.
This allows to save bandwidth: end-users on LANs behind a receiver
are able to receive the multicast datagrams without using a return
channel.
Only contributions to multicast sessions require switching to active
routing mode.
The passive routing configuration is possible only if the upstream
router is considered as a valid source, i.e. the upstream router
sends its Reverse Path Forwarding (RPF) information.
The upstream router (the feed) sends its RPF tables only if there is
at least one active DVMRP receiver on the network.
One active receiver is therefore mandatory to use passive routing
mode on the UDL.
Indeed, a program such as mtest (to join a multicast session on the
UDL interface) without any active receiver manages to send multicast
datagrams to the UDL.
Guinamand & Charron [Page 7]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
But it is not enough because receivers will not forward these
datagrams as they don't receive the RPF tables of the upstream
router.
4. Domains of application
The purpose of this section is to describe two kinds of application
wherein dynamic multicast routing over a UDL presents a lot of
benefits.
4.1 Reliable multicast
RFC 3077 is very well suited for applications based on reliable
multicast in push mode.
Receivers send multicast ACKS and NACKs via the UDLR tunnel.
Each receiver is aware of each other's status and will not ask for a
retransmission of packets if another receiver already asked for these
same packets.
Dynamic multicast routing over a UDL allows a perfect coordination
between receivers.
4.2 Teleteaching
For this application, receivers are configured in passive mode.
They receive teleteaching multicast sessions on their receive-only
interface and route them through their Ethernet interface on the
corporate LAN.
Every workstation connected on the LAN receives the multicast
session.
Switching to active mode is obviously required if a member wishes to
contribute to the session.
5. References
[UDLR] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang, "A
Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077,
March 2001
[Pusa00] T. Pusateri, "Distance Vector Multicast Routing Protocol"
,2000
[IGMPv2] W. Fenner, " Internet Group Management Protocol, Version 2",
RFC 2236, November 1997
[ETSI EN 300 421] "Digital Video Broadcasting (DVB), Framing
structure, channel coding and modulation for 11/12 GHz satellite
services"
Guinamand & Charron [Page 8]
INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001
6. Author's Addresses
Yann Guinamand
Alcatel Space Industries
100, Bd du Midi
06156 Cannes la Bocca Cedex
France
Phone: (+33) 4 92 92 66 02
EMail : yann.guinamand@space.alcatel.fr
Philippe Charron
Alcatel Space Industries
100, Bd du Midi
06156 Cannes la Bocca Cedex
France
Phone: (+33) 4 92 92 79 89
Email: philippe.charron@space.alcatel.fr
7. Full copyright statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
