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 ". 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 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