C. Benassy-Foch
P. Charron
Internet Draft Y. Guinamand
Document: draft-ietf-udlr-dvmrp-conf-02.txt Alcatel Space
Expires: July 2002 February 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
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. DVMRPv3 over a UDL............................................2
2.1 Network architecture.........................................2
2.2 Active mode configuration on receivers.......................3
2.2.1 Feed configuration and behavior............................3
2.2.2 Receiver configuration and behavior........................4
2.2.3 Scalability issue of DVMRP.................................5
2.3 Passive mode configuration on receivers......................6
2.3.1 Feed configuration and behavior............................6
2.3.2 Receiver configuration and behavior........................6
Configuration of DVMRP over a UDL February 2002
2.4 How to switch between active and passive mode................7
3. Domains of application........................................7
3.1 Application using a Reliable Multicast Transport Protocol....7
3.2 Multicast application with interactivity.....................8
4. Others network architectures..................................9
4.1 Connectivity on the same LAN as the Feed.....................9
4.2 Mbone connectivity via two access points: the UDL and the LAN10
5. Acknowledgements.............................................11
6. References...................................................11
7. Author's Addresses...........................................12
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 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.
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 July 2002 2
Configuration of DVMRP over a UDL February 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 Active mode configuration on receivers
DVMRPv3 is running on the feed and 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.
2.2.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.
Informational - Expires July 2002 3
Configuration of DVMRP over a UDL February 2002
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.2.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.
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:
Informational - Expires July 2002 4
Configuration of DVMRP over a UDL February 2002
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.2.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 (an IP
packet of 312 Bytes) (maximum size is 576 Bytes).
DVMRP implementations can support a limited number of DVMRP
neighbors. For instance in mrouted implementation 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
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.
Informational - Expires July 2002 5
Configuration of DVMRP over a UDL February 2002
2.3 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 (mrouted 3.9b3). 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).
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.3.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. A join via mtest program on the UDL interface of the
feed is enough to send the multicast session on the UDL.
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.3.2 Receiver configuration and behavior
Receivers accept new parameters in their configuration file. The
UDL interface must be declared as "one_way" and the LAN interface
must contain the parameter "switch_uni_bi <group_ip_address>".
This is an example of a default receiver configuration file:
Phyint dvb0 # UDL Interface
Threshold 8
Boundary LOCAL
Informational - Expires July 2002 6
Configuration of DVMRP over a UDL February 2002
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.4 How to switch between active and passive mode
When someone joins the session defined by the <group_ip_address> of
the switch_uni_bi parameter (here 224.5.6.7 in the example) on the
lan the receiver receives an IGMP join on the Lan interface and
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.
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). Moreover a receiver has to switch to active mode
when a end-user on its LAN wishes to participate to a multicast
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 will send a NACK to the push server. This
retransmission request is relayed by the GRE and the feed to the
Informational - Expires July 2002 7
Configuration of DVMRP over a UDL February 2002
push server. 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 and they will suppress the sending
of a NACK about the same packet.
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, some receivers
on the UDL could be in active mode to send retransmission request
(NACK) to the push server. Other receivers connected to the UDL on
passive mode will receive missing packet without sending any
request.
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
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.
Informational - Expires July 2002 8
Configuration of DVMRP over a UDL February 2002
4. Others network architectures
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.
Informational - Expires July 2002 9
Configuration of DVMRP over a UDL February 2002
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.
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.
Informational - Expires July 2002 10
Configuration of DVMRP over a UDL February 2002
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 :
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
Informational - Expires July 2002 11
Configuration of DVMRP over a UDL February 2002
[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"
[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
Informational - Expires July 2002 12
Configuration of DVMRP over a UDL February 2002
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.
Informational - Expires July 2002 13
Datatracker
Report a datatracker bug
draft-ietf-udlr-dvmrp-conf-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |