Internet-Draft Y. Guinamand P. Charron Document: draft-ietf-udlr-dvmrp-conf-01.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.................3 2.2. Connectivity via PPP..........................................3 2.3. Connectivity on the same LAN with passive DVMRP mode..........4 2.4. MBone connectivity via 2 access points : the UDL and the LAN..5 Guinamand, Charron [Page 1] Internet Draft Configuration of DVMRP over a UDL November 2001 3. DVMRP over a UDL................................................7 3.1. Feeds and receivers...........................................7 3.1.1. Requirements................................................8 3.1.2. Consequences................................................8 3.2. Broadcast and prune mode......................................8 3.3. DVMRP scalability issues and passive mode.....................9 4. Domains of application.........................................10 4.1. Reliable multicast...........................................10 4.2. Teleteaching.................................................10 5. Acknowledgements...............................................11 6. References.....................................................11 7. Author's adresses..............................................11 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 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 four 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. Guinamand, Charron [Page 2] Internet Draft Configuration of DVMRP over a UDL November 2001 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. 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 2.4 MBone connectivity via 2 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. Guinamand, Charron [Page 5] Internet Draft Configuration of DVMRP over a UDL November 2001 UniDirectional Link (UDL) ---->------------------------>---- | | | | ---------- ----------- | Feed | | Recv1 | A ---------- ----------- C | | | | ---------------- LAN 1 LAN 2 ----------------------- | | ---- ---- |R1| |R2| ---- ---- B | | | ---------------------------------------------------------- | Internet / MBone | ---------------------------------------------------------- Figure 4 : MBone connectivity via 2 access points In the architecture described in the figure 4 : The Feed and Recv1 are neigbor 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. In both cases, the shortest path is chosen to route the traffic between the source and the destinaton. 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. Guinamand, Charron [Page 6] Internet Draft Configuration of DVMRP over a UDL November 2001 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 bidirectional interface of the receiver. As a result, the receiver cannot compute the shortest path to a source via its bidirectional 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. 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 5 : Feeds and receivers over a UDL Guinamand, Charron [Page 7] Internet Draft Configuration of DVMRP over a UDL November 2001 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. - The feed has to be elected as the Designated Forwarder. The feed forwards data over the UDL. A receiver must not be elected as a Designated Forwarder to avoid that data are encapsulated into the link-layer tunneling mechanism up to the feed and then reforwarded over the UDL. - 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) - 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 Guinamand, Charron [Page 8] Internet Draft Configuration of DVMRP over a UDL November 2001 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 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 establish 2 way neighbor adjacency. 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. The general idea of the passive mode is to allow a receiver to forward multicast traffic from the UDL over the LAN without establishing a 2 way relationship with a feed. There are several reasons for that : - A UDL such as a satellite network is a flat architecture in which the feed may have more than 64 neighbors. The passive mode allows more than 64 receivers. - 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. Receivers will route multicast datagrams from the UDL to the LAN on which they are connected without sending any information to the upstream router. The passive mode hence saves the cost of a return channel : 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. A DVMRP router sends routing information or route reports which are used for determining the reverse path neighbor back to the source of the multicast traffic. Guinamand, Charron [Page 9] Internet Draft Configuration of DVMRP over a UDL November 2001 The feed will send these information only if at least one receiver is configured in active DVMRP mode. Indeed, an application that sends join messages for specific multicast groups over the UDL without any active receiver manages to send multicast datagrams to the UDL. But it is not enough because receivers will not forward these datagrams as they don't receive the routing information or route reports 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 [UDLR] is very well suited for applications based on reliable multicast in push mode. A multicast push server is connected to the feed. A set of multicast push clients on the remote sites are connected to the UDL. Multicast datagrams from the push server are routed over the UDL as soon as one client joins the multicast group. In case of packet losses, push clients send back NACKs to the push server to ask for retransmission. These requests are sent in multicast and relayed by the receiver through the link-layer tunneling mechanism up to the feed. This provides a mechanism for push client to refrain from asking retransmission of packet which were already requested by another client. A such mechanism is very well suited when a large number of clients detect the same packets loss. It avoids an implosion of request messages at the server. 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 host connected on the LAN receives the multicast session. Switching to active mode is obviously required if a member wishes to Guinamand, Charron [Page 10] Internet Draft Configuration of DVMRP over a UDL November 2001 contribute to the session. A multicast IP address can be defined in the DVMRP router's configuration to allow to switch between active and passive mode. Indeed, if a host on the corporate LAN joins this multicast IP address, the DVMRP router automatically switches to active mode. It switches back to passive mode as soon as no more member of this multicast group is present. 5. Acknowledgements We would like to thank Emmanuel Duros for his technical inputs, especially for the section 2.4 he provided. 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 [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" 7. 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 Guinamand, Charron [Page 11] Internet Draft Configuration of DVMRP over a UDL November 2001 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 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. Guinamand, Charron [Page 12]