[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]