INTERNET-DRAFT Y. Guinamand P. Charron Document: draft-ietf-udlr-dvmrp-conf-00.txt Alcatel Space Expires: April 2002 November 2001 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. Network architectures.......................................... 2 2.1. Connectivity via the access router of the LAN.................. 2 2.2 Connectivity via PPP............................................ 3 2.3 Connectivity on the same LAN with passive DVMRP mode............ 4 3. DVMRP over a UDL............................................... 5 3.1.1 Requirements................................................. 5 3.1.2 Consequences................................................. 6 3.2 Broadcast and prune mode........................................ 6 3.3 DVMRP scalability issues and passive mode....................... 7 Guinamand & Charron [Page 1] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 4. Domains of application.......................................... 8 4.1 Reliable multicast.............................................. 8 4.2 Teleteaching.................................................... 8 5. References..................................................... 8 6. Author's Addresses............................................. 9 7. Full copyright statement....................................... 9 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 bidirectionality of all nodes connected by a unidirectional link, allows to connect natively receivers and feeds, emulating the behaviour of a LAN. Feeds and receivers can therefore easily exchange their routing information. This document describes routing over UDLs in three different network architectures connecting feeds to receivers and explains how DVMRP should be configured for each case, considering the characteristics of the UDL and of the return link. 2. Network architectures Feed and receivers are connected via a UDL which is a satellite link. A geostationnary satellite link features a UDL between the feed and the receivers, a minimum throughput of 2048Kbps up to 48000Kbps and 250ms delay from the feed to the 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 II [ETSI EN 300 421] transmission equipments. 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 receivers implement the RFC 3077, hence making the UDL totally transparent for the IP layer. 2.1. Connectivity via the access router of the LAN In this architecture, the receiver has one receive-only interface and one Ethernet interface. Guinamand & Charron [Page 2] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 The receiver uses the Ethernet interface to connect to the LAN on which workstations and one access router are connected. GRE traffic is sent to the Feed Bidirectional IP (FBIP) via the access router of the LAN. The access router doesn't require any multicast routing abilities. UniDirectional Link (UDL) ---------->------>------- | | ---------- --------- | Feed | | Recv | ---------- --------- | FBIP | | |-[WS] ------- ^ | | LAN | | |-[WS] ------- | | ---<----INTERNET-----<-[X] ^ | | Access Router Figure 1 : Connectivity receiver/feed via the access router of the LAN 2.2 Connectivity via PPP In this architecture, the receiver has one only-receive interface, one Ethernet interface and one PPP interface. The receiver uses the Ethernet interface to connect to the LAN on which workstations are connected. The receiver routes IP traffic encapsulated within GRE packets to FBIP through the PPP interface. Guinamand & Charron [Page 3] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 UniDirectional Link (UDL) ---------->------>------- | | ---------- ------------------ | Feed | | Recv | Modem | ---------- ------------------ | FBIP | | PPP connection | |-[WS] | | | ------- ^ |-[WS] | ISP | | ------- | | | | ^ INTERNET | | | V -----<--------------------<---------- GRE traffic Figure 2 : Connectivity receiver/feed via PPP 2.3 Connectivity on the same LAN with passive DVMRP mode In this architecture, the feed has its Ethernet interface connected on the same LAN as the receiver Recv1. Recv1 has one receive-only interface and one Ethernet interface. The objective of Recv1 is to send routing information to the feed to prevent the feed from considering that the satellite network is a leaf. This way, the feed sends its routing information because it has one permanent neighbor. Recv2 is a router that can switch between the active and the passive mode (as described in section 3.3) which solves scalability issues, i.e. it allows a huge number of receivers to listen to the multicast sessions. Guinamand & Charron [Page 4] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 Unidirectional Link (UDL) -------->---------------->------- | | | ---------- --------- ----------------- | Feed | | Recv1 | | Recv2 | Modem | ---------- --------- ----------------- | FBIP | | | PPP connection | | -------- | ------------------ LAN of Recv 2 ------- | LAN | ISP | | ------- | | [X]----------- INTERNET ------------------ Figure 3 : Connectivity receiver/feed on the same LAN with passive DVMRP mode 3. DVMRP over a UDL 3.1 Feeds and receivers DVMRPv3 is running on the feed and on receivers. While the feed and the receivers are considered to be on the same LAN, the Designated Querier and Forwarder on the UDL are elected as defined in respectively IGMPv2 [IGMPv2] and DVMRPv3 [Pusa00]. UniDirectional Link (UDL) ----->--------------------------------- | | | | | | -------- --------- ---------- [Feed 1]--------[ Recv1 ]-----[ Recv 2 ] -------- --------- ---------- | | | | | | ----------------------------------------- | Mbone | ----------------------------------------- Figure 4 : Feeds and receivers over a UDL 3.1.1 Requirements - The feed is elected as the Designated Querier. 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 must be elected as the Designated Querier. Guinamand & Charron [Page 5] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 - In the architecture described in section 2.3, the feed has to be elected as the Designated Forwarder. Let's consider a source connected on the BiDirectional Link (BDL). If a receiver was designated as a Forwarder, the receiver would encapsulate data into the UDLR tunnel and data would be reinjected in the UDL by the feed. To prevent such a situation, the feed has to be elected as the Designated Forwarder. - All active receivers are considered as DVMRP neighbors. 3.1.2 Consequences - The feed has the smallest IP address on the UDL. (Querier election mechanism as described in IGMPv2) - In the architecture described in section 2.3, i.e. the feed is the cheapest route between the LAN and the UDL. (Designated forwarder election mechanism as described in DVMRPv3 section 2.4) - The feed is the default MBone connection for the satellite network. - All active receivers have a return link channel up. A receiver configured in passive mode routing without a return link channel won't be able to contribute to any multicast sessions and won't route multicast traffic coming from the UDL to its LAN. 3.2 Broadcast and prune mode DVMRP is based on "broadcast and prune" mode, ie the DVMRP router initially floods datagrams out of all dependent downstream interfaces and then stops flooding when it has received prune messages from all downstream routers. On a UDL, 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 network architectures described in sections 2.1 and 2.2 show that the links connecting receivers to feeds are very different than links connecting a LAN. Indeed, these links cross many routers in the Internet, which increases dramatically the loss rate and therefore the probability to loose a prune message. For this reason, prunes must be retransmitted using binary exponential back-off during the lifetime of the prune if traffic is still arriving on the upstream interface. The algorithm is described in [Pusa00], section 3.5.5 Guinamand & Charron [Page 6] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 Example: Add "rexmit_prunes on" for the UDL interface of each receiver in the mrouted configuration file (implementation of DVMRPv3) 3.3 DVMRP scalability issues and passive mode DVMRP routers multicast Probe messages to locate each other. As a DVMRP router sees Probe messages from its DVMRP neighbors, it records the neighbor addresses in its routing table. The fact that all receivers are DVMRP neighbors on the UDL increases dramatically the DVMRP traffic and the size of routing tables with the exchange of DVMRP Reports. Example: The mrouted implementation of DVMRPv3 supports only 64 neighbors. A solution is to configure the DVMRP routers in passive mode. In this configuration, the downstream router won't send any DVMRP Probes or DVMRP Reports. A UDL such as a satellite network is a flat architecture in which the feed may have more than 64 neighbors. The Probe messages sent periodically by DVMRP routers keep the PPP connection alive until there is no more a member of a multicast session behind a receiver. Some modification of the implementation of DVMRPv3 making the router act passive can allow the connection of more than 64 receivers and can hence save the cost of a return channel. Receivers will route multicast datagrams from the UDL to the LAN on which they are connected without sending any information to the upstream router. This allows to save bandwidth: end-users on LANs behind a receiver are able to receive the multicast datagrams without using a return channel. Only contributions to multicast sessions require switching to active routing mode. The passive routing configuration is possible only if the upstream router is considered as a valid source, i.e. the upstream router sends its Reverse Path Forwarding (RPF) information. The upstream router (the feed) sends its RPF tables only if there is at least one active DVMRP receiver on the network. One active receiver is therefore mandatory to use passive routing mode on the UDL. Indeed, a program such as mtest (to join a multicast session on the UDL interface) without any active receiver manages to send multicast datagrams to the UDL. Guinamand & Charron [Page 7] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 But it is not enough because receivers will not forward these datagrams as they don't receive the RPF tables of the upstream router. 4. Domains of application The purpose of this section is to describe two kinds of application wherein dynamic multicast routing over a UDL presents a lot of benefits. 4.1 Reliable multicast RFC 3077 is very well suited for applications based on reliable multicast in push mode. Receivers send multicast ACKS and NACKs via the UDLR tunnel. Each receiver is aware of each other's status and will not ask for a retransmission of packets if another receiver already asked for these same packets. Dynamic multicast routing over a UDL allows a perfect coordination between receivers. 4.2 Teleteaching For this application, receivers are configured in passive mode. They receive teleteaching multicast sessions on their receive-only interface and route them through their Ethernet interface on the corporate LAN. Every workstation connected on the LAN receives the multicast session. Switching to active mode is obviously required if a member wishes to contribute to the session. 5. 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 [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" Guinamand & Charron [Page 8] INTERNET-DRAFT Configuration of DVMRP over a UDL November 2001 6. Author's Addresses Yann Guinamand Alcatel Space Industries 100, Bd du Midi 06156 Cannes la Bocca Cedex France Phone: (+33) 4 92 92 66 02 EMail : yann.guinamand@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 7. 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 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.