Internet-Draft Y. Guinamand
P. Charron
Document: draft-ietf-udlr-dvmrp-conf-01.txt Alcatel Space
Expires: April 2002 November 2001
Configuration of DVMRP over a UniDirectional Link
<draft-ietf-udlr-dvmrp-conf-01.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.................3
2.2. Connectivity via PPP..........................................3
2.3. Connectivity on the same LAN with passive DVMRP mode..........4
2.4. MBone connectivity via 2 access points : the UDL and the LAN..5
Guinamand, Charron [Page 1]
Internet Draft Configuration of DVMRP over a UDL November 2001
3. DVMRP over a UDL................................................7
3.1. Feeds and receivers...........................................7
3.1.1. Requirements................................................8
3.1.2. Consequences................................................8
3.2. Broadcast and prune mode......................................8
3.3. DVMRP scalability issues and passive mode.....................9
4. Domains of application.........................................10
4.1. Reliable multicast...........................................10
4.2. Teleteaching.................................................10
5. Acknowledgements...............................................11
6. References.....................................................11
7. Author's adresses..............................................11
8. Full copyright statement.......................................12
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 four 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.
Guinamand, Charron [Page 2]
Internet Draft Configuration of DVMRP over a UDL November 2001
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.
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
2.4 MBone connectivity via 2 access points : the UDL and the LAN
A feed is connected to the MBone/Internet and can forward
multicast traffic over the UDL.
IGMP and DVMRP messages come from receivers through the GRE
tunnels.
Receivers are connected to the UDL and also to a LAN which
already has MBone connectivity.
Receivers send routing information through the GRE tunnels to the
feed.
A client located on a remote LAN can receive multicast traffic
either from the UDL (e.g. a satellite link) or from the
"terrestrial" network.
Guinamand, Charron [Page 5]
Internet Draft Configuration of DVMRP over a UDL November 2001
UniDirectional Link (UDL)
---->------------------------>----
| |
| |
---------- -----------
| Feed | | Recv1 |
A ---------- ----------- C
| | | |
---------------- LAN 1 LAN 2 -----------------------
| |
---- ----
|R1| |R2|
---- ---- B
| | |
----------------------------------------------------------
| Internet / MBone |
----------------------------------------------------------
Figure 4 : MBone connectivity via 2 access points
In the architecture described in the figure 4 :
The Feed and Recv1 are neigbor DVMRP routers
R1 (respectively R2) is a multicast router connected to the MBone
that communicates with the Feed
A and B are 2 multicast sources which transmit on the same multicast
group. C located on LAN2 joins this group.
From A, the multicast traffic is routed over the MBone cloud and
through R2 to reach the client.
In both cases, the shortest path is chosen to route the traffic
between the source and the destinaton. Routing operates here in an
optimal way.
When C starts generating multicast traffic :
1) to B : this traffic is routed through R2 and through the MBone.
2) to A : this traffic would normally be routed through Recv1 and
the feed because DVMRP thinks that C is only 2 hopes away from A.
In fact, the multicast traffic would go from C to Recv1, then
encapsulated within GRE packets, would go through the Internet up
to the Feed and then forwarded over LAN1.
Guinamand, Charron [Page 6]
Internet Draft Configuration of DVMRP over a UDL November 2001
This is not the optimal way to route traffic from LAN2 to LAN1
because the multicast traffic would be forwarded in a GRE tunnel
between Recv1 and the Feed over the Internet, whereas it could be
natively and optimally routed in multicast between R2 and R1 over
the MBone.
Furthermore, the GRE encapsulation adds extra overhead useless here.
To route the multicast traffic from LAN2 to LAN1 over the MBone and
not within the GRE tunnel, DVMRP has to be configured on the
receiver.
The solution is to set an infinite metric to the bidirectional
interface of the receiver.
As a result, the receiver cannot compute the shortest path to a
source via its bidirectional interface and then, cannot forward
the traffic over the UDL.
Furthermore, a receiver cannot announce valid routes to the feed
since they would all have infinite metrics.
The feed cannot compute any reverse path back through these
receivers.
Hence, it is not possible for the multicast traffic to come from
the UDL but it flows from the terrestrial network to LAN1.
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 5 : Feeds and receivers over a UDL
Guinamand, Charron [Page 7]
Internet Draft Configuration of DVMRP over a UDL November 2001
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.
- The feed has to be elected as the Designated Forwarder.
The feed forwards data over the UDL.
A receiver must not be elected as a Designated Forwarder to avoid
that data are encapsulated into the link-layer tunneling mechanism
up to the feed and then reforwarded over the UDL.
- 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)
- 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
Guinamand, Charron [Page 8]
Internet Draft Configuration of DVMRP over a UDL November 2001
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
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 establish 2 way neighbor
adjacency.
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.
The general idea of the passive mode is to allow a receiver to
forward multicast traffic from the UDL over the LAN without
establishing a 2 way relationship with a feed.
There are several reasons for that :
- A UDL such as a satellite network is a flat architecture in which
the feed may have more than 64 neighbors.
The passive mode allows more than 64 receivers.
- 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.
Receivers will route multicast datagrams from the UDL to the LAN on
which they are connected without sending any information to the
upstream router.
The passive mode hence saves the cost of a return channel :
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.
A DVMRP router sends routing information or route reports which are
used for determining the reverse path neighbor back to the source of
the multicast traffic.
Guinamand, Charron [Page 9]
Internet Draft Configuration of DVMRP over a UDL November 2001
The feed will send these information only if at least one receiver
is configured in active DVMRP mode.
Indeed, an application that sends join messages for specific
multicast groups over the UDL without any active receiver manages to
send multicast datagrams to the UDL.
But it is not enough because receivers will not forward these
datagrams as they don't receive the routing information or route
reports 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
[UDLR] is very well suited for applications based on reliable
multicast in push mode.
A multicast push server is connected to the feed.
A set of multicast push clients on the remote sites are connected
to the UDL.
Multicast datagrams from the push server are routed over the UDL as
soon as one client joins the multicast group.
In case of packet losses, push clients send back NACKs to the push
server to ask for retransmission.
These requests are sent in multicast and relayed by the receiver
through the link-layer tunneling mechanism up to the feed.
This provides a mechanism for push client to refrain from asking
retransmission of packet which were already requested by another
client.
A such mechanism is very well suited when a large number of clients
detect the same packets loss.
It avoids an implosion of request messages at the server.
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 host connected on the LAN receives the multicast session.
Switching to active mode is obviously required if a member wishes to
Guinamand, Charron [Page 10]
Internet Draft Configuration of DVMRP over a UDL November 2001
contribute to the session.
A multicast IP address can be defined in the DVMRP router's
configuration to allow to switch between active and passive mode.
Indeed, if a host on the corporate LAN joins this multicast IP
address, the DVMRP router automatically switches to active mode.
It switches back to passive mode as soon as no more member of this
multicast group is present.
5. Acknowledgements
We would like to thank Emmanuel Duros for his technical inputs,
especially for the section 2.4 he provided.
6. 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"
7. 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
Guinamand, Charron [Page 11]
Internet Draft Configuration of DVMRP over a UDL November 2001
8. 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.
Guinamand, Charron [Page 12]
