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 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]