Network Working Group J.Takei
Internet-Draft H.Izumiyama
February 2002 JSAT
Expires August 2002
Identifying Multicast Implications in
a Link-Layer Tunneling Mechanism for Unidirectional Links
<draft-ietf-udlr-multicast-issues-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes operational information for deploying
multicast network with link layer tunneling mechanism which
defined in [RFC3077]. RFC3077 defines the mechanism which allows a
operator to integrate unidirectional link(e.g. satellite link
etc..) into the network transparently. In some multicast network
configuration, a certain configuration for unidirectional link
are necessary. This document clarifies the problem that exist when
a operator use a multicast routing protocol with link layer
tunneling mechanism. It also describes how to solve those problem
with short term solutions and also long term solutions.
This document does not define any new protocol.
1. Terminology
Unidirectional link (UDL): A one-way transmission link, e.g. a
broadcast satellite link.
Receiver: A router or a host that has receive-only connectivity
to a UDL.
Takei [Page 1]
Internet Draft Multicast Implications in LLTM for UDL March 2002
Feed: A router that has send-only connectivity to a UDL.
Node: A receiver or a feed.
Bidirectional interface: a typical communication interface that can
send or receive packets, such as an Ethernet card, a modem, etc.
Listener: a host that receive multicast packet.
Sender: a host that transmit multicast packet to the Internet.
Multicast Router: a router that has a capability to route and
forward IP multicast packet.
2. General Overview
Figure 1 depicts the architecture with a single feed and several
receivers. This is a basic network configuration for UDLR[RFC3077].
fuip is the feed unidirectional IP address as defined in Section 7
of RFC[3077]. Also called the feed tunnel end-point.
fbip is the feed bidirectional IP address as defined in Section 7 of
RFC[3077].
r1u (resp. r2u) is the IP address of the 'Receiver 1'
(resp. Receiver receive-only interface.
r1b (resp. r2b) is the IP address of the 'Receiver 1'
(resp. Receiver bidirectional interface connected to the
Internet. Subnet A is a local area network connected to recv 2.
Unidirectional Link
---->------------------------------>------
| | |
|fuip |r1u |r2u
-------- -------- -------- ----------
| Feed | |Recv 1| |Recv 2|---|subnet A|
-------- -------- -------- ----------
|fbip |r1b |r2b |
| | | |
----------------------------------------------------
| Internet |
----------------------------------------------------
Figure 1: Typical topology using LLTM
Figure 2 shows simplified sample multicast network topology. A
Listener will receive multicast packet from the sender via UDL
link(right route). In this draft, we assume following
model. Multicast traffic mainly flows from the Sender to a
Receiver. Few multicast traffic may flow to a Receiver to the
Takei [Page 2]
Internet Draft Multicast Implications in LLTM for UDL March 2002
Sender. A number of UDL_Receivers can be a big number when a feed
will distribute a data via broadcast type media(e.g. satellite).
+------+
|Sender|
+--+---+
|
+--+--+
|MC-R1 |
+-----+
/ \
/ \
/ \
+-----+ +-----+
|MC-R2| |MC-R4| Sender: Source of multicast
+-----+ +-----+ Listener: Multicast Receiver
| | MC-Rx: Multicast router
BDL UDL BDL: Bidirectional link
| | UDL: Unidirectional link
+-----+ +-----+ Metric_BDL > Metric_UDL
|MC-R3| |MC-R5|
+-----+ +-----+
| |
\ /
\ /
\ / ^ controlled by RPF
+-----+ | (WAN)
|MC-R6| -------------------------
+-----+ | (LAN)
| v controlled by IGMP
----+----+------+--------
| |
+---+----+ +---+----+
|Listener| |Listener| .........
+--------+ +--------+
Figure 2: Typical Multicast Network Topology
A traffic from the sender to a receiver will flow under controlled
by multicast routing protocols(e.g. IGMP, DVMRP, etc.). A
multicast routing control can be divided in to two category. One
is membership control mechanism like IGMP. It will handle who are
receiving multicast packet. The other one is RPF based forwarding
control mechanism which will be used between routers in wide area
network(e.g. DVMRP, PIM, etc.). This document will describe
problems with both mechanism.
3 Problem related to membership control mechanism with IGMPv2
In the LLTM environment, A receiver may be a listener or a
multicast router. If the number of receivers will be large or the
network delay between listeners when they exchange multicast
control packet, a certain configuration for unidirectional link
with large receiver environment are necessary by following
Takei [Page 3]
Internet Draft Multicast Implications in LLTM for UDL March 2002
reasons.
Multicast routers use IGMP to learn which groups have listeners on
each of their attached physical networks. A multicast router keeps
a list of multicast group memberships for each attached network,
and a timer for each membership. To keep update above information, a
multicast router periodically send a query on each
attached network.
When a host receives a query, it sets delay timers for each group
of which it is a member on the interface from which it received
the query. Each timer is set to a different random value, using
the highest clock granularity available on the host, selected from
the range (0,Max Response Time) with Max Response Time as
specified in the Query packet.
When a group's timer expires, the listener multicast Membership
report to the group. If the listener receives another listener's
report while it has a timer running, it stops its timer for the
specified group and does not send a report, in order to suppress
duplicate reports.
But in the LLTM environment, a report from a listener to another
listener will be forwarded to a feed via tunnel and then forwarded
to the listener via UDL. If the network delay in UDL is not small
like local area network, the network delay between listeners is also
big. For example if the UDL link is satellite link, the delay of
the UDL is over 250msec. Thus total delay is sum of 250msec and
the delay of BDL.
RFC2236 defines Max Response Time and its range is 0 to 25.5sec
and default value is 10sec. Varying this setting allows routers to
tune the burstiness of IGMP traffic on a subnet. If the number of
a listener is bigger than 2.5 times of the number of listener
expected in RFC2236, IGMP traffic density may be a cause of a
network trouble.
And if the network delay between listeners are relatively larger
than local area network environment, many listener may send query
report to the group before receiving a query report from another
listener. This is also a cause of useless IGMP traffic in subnet.
Two short term solution can be listed to solve above issue.
1. By configuring routers with static routing, there are no need
to send query to the subnet. This solution can be applied to
simple network.
2. By putting a listener at the segment of feed UDL interface
connected, the listener always send report to a querier without
using UDL. This solution need to connect a host directory to
the feed UDL interface and it can communicate with
bidirectional.
In the long term solution, some modification of IGMP is required
like expanding the range of Max Response Time.
Takei [Page 4]
Internet Draft Multicast Implications in LLTM for UDL March 2002
Same kind of problems occur with multicast routing protocol which
have membership control function similar to IGMP.
4 Problem related to Reverse Path Forwarding(RPF) mechanism
In figure2, a multicast packet from the sender to a listener is
forward following path.
Sender -> MC-R4 -> MC-R5 -> MC-R6 -> Listener
To forward multicast packets from MC-R5 to MC-R6, the reverse path
from MC-R6 to the sender must be toward to MC-R5. If the reverse
path direction is not toward to MC-R5, the multicast packet from
MC-R5 will be discard at MC-R6.
The link between MC-R5 and MC-R4 is unidirectional link. So the
metric or the cost of the link from MC-R5 to MC-R4 should be higher
than other link or infinity. Therefore if MC-R6 calculate the
reverse path using unicast routing table, the direction of the path
will toward MC-R3. Some multicast routing protocol use revers path
forwarding(RPF) mechanism and if the protocol calculate using
unicast routing table, UDL will not be used.
Short term solutions for this problem, there are some solutions. One
is setting up the unicast routing to use the tunnel between the feed
and a receiver and make a static route for unicast
communications. Therefore unicast routing matches PRF and a
multicast packet from UDL will not be discarded. This is not optimal
route in terms of unicast routing and needs to configure all
receiver.
The other way is to use multicast routing protocol which build
multicast routing table(RPF) independent from unicast routing
table. DVMRP build multicast routing table independent from unicast
routing table but it has already know that DVMRP has a scale problem.
The third one is using broadcast type media to connect MC-Rs. By
connecting MC-R3, MC-R5 and MC-R6 with broadcast type media as show in
figure3, RPF at MC-R6 toward to MC-R3. This means MC-R6 receives a
multicast packet from the network interface which connect MC-R3 and
MC-R5(if_a). Multicast routing protocol maintain routing table with
their connected interface not next hop IP address. As a result
multicast packet from UDL will be accepted at MC-R6 and UDL will be
used efficiently.
Takei [Page 5]
Internet Draft Multicast Implications in LLTM for UDL March 2002
BDL UDL
| |
+-----+ +-----+
|MC-R3| |MC-R5|
+-----+ +-----+
| |
| |
---+----+-----+---- broadcast type media network
|if_a
+-----+
|MC-R6|
+-----+
:if_b
Fig 3. connect MC-Rs with broadcast type media
As a long term solution, a implementation which build multicast
routing table independent from unicast routing table can be listed.
References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC2236, November 1997
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional
Links', RFC 3077, March 2001
Author's address
Jun Takei, Hidetaka Izumiyama
JSAT Co. Ltd.
PCPM 17F
1-11-1 Marunouchi Chiyoda-ku
Tokyo 100-6218
Japan
Phone: +81 3 5129 7638
Fax: +81 3 5219 7871
Email: takei@csm.jcsat.co.jp
Takei [Page 6]
