C. Benassy-Foch
P. Charron
Internet Draft Y. Guinamand
Document: draft-ietf-udlr-dvmrp-conf-03.txt Alcatel Space
Expires: December 2002 June 2002
Configuration of DVMRP over a UniDirectional Link
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
Routers connected to a UniDirectional Link (UDL) such as a
satellite network, implement a link layer tunneling mechanism, as
defined in the RFC 3077 [UDLR]. These routers could exchange
multicast routing information. This document describes how DVMRPv3
works on this network architecture and suggests a different
configuration of DVMRPv3 on routers connected to the UDL more
adapted and optimized to this network architecture.
Table of Contents
Status of this Memo..............................................1
Abstract.........................................................1
1. Introduction..................................................2
2. DVMRPv3 over a UDL............................................2
2.1 Network architecture.........................................2
2.2 DVMRPv3 implementation.......................................3
2.3 Active mode configuration on receivers.......................3
2.3.1 Feed configuration and behavior............................4
2.3.2 Receiver configuration and behavior........................4
2.3.3 Scalability issue of DVMRP.................................5
Configuration of DVMRP over a UDL June 2002
2.4 Passive mode configuration on receivers......................6
2.4.1 Feed configuration and behavior............................6
2.4.2 Receiver configuration and behavior........................7
2.5 When and How to switch between active and passive mode.......7
3. Domains of application........................................8
3.1 Application using a Reliable Multicast Transport Protocol....8
3.2 Multicast application with interactivity.....................8
4. Others network architectures..................................9
4.1 Connectivity on the same LAN as the Feed....................10
4.2 Mbone connectivity via two access points: the UDL and the LAN11
5. Acknowledgements.............................................12
6. References...................................................12
7. Author's Addresses...........................................13
8. Full copyright statement.....................................13
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 bi-directionality of all nodes connected by a unidirectional
link, allows to connect natively receivers and feeds, emulating the
behavior of a LAN. Feeds and receivers can therefore easily
exchange their routing information. DVMRPv3 could be used as
multicast routing protocol on this network.
2. DVMRPv3 over a UDL
2.1 Network architecture
Feed and receivers are connected via a UDL, which is a satellite
link. A geostationnary link features a UDL between the feed and
receivers, a minimum throughput of 2048Kbps up to 48000Kbps and a
250ms delay from the feed to 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-2 [ETSI EN 300 421]
transmission equipment. 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 receiver implement the RFC 3077, hence making the UDL
totally transparent for the IP layer.
Informational - Expires December 2002 2
Configuration of DVMRP over a UDL June 2002
UniDirectional Link (UDL)
+-------->--------->------------>-----+
| | |
-------- -------- --------
| Feed | |Recv 1| |Recv 2|
-------- -------- --------
| | | |
| Workstation [WS]--| | |--[WS]
| |--[WS] | | LAN
| LAN | | |--[WS]
| | |
| v v
| | -------
| Access router [X] |modem| PPP
| | -------
| | |
+-------+ | | -------
| MBONE |--[X] Router | | ISP |
+-------+ | | -------
| | |
| +--------+ v v
+---<----|INTERNET|--<---+----<-------+
+--------+
Figure 1: Connectivity feed/receiver via an access router or a PPP
connection.
The Feed is connected to the MBONE and to the INTERNET. So it can
forward multicast traffic over the UDL.
Receivers have an Ethernet interface to connect to a LAN on which
workstations are connected. The LAN is connected to the INTERNET
via an access router (which does not have multicast routing
ability) or via a PPP connection. Receivers route IP traffic
encapsulated into GRE packets to the bi-directional interface of
the Feed.
2.2 DVMRPv3 implementation
DVMRPv3 is running on the feed and receivers. The feed and
receivers are DVMRP routers. In the experiment the DVMRPv3
implementation is mrouted 3.9b3. Feed and receivers run FreeBSD
3.4-RELEASE.
2.3 Active mode configuration on receivers
The feed and receivers are DVMRP routers. In active mode feed and
receivers have a standard DVMRPv3 implementation(mrouted 3.9b3).
A return link channel is necessary for receivers to exchange DVMRP
messages. Thanks to the Link Layer Tunneling Mechanism, feed and
receivers are considered to be on the same LAN. Thus they are DVMRP
neighbor routers.
Informational - Expires December 2002 3
Configuration of DVMRP over a UDL June 2002
2.3.1 Feed configuration and behavior
Feed configuration:
The feed is the only DVMRP router of the LAN having access to the
MBONE. The feed must be elected as the Designated Forwarder
[Pusa00] on the UDL to forward multicast data over the UDL.
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 has to be elected as the Designated
Querier as defined in IGMPv2 [IGMPv2]. It needs to have the
smallest IP address on the UDL.
Feed behavior:
The feed periodically sends Probe messages over the UDL to discover
DVMRP neighbor routers. These messages contain the list of neighbor
router addresses.
Upon reception of a Probe message from a receiver via the GRE
tunnel, the feed updates its list of neighbors. If its address is
included into this report message, the feed establishes a two-way
neighbor adjacency with this receiver.
As the feed has DVMRP neighbor routers on the UDL, it sends route
information into Report messages over the UDL. A Report message
contains the list of source networks and the associated metrics.
It enables routers to determine the Reverse Path neighbor back to
the source of the multicast traffic.
These two DVMRP messages use a reserved multicast IP address (ALL-
DVMRP-ROUTERS) and have a TTL set to 1.
Upon reception of multicast traffic from the MBONE the feed will
broadcast traffic over the UDL and will stop flooding it when it
receives Prune messages from all downstream routers(all receivers).
2.3.2 Receiver configuration and behavior
Receiver configuration:
Receivers are standard DVMRP routers. The return link channel is
used to exchange DVMRP messages.
In this network architecture 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 GRE tunnel between
receivers and the feed crosses many routers in the INTERNET.
Therefore it dramatically increases the probability to lose a Prune
message.
Informational - Expires December 2002 4
Configuration of DVMRP over a UDL June 2002
For this reason Prune message must be transmitted using a binary
exponential back-off during the lifetime of the Prune message if
the traffic is still arriving on the upstream interface. This
algorithm is described in [Pusa00] section 3.5.5.
Example of configuration using mrouted (implementation of DVMRP):
Add "rexmit_prunes on"
Receiver behavior:
Receivers send Probe messages to discover others DVMRP routers.
Probe messages are encapsulated into the GRE tunnel and forwarded
to the feed. Receivers consider the feed as a DVMRP neighbor
router.
Then receivers send Report messages to the Feed via the GRE tunnel.
When the feed broadcast multicast data over the UDL, Receivers uses
the DVMRP routing table to determine if the traffic should be or
not forwarded to their Ethernet interfaces. First receivers check
if the incoming interface is the upstream interface of the data.
Secondly the multicast traffic is forwarded to downstream
interfaces as indicated into the DVMRP routing table. If there is
no downstream interface, the receiver sends a Prune message to the
upstream routeur via the GRE tunnel. After the receiver will send a
Graft message to the upstream router if the list of downstream
interfaces associated to this traffic is not any more empty.
2.3.3 Scalability issue of DVMRP
There are two main factors that limit the scalability of DVMRP over
a UDL.
First, the number of Probe messages periodically exchanged between
receivers and the feed is proportional to the number of receivers
connected to the UDL. The period is 10s. The size of Probe message
depends on the number of DVMRP routers.
In case of many receivers connected to the LAN, the DVMRP traffic
will dramatically increase on the UDL.
For example: A UDL with a feed and 70 receivers
The feed would receive 70 Probe messages every 10s. The Feed would
send a probe message over the UDL containing 70 IP addresses every
10s too. The size of this Probe message would be 292 Bytes (the IP
header would be 24 Bytes because of the IP router Alert option then
the IP packet would be 316 Bytes)(the maximum size is 576 Bytes
including IP header).
DVMRP implementations can support a limited number of DVMRP
neighbors. For instance in mrouted implementation (mrouted 3.9b3)
the maximum number of DVMRP neighbors is 64. A satellite UDL allows
more than 64 receivers.
In addition, Report messages are sent over the UDL. A router sends
a Report message every 60s in multicast and sends a Report message
Informational - Expires December 2002 5
Configuration of DVMRP over a UDL June 2002
in unicast when a new neighbor router is discovered (reception of a
Probe message with its own address into the list of neighbor
addresses). To prevent an implosion of Report messages, the sending
of Report messages is spread out across the report interval. So
each receiver would send a Report message every 60s to the Feed via
the GRE tunnel.
The return link channel will be loaded by DVMRP Messages. To enable
receivers connected to the UDL to forward multicast traffic without
a return link channel, Receivers could be configured in passive
mode.
2.4 Passive mode configuration on receivers
When the UDL is for example a satellite link, the number of
receivers easily overloads the capabilities of DVMRP. To avoid
this, the chosen solution is to implement a passive mode in the
standard implementation of DVMRP. This mode allows the mrouted
implementation to forward a valid multicast source from the UDL to
the lan of receivers without sending any information to the
upstream router (the feed)(the return link channel is not used).
A change is required on the DVMRP implementation used on receivers:
a new parameter has to be added into the implementation. It is
detailled in the section 2.3.2 (Receiver configuration and
behavior).
In this mode, receivers get from the feed the Multicast streams and
the RPF tables (contained into Report messages). The standard
implementation of multicast routing table is not modified, so
receivers need the RPF information to choose the feed as a valid
upstream router for the Multicast sessions they receives. This is
mandatory to avoid the creation of routing loop.
Without this RPF information receivers are not able to forward a
source from the feed to the lan. As described in the DVMRPv3
[Pusa00] a DVMRP router will send RPF information on an interface
only if there is at least one neighbor on this interface.
According to this, the feed must have at least one DVMRP neighbor
router on the UDL. So at least one receiver must be in active mode.
This active receiver will send Probe message to the feed via the
GRE tunnel and the feed will send over the UDL route information.
2.4.1 Feed configuration and behavior
The implementation of the multicast routing daemon is unmodified
into the feed. The feed configuration is the same as the one when
receivers are in active mode. The feed does not require any
modification to allow receivers to run in passive mode.
As the multicast routing algorithm is not modify, the feed must
receive a join IGMP message in order to forward a multicast session
on the UDL. An internal application could be developed to send a
Informational - Expires December 2002 6
Configuration of DVMRP over a UDL June 2002
join message on the UDL interface of the Feed. This internal
application might be based on a mtest program.
For instance, it is interesting to configure the Feed to forward
advertisement of multicast sessions via the Session Announcement
Protocol [SAP] and multicast sessions about hot topics.
2.4.2 Receiver configuration and behavior
To support the passive mode receivers has to accept a new parameter
in their DVMRP configuration file (mrouted 3.9b3). The LAN
interface must contain the new parameter "switch_uni_bi
<group_ip_address>". This <group ip address > is not a multicast
group address related to a multicast group session. This address is
dedicated to the configuration of the Receiver on the LAN
interface.
In addition the UDL interface of the passive receiver must be
declared as "one_way".
This is an example of a default receiver configuration file:
Phyint dvb0 # UDL Interface
Threshold 8
Boundary LOCAL
One_way
Phyint eth0 # Lan Interface
Switch_uni_bi 224.5.6.7
In this configuration the receiver is launched in passive mode and
only forwards the valid sources it has received to its lan
interface.
"Valid sources" means multicast data from a source having not an
empty list of downstream interfaces into the routing table.
As described in the DVMRP protocol [Pusa00] the feed will send
Report messages needed to calculate the Reverse Path neighbor back
to the source of a multicast traffic, only if there is at least one
valid neighbors on the UDL.
This means you need to have all the time an active receiver on your
UDL. Section 4.1 of this document present a solution to this
problem.
2.5 When and How to switch between active and passive mode
In the experiment the passive mode is the default configuration of
receiver.
A receiver needs to switch to active mode when it has subscribers
on its LAN to a multicast session that is not forwarded by the Feed
over the UDL at this moment(all other active receivers have sent a
prune message).
Informational - Expires June 2002 7
Configuration of DVMRP over a UDL December 2002
When a end-user on the LAN wishes to participate to a multicast
session (to send multicast data), a receiver has to switch to
active mode too.
To switch to active mode, someone on the LAN must send a join
message to the session defined by the <group_ip_address>, the
groupe IP address of the æswitch_uni_biÆ parameter (here 224.5.6.7
in the example). Upon reception of an IGMP join on the lan
interface to this specific group address the receiver switches to
active mode.
The receiver will work in active mode until there is no more
members for the æswitch_uni_biÆ session, and will automaticaly
return to passive mode as it does not receive any more IGMP join
for this session.
3. Domains of application
The purpose of this section is to describe two kinds of
applications wherein dynamic multicast routing over a UDL presents
a lot of benefits.
3.1 Application using a Reliable Multicast Transport Protocol
[UDLR] is very well suited for applications using Reliable
Multicast Transport protocol based on Negative-ACKnowledgment.
A multicast push server is connected to the feed, which forwards
multicast data over the UDL to receivers. A receiver who is missing
data packets could send a NACK in multicast to the push server.
This retransmission request is relayed by the GRE tunnel to the
feed. It forwards the request to the push server and on the UDL
too. Upon reception of the NACK, the push sender retransmits the
requested packet. Then this requested packet is sent by the Feed
over the UDL. Other receivers connected to the UDL will receive the
missing packet. As the feed has forwarded the NACK request on the
UDL receivers have suppressed the sending of the same NACK.
This NACK suppression mechanism is easy to implement over a UDL. It
can be scaled to a large number of receivers and it reduces the use
of the return channel link.
With such a reliable multicast transport protocol based on NACK
some receivers on the UDL could be in active mode to send
retransmission request to the push server. Other receivers
connected to the UDL on passive mode will receive missing packet
without sending any request. These two modes on receivers will
improve the NACK suppression mechanism.
The application will offer a better service (a reliable transport
service) without overloading return channel links of receivers.
3.2 Multicast application with interactivity
Applications such as tele-teaching and collaborative work require a
main multicast flow from a main source to end-users (to deliver a
Informational - Expires December 2002 8
Configuration of DVMRP over a UDL June 2002
course or a lecture) and several minor flows from end-users to the
main source and other end-users (questions and remarks from end-
users).
For these applications, end-users are on the LAN interface of
passive receivers and they have joined the multicast session (they
have sent an IGMP report message for the session group address).
Passive receivers forward multicast session data to their LAN
interfaces.
If an end-user wishes to participate to the multicast session (for
instance, asking a question), the receiver must switch to active
mode. The return link channel will be set up. DVMRP messages will
be sent via the GRE tunnel to the feed and multicast data will be
forwarded via the GRE tunnel over the UDL.
After if no more end-user wishes to participate, the receiver will
switch back to passive mode.
Receivers in passive mode could listen multicast session without
sending DVMRP messages, hence without using their return link
channels. However they can participate multicast session by
switching to active mode. The use of the return link is optimized.
4. Others network architectures
This section proposes other network architectures well-adapted to
these two modes of configuration. These networks are based on a UDL
and a return channel link implementing the Link Layer Tunneling
Mechanism [UDLR]. The first architecture suggests a solution for an
operator of such a network to always have an active receiver
connected to the UDL under its control. In the second architecture,
a receiver has an access to the Mbone as the Feed has. In this case
the GRE tunnel is not worth forwarding multicast message to the
Feed or to a multicast source, it is better to forward these
multicast messages through the Mbone. To solve that, a
configuration of the DVMRP router included into the receiver is
proposed.
Informational - Expires December 2002 9
Configuration of DVMRP over a UDL June 2002
4.1 Connectivity on the same LAN as the Feed
UniDirectional Link (UDL)
+-------->------------>-----+
| | |
-------- -------- --------
| Feed | |Recv 1| |Recv 2|
-------- -------- --------
| | | | Workstations
| [WS]--| | | LAN
| |--[WS] | |--[WS]
LAN +--------------+ |
| v
| -------
Router [X] |modem| PPP
| -------
| |
+-------+ | -------
| MBONE |--[X] Router | ISP |
+-------+ | -------
| |
| +--------+ v
+----<---|INTERNET|---<----+
+--------+
Figure 2: Connectivity feed/receiver on the same LAN
In this architecture, the feed has its Ethernet interface connected
on the same LAN as the receiver Recv 1. Recv 1 has a receive-only
interface and an Ethernet interface.
The Recv1 must not forward traffic to the UDL, the feed must be the
Designated Forwarder. So the feed must have the cheapest route
between the LAN of the Feed and the UDL.
Example of configuration with mrouted:
# fl0: The LAN interface of the feed
phyint fl0 metric 1 threshold 1
# r1l0: The LAN interface of the recv 1
phyint r1l0 metric 10 threshold 20
Recv 1 should be in active mode. In this case the feed has a
permanent DVMRP neighbor router. Thus the feed will continue to
send Report messages over the UDL, and all other receivers
connected to the UDL will be able to determine the Reverse Path
neighbor back to the source of a multicast traffic.
Recv 2 could be in passive mode if it wants to receive multicast
traffic. If it wishes to become a multicast source, it has to
switch to active mode.
Informational - Expires December 2002 10
Configuration of DVMRP over a UDL June 2002
With this network architecture, there is at least one receiver in
active mode on the UDL allowing a huge number of passive receivers
to listen multicast sessions.
4.2 Mbone connectivity via two 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.
UniDirectional Link (UDL)
---->------------------------>----
| |
| |
---------- -----------
| Feed | | Recv1 |
A ---------- ----------- C
| | | |
---------------- LAN 1 LAN 2 -----------------------
| |
---- ----
|R1| |R2|
---- ---- B
| | |
----------------------------------------------------------
| Internet / MBone |
----------------------------------------------------------
Figure 3 : MBone connectivity via 2 access points
In the architecture described in the figure 3 : The Feed and Recv1
are neighbor 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 destination. Routing operates here in an
optimal way.
When C starts generating multicast traffic :
Informational - Expires December 2002 11
Configuration of DVMRP over a UDL June 2002
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.
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 bi-
directional interface of the receiver.
As a result, the receiver cannot compute the shortest path to a
source via its bi-directional 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.
5. Acknowledgements
We would like to thank Emmanuel Duros for his technical inputs,
especially for the section 4.2, and all UDLR WG members for their
comments.
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
Informational - Expires December 2002 12
Configuration of DVMRP over a UDL June 2002
services"
[SAP] M. Handley, C. Perkins, E. Whelan, "Session Annoucement
Protocol", October 2000
7. Author's Addresses
Celine Benassy-Foch
Alcatel Space Industries
26 av. J.F. Champollion
31037 Toulouse Cedex
France
Phone: (+33) 5 34 35 39 34
Email: celine.benassy@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
Yann Guinamand
166 rue du President Wilson
92 300 Levallois Perret
France
Phone: (+33) 6 73 48 23 26
Email : yann@guinamand.com
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
Informational - Expires December 2002 13
Configuration of DVMRP over a UDL June 2002
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.
Informational - Expires December 2002 14
Datatracker
Report a datatracker bug
draft-ietf-udlr-dvmrp-conf-03
None
| Document | Document type |
Expired Internet-Draft
(udlr WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors |
Celine Benassy-Foch
,
Philippe Charron
,
Yann Guinamand
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |