idnits 2.17.1 draft-ietf-udlr-dvmrp-conf-03.txt: -(401): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 746 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([UDLR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7984 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X' is mentioned on line 509, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Pusa00' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAP' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 C. Benassy-Foch 2 P. Charron 3 Internet Draft Y. Guinamand 4 Document: draft-ietf-udlr-dvmrp-conf-03.txt Alcatel Space 5 Expires: December 2002 June 2002 7 Configuration of DVMRP over a UniDirectional Link 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 Routers connected to a UniDirectional Link (UDL) such as a 30 satellite network, implement a link layer tunneling mechanism, as 31 defined in the RFC 3077 [UDLR]. These routers could exchange 32 multicast routing information. This document describes how DVMRPv3 33 works on this network architecture and suggests a different 34 configuration of DVMRPv3 on routers connected to the UDL more 35 adapted and optimized to this network architecture. 37 Table of Contents 39 Status of this Memo..............................................1 40 Abstract.........................................................1 41 1. Introduction..................................................2 42 2. DVMRPv3 over a UDL............................................2 43 2.1 Network architecture.........................................2 44 2.2 DVMRPv3 implementation.......................................3 45 2.3 Active mode configuration on receivers.......................3 46 2.3.1 Feed configuration and behavior............................4 47 2.3.2 Receiver configuration and behavior........................4 48 2.3.3 Scalability issue of DVMRP.................................5 50 Configuration of DVMRP over a UDL June 2002 52 2.4 Passive mode configuration on receivers......................6 53 2.4.1 Feed configuration and behavior............................6 54 2.4.2 Receiver configuration and behavior........................7 55 2.5 When and How to switch between active and passive mode.......7 56 3. Domains of application........................................8 57 3.1 Application using a Reliable Multicast Transport Protocol....8 58 3.2 Multicast application with interactivity.....................8 59 4. Others network architectures..................................9 60 4.1 Connectivity on the same LAN as the Feed....................10 61 4.2 Mbone connectivity via two access points: the UDL and the LAN11 62 5. Acknowledgements.............................................12 63 6. References...................................................12 64 7. Author's Addresses...........................................13 65 8. Full copyright statement.....................................13 67 1. Introduction 69 Multicast routing on a UDL such as a satellite network seems very 70 complex because the receiver can not send its routing information 71 to the feed. 73 The RFC 3077, which describes a link-layer mechanism to emulate the 74 full bi-directionality of all nodes connected by a unidirectional 75 link, allows to connect natively receivers and feeds, emulating the 76 behavior of a LAN. Feeds and receivers can therefore easily 77 exchange their routing information. DVMRPv3 could be used as 78 multicast routing protocol on this network. 80 2. DVMRPv3 over a UDL 82 2.1 Network architecture 84 Feed and receivers are connected via a UDL, which is a satellite 85 link. A geostationnary link features a UDL between the feed and 86 receivers, a minimum throughput of 2048Kbps up to 48000Kbps and a 87 250ms delay from the feed to receivers. 89 A satellite link is extremely well suited for multicast IP. The 90 large coverage associated to multicast allows to connect the feed 91 to a huge number of receivers using a modest amount of bandwidth. 93 The Feed is directly connected to DVB/MPEG-2 [ETSI EN 300 421] 94 transmission equipment. Receivers integrate a DVB-S/MPEG Satellite 95 reception card (receive-only interface) with a MAC address of 48 96 bits, similar to an Ethernet card. This reception card supports 97 unicast, broadcast and multicast mode. 99 The feed and receiver implement the RFC 3077, hence making the UDL 100 totally transparent for the IP layer. 102 Informational - Expires December 2002 2 104 Configuration of DVMRP over a UDL June 2002 106 UniDirectional Link (UDL) 107 +-------->--------->------------>-----+ 108 | | | 109 -------- -------- -------- 110 | Feed | |Recv 1| |Recv 2| 111 -------- -------- -------- 112 | | | | 113 | Workstation [WS]--| | |--[WS] 114 | |--[WS] | | LAN 115 | LAN | | |--[WS] 116 | | | 117 | v v 118 | | ------- 119 | Access router [X] |modem| PPP 120 | | ------- 121 | | | 122 +-------+ | | ------- 123 | MBONE |--[X] Router | | ISP | 124 +-------+ | | ------- 125 | | | 126 | +--------+ v v 127 +---<----|INTERNET|--<---+----<-------+ 128 +--------+ 130 Figure 1: Connectivity feed/receiver via an access router or a PPP 131 connection. 133 The Feed is connected to the MBONE and to the INTERNET. So it can 134 forward multicast traffic over the UDL. 136 Receivers have an Ethernet interface to connect to a LAN on which 137 workstations are connected. The LAN is connected to the INTERNET 138 via an access router (which does not have multicast routing 139 ability) or via a PPP connection. Receivers route IP traffic 140 encapsulated into GRE packets to the bi-directional interface of 141 the Feed. 143 2.2 DVMRPv3 implementation 145 DVMRPv3 is running on the feed and receivers. The feed and 146 receivers are DVMRP routers. In the experiment the DVMRPv3 147 implementation is mrouted 3.9b3. Feed and receivers run FreeBSD 148 3.4-RELEASE. 150 2.3 Active mode configuration on receivers 152 The feed and receivers are DVMRP routers. In active mode feed and 153 receivers have a standard DVMRPv3 implementation(mrouted 3.9b3). 155 A return link channel is necessary for receivers to exchange DVMRP 156 messages. Thanks to the Link Layer Tunneling Mechanism, feed and 157 receivers are considered to be on the same LAN. Thus they are DVMRP 158 neighbor routers. 160 Informational - Expires December 2002 3 162 Configuration of DVMRP over a UDL June 2002 164 2.3.1 Feed configuration and behavior 166 Feed configuration: 168 The feed is the only DVMRP router of the LAN having access to the 169 MBONE. The feed must be elected as the Designated Forwarder 170 [Pusa00] on the UDL to forward multicast data over the UDL. 172 The feed is the closest element from all receivers in term of 173 transmission duration. To ensure that all queries are well 174 centralized on the feed, it has to be elected as the Designated 175 Querier as defined in IGMPv2 [IGMPv2]. It needs to have the 176 smallest IP address on the UDL. 178 Feed behavior: 180 The feed periodically sends Probe messages over the UDL to discover 181 DVMRP neighbor routers. These messages contain the list of neighbor 182 router addresses. 184 Upon reception of a Probe message from a receiver via the GRE 185 tunnel, the feed updates its list of neighbors. If its address is 186 included into this report message, the feed establishes a two-way 187 neighbor adjacency with this receiver. 189 As the feed has DVMRP neighbor routers on the UDL, it sends route 190 information into Report messages over the UDL. A Report message 191 contains the list of source networks and the associated metrics. 192 It enables routers to determine the Reverse Path neighbor back to 193 the source of the multicast traffic. 195 These two DVMRP messages use a reserved multicast IP address (ALL- 196 DVMRP-ROUTERS) and have a TTL set to 1. 198 Upon reception of multicast traffic from the MBONE the feed will 199 broadcast traffic over the UDL and will stop flooding it when it 200 receives Prune messages from all downstream routers(all receivers). 202 2.3.2 Receiver configuration and behavior 204 Receiver configuration: 206 Receivers are standard DVMRP routers. The return link channel is 207 used to exchange DVMRP messages. 208 In this network architecture it is primordial to ensure that the 209 upstream router receives all Prune messages from its downstream 210 routers. If a prune message is lost, useless traffic continues to 211 be forwarded and hence wastes bandwidth. The GRE tunnel between 212 receivers and the feed crosses many routers in the INTERNET. 213 Therefore it dramatically increases the probability to lose a Prune 214 message. 216 Informational - Expires December 2002 4 218 Configuration of DVMRP over a UDL June 2002 220 For this reason Prune message must be transmitted using a binary 221 exponential back-off during the lifetime of the Prune message if 222 the traffic is still arriving on the upstream interface. This 223 algorithm is described in [Pusa00] section 3.5.5. 225 Example of configuration using mrouted (implementation of DVMRP): 226 Add "rexmit_prunes on" 228 Receiver behavior: 230 Receivers send Probe messages to discover others DVMRP routers. 231 Probe messages are encapsulated into the GRE tunnel and forwarded 232 to the feed. Receivers consider the feed as a DVMRP neighbor 233 router. 234 Then receivers send Report messages to the Feed via the GRE tunnel. 236 When the feed broadcast multicast data over the UDL, Receivers uses 237 the DVMRP routing table to determine if the traffic should be or 238 not forwarded to their Ethernet interfaces. First receivers check 239 if the incoming interface is the upstream interface of the data. 240 Secondly the multicast traffic is forwarded to downstream 241 interfaces as indicated into the DVMRP routing table. If there is 242 no downstream interface, the receiver sends a Prune message to the 243 upstream routeur via the GRE tunnel. After the receiver will send a 244 Graft message to the upstream router if the list of downstream 245 interfaces associated to this traffic is not any more empty. 247 2.3.3 Scalability issue of DVMRP 249 There are two main factors that limit the scalability of DVMRP over 250 a UDL. 252 First, the number of Probe messages periodically exchanged between 253 receivers and the feed is proportional to the number of receivers 254 connected to the UDL. The period is 10s. The size of Probe message 255 depends on the number of DVMRP routers. 256 In case of many receivers connected to the LAN, the DVMRP traffic 257 will dramatically increase on the UDL. 259 For example: A UDL with a feed and 70 receivers 260 The feed would receive 70 Probe messages every 10s. The Feed would 261 send a probe message over the UDL containing 70 IP addresses every 262 10s too. The size of this Probe message would be 292 Bytes (the IP 263 header would be 24 Bytes because of the IP router Alert option then 264 the IP packet would be 316 Bytes)(the maximum size is 576 Bytes 265 including IP header). 267 DVMRP implementations can support a limited number of DVMRP 268 neighbors. For instance in mrouted implementation (mrouted 3.9b3) 269 the maximum number of DVMRP neighbors is 64. A satellite UDL allows 270 more than 64 receivers. 272 In addition, Report messages are sent over the UDL. A router sends 273 a Report message every 60s in multicast and sends a Report message 275 Informational - Expires December 2002 5 277 Configuration of DVMRP over a UDL June 2002 279 in unicast when a new neighbor router is discovered (reception of a 280 Probe message with its own address into the list of neighbor 281 addresses). To prevent an implosion of Report messages, the sending 282 of Report messages is spread out across the report interval. So 283 each receiver would send a Report message every 60s to the Feed via 284 the GRE tunnel. 286 The return link channel will be loaded by DVMRP Messages. To enable 287 receivers connected to the UDL to forward multicast traffic without 288 a return link channel, Receivers could be configured in passive 289 mode. 291 2.4 Passive mode configuration on receivers 293 When the UDL is for example a satellite link, the number of 294 receivers easily overloads the capabilities of DVMRP. To avoid 295 this, the chosen solution is to implement a passive mode in the 296 standard implementation of DVMRP. This mode allows the mrouted 297 implementation to forward a valid multicast source from the UDL to 298 the lan of receivers without sending any information to the 299 upstream router (the feed)(the return link channel is not used). 301 A change is required on the DVMRP implementation used on receivers: 302 a new parameter has to be added into the implementation. It is 303 detailled in the section 2.3.2 (Receiver configuration and 304 behavior). 306 In this mode, receivers get from the feed the Multicast streams and 307 the RPF tables (contained into Report messages). The standard 308 implementation of multicast routing table is not modified, so 309 receivers need the RPF information to choose the feed as a valid 310 upstream router for the Multicast sessions they receives. This is 311 mandatory to avoid the creation of routing loop. 313 Without this RPF information receivers are not able to forward a 314 source from the feed to the lan. As described in the DVMRPv3 315 [Pusa00] a DVMRP router will send RPF information on an interface 316 only if there is at least one neighbor on this interface. 318 According to this, the feed must have at least one DVMRP neighbor 319 router on the UDL. So at least one receiver must be in active mode. 320 This active receiver will send Probe message to the feed via the 321 GRE tunnel and the feed will send over the UDL route information. 323 2.4.1 Feed configuration and behavior 325 The implementation of the multicast routing daemon is unmodified 326 into the feed. The feed configuration is the same as the one when 327 receivers are in active mode. The feed does not require any 328 modification to allow receivers to run in passive mode. 330 As the multicast routing algorithm is not modify, the feed must 331 receive a join IGMP message in order to forward a multicast session 332 on the UDL. An internal application could be developed to send a 334 Informational - Expires December 2002 6 336 Configuration of DVMRP over a UDL June 2002 338 join message on the UDL interface of the Feed. This internal 339 application might be based on a mtest program. 341 For instance, it is interesting to configure the Feed to forward 342 advertisement of multicast sessions via the Session Announcement 343 Protocol [SAP] and multicast sessions about hot topics. 345 2.4.2 Receiver configuration and behavior 347 To support the passive mode receivers has to accept a new parameter 348 in their DVMRP configuration file (mrouted 3.9b3). The LAN 349 interface must contain the new parameter "switch_uni_bi 350 ". This is not a multicast 351 group address related to a multicast group session. This address is 352 dedicated to the configuration of the Receiver on the LAN 353 interface. 354 In addition the UDL interface of the passive receiver must be 355 declared as "one_way". 357 This is an example of a default receiver configuration file: 359 Phyint dvb0 # UDL Interface 360 Threshold 8 361 Boundary LOCAL 362 One_way 363 Phyint eth0 # Lan Interface 364 Switch_uni_bi 224.5.6.7 366 In this configuration the receiver is launched in passive mode and 367 only forwards the valid sources it has received to its lan 368 interface. 369 "Valid sources" means multicast data from a source having not an 370 empty list of downstream interfaces into the routing table. 372 As described in the DVMRP protocol [Pusa00] the feed will send 373 Report messages needed to calculate the Reverse Path neighbor back 374 to the source of a multicast traffic, only if there is at least one 375 valid neighbors on the UDL. 377 This means you need to have all the time an active receiver on your 378 UDL. Section 4.1 of this document present a solution to this 379 problem. 381 2.5 When and How to switch between active and passive mode 383 In the experiment the passive mode is the default configuration of 384 receiver. 386 A receiver needs to switch to active mode when it has subscribers 387 on its LAN to a multicast session that is not forwarded by the Feed 388 over the UDL at this moment(all other active receivers have sent a 389 prune message). 391 Informational - Expires June 2002 7 393 Configuration of DVMRP over a UDL December 2002 395 When a end-user on the LAN wishes to participate to a multicast 396 session (to send multicast data), a receiver has to switch to 397 active mode too. 399 To switch to active mode, someone on the LAN must send a join 400 message to the session defined by the , the 401 groupe IP address of the �switch_uni_bi� parameter (here 224.5.6.7 402 in the example). Upon reception of an IGMP join on the lan 403 interface to this specific group address the receiver switches to 404 active mode. 406 The receiver will work in active mode until there is no more 407 members for the �switch_uni_bi� session, and will automaticaly 408 return to passive mode as it does not receive any more IGMP join 409 for this session. 411 3. Domains of application 413 The purpose of this section is to describe two kinds of 414 applications wherein dynamic multicast routing over a UDL presents 415 a lot of benefits. 417 3.1 Application using a Reliable Multicast Transport Protocol 419 [UDLR] is very well suited for applications using Reliable 420 Multicast Transport protocol based on Negative-ACKnowledgment. 422 A multicast push server is connected to the feed, which forwards 423 multicast data over the UDL to receivers. A receiver who is missing 424 data packets could send a NACK in multicast to the push server. 425 This retransmission request is relayed by the GRE tunnel to the 426 feed. It forwards the request to the push server and on the UDL 427 too. Upon reception of the NACK, the push sender retransmits the 428 requested packet. Then this requested packet is sent by the Feed 429 over the UDL. Other receivers connected to the UDL will receive the 430 missing packet. As the feed has forwarded the NACK request on the 431 UDL receivers have suppressed the sending of the same NACK. 432 This NACK suppression mechanism is easy to implement over a UDL. It 433 can be scaled to a large number of receivers and it reduces the use 434 of the return channel link. 436 With such a reliable multicast transport protocol based on NACK 437 some receivers on the UDL could be in active mode to send 438 retransmission request to the push server. Other receivers 439 connected to the UDL on passive mode will receive missing packet 440 without sending any request. These two modes on receivers will 441 improve the NACK suppression mechanism. 442 The application will offer a better service (a reliable transport 443 service) without overloading return channel links of receivers. 445 3.2 Multicast application with interactivity 447 Applications such as tele-teaching and collaborative work require a 448 main multicast flow from a main source to end-users (to deliver a 450 Informational - Expires December 2002 8 452 Configuration of DVMRP over a UDL June 2002 454 course or a lecture) and several minor flows from end-users to the 455 main source and other end-users (questions and remarks from end- 456 users). 458 For these applications, end-users are on the LAN interface of 459 passive receivers and they have joined the multicast session (they 460 have sent an IGMP report message for the session group address). 461 Passive receivers forward multicast session data to their LAN 462 interfaces. 463 If an end-user wishes to participate to the multicast session (for 464 instance, asking a question), the receiver must switch to active 465 mode. The return link channel will be set up. DVMRP messages will 466 be sent via the GRE tunnel to the feed and multicast data will be 467 forwarded via the GRE tunnel over the UDL. 468 After if no more end-user wishes to participate, the receiver will 469 switch back to passive mode. 471 Receivers in passive mode could listen multicast session without 472 sending DVMRP messages, hence without using their return link 473 channels. However they can participate multicast session by 474 switching to active mode. The use of the return link is optimized. 476 4. Others network architectures 478 This section proposes other network architectures well-adapted to 479 these two modes of configuration. These networks are based on a UDL 480 and a return channel link implementing the Link Layer Tunneling 481 Mechanism [UDLR]. The first architecture suggests a solution for an 482 operator of such a network to always have an active receiver 483 connected to the UDL under its control. In the second architecture, 484 a receiver has an access to the Mbone as the Feed has. In this case 485 the GRE tunnel is not worth forwarding multicast message to the 486 Feed or to a multicast source, it is better to forward these 487 multicast messages through the Mbone. To solve that, a 488 configuration of the DVMRP router included into the receiver is 489 proposed. 491 Informational - Expires December 2002 9 493 Configuration of DVMRP over a UDL June 2002 495 4.1 Connectivity on the same LAN as the Feed 497 UniDirectional Link (UDL) 498 +-------->------------>-----+ 499 | | | 500 -------- -------- -------- 501 | Feed | |Recv 1| |Recv 2| 502 -------- -------- -------- 503 | | | | Workstations 504 | [WS]--| | | LAN 505 | |--[WS] | |--[WS] 506 LAN +--------------+ | 507 | v 508 | ------- 509 Router [X] |modem| PPP 510 | ------- 511 | | 512 +-------+ | ------- 513 | MBONE |--[X] Router | ISP | 514 +-------+ | ------- 515 | | 516 | +--------+ v 517 +----<---|INTERNET|---<----+ 518 +--------+ 520 Figure 2: Connectivity feed/receiver on the same LAN 522 In this architecture, the feed has its Ethernet interface connected 523 on the same LAN as the receiver Recv 1. Recv 1 has a receive-only 524 interface and an Ethernet interface. 526 The Recv1 must not forward traffic to the UDL, the feed must be the 527 Designated Forwarder. So the feed must have the cheapest route 528 between the LAN of the Feed and the UDL. 530 Example of configuration with mrouted: 531 # fl0: The LAN interface of the feed 532 phyint fl0 metric 1 threshold 1 533 # r1l0: The LAN interface of the recv 1 534 phyint r1l0 metric 10 threshold 20 536 Recv 1 should be in active mode. In this case the feed has a 537 permanent DVMRP neighbor router. Thus the feed will continue to 538 send Report messages over the UDL, and all other receivers 539 connected to the UDL will be able to determine the Reverse Path 540 neighbor back to the source of a multicast traffic. 542 Recv 2 could be in passive mode if it wants to receive multicast 543 traffic. If it wishes to become a multicast source, it has to 544 switch to active mode. 546 Informational - Expires December 2002 10 548 Configuration of DVMRP over a UDL June 2002 550 With this network architecture, there is at least one receiver in 551 active mode on the UDL allowing a huge number of passive receivers 552 to listen multicast sessions. 554 4.2 Mbone connectivity via two access points: the UDL and the LAN 556 A feed is connected to the MBone/Internet and can forward multicast 557 traffic over the UDL. IGMP and DVMRP messages come from receivers 558 through the GRE tunnels. 560 Receivers are connected to the UDL and also to a LAN which already 561 has MBone connectivity. Receivers send routing information through 562 the GRE tunnels to the feed. 564 A client located on a remote LAN can receive multicast traffic 565 either from the UDL (e.g. a satellite link) or from the 566 "terrestrial" network. 568 UniDirectional Link (UDL) 569 ---->------------------------>---- 570 | | 571 | | 572 ---------- ----------- 573 | Feed | | Recv1 | 574 A ---------- ----------- C 575 | | | | 576 ---------------- LAN 1 LAN 2 ----------------------- 577 | | 578 ---- ---- 579 |R1| |R2| 580 ---- ---- B 581 | | | 582 ---------------------------------------------------------- 583 | Internet / MBone | 584 ---------------------------------------------------------- 586 Figure 3 : MBone connectivity via 2 access points 588 In the architecture described in the figure 3 : The Feed and Recv1 589 are neighbor DVMRP routers. R1 (respectively R2) is a multicast 590 router connected to the MBone that communicates with the Feed. 592 A and B are 2 multicast sources which transmit on the same 593 multicast group. C located on LAN2 joins this group. 595 From A, the multicast traffic is routed over the MBone cloud and 596 through R2 to reach the client. 598 In both cases, the shortest path is chosen to route the traffic 599 between the source and the destination. Routing operates here in an 600 optimal way. 602 When C starts generating multicast traffic : 604 Informational - Expires December 2002 11 606 Configuration of DVMRP over a UDL June 2002 608 1) to B : this traffic is routed through R2 and through the MBone. 609 2) to A : this traffic would normally be routed through Recv1 and 610 the feed because DVMRP thinks that C is only 2 hopes away from A. 611 In fact, the multicast traffic would go from C to Recv1, then 612 encapsulated within GRE packets, would go through the Internet up 613 to the Feed and then forwarded over LAN1. 615 This is not the optimal way to route traffic from LAN2 to LAN1 616 because the multicast traffic would be forwarded in a GRE tunnel 617 between Recv1 and the Feed over the Internet, whereas it could be 618 natively and optimally routed in multicast between R2 and R1 over 619 the MBone. 621 Furthermore, the GRE encapsulation adds extra overhead useless 622 here. 624 To route the multicast traffic from LAN2 to LAN1 over the MBone and 625 not within the GRE tunnel, DVMRP has to be configured on the 626 receiver. The solution is to set an infinite metric to the bi- 627 directional interface of the receiver. 629 As a result, the receiver cannot compute the shortest path to a 630 source via its bi-directional interface and then, cannot forward 631 the traffic over the UDL. 633 Furthermore, a receiver cannot announce valid routes to the feed 634 since they would all have infinite metrics. The feed cannot compute 635 any reverse path back through these receivers. 637 Hence, it is not possible for the multicast traffic to come from 638 the UDL but it flows from the terrestrial network to LAN1. 640 5. Acknowledgements 642 We would like to thank Emmanuel Duros for his technical inputs, 643 especially for the section 4.2, and all UDLR WG members for their 644 comments. 646 6. References 648 [UDLR] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang, "A 649 Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, 650 March 2001 652 [Pusa00] T. Pusateri, "Distance Vector Multicast Routing Protocol" 653 ,2000 655 [IGMPv2] W. Fenner, " Internet Group Management Protocol, Version 656 2", RFC 2236, November 1997 658 [ETSI EN 300 421] "Digital Video Broadcasting (DVB), Framing 659 structure, channel coding and modulation for 11/12 GHz satellite 661 Informational - Expires December 2002 12 663 Configuration of DVMRP over a UDL June 2002 665 services" 667 [SAP] M. Handley, C. Perkins, E. Whelan, "Session Annoucement 668 Protocol", October 2000 670 7. Author's Addresses 672 Celine Benassy-Foch 673 Alcatel Space Industries 674 26 av. J.F. Champollion 675 31037 Toulouse Cedex 676 France 677 Phone: (+33) 5 34 35 39 34 678 Email: celine.benassy@space.alcatel.fr 680 Philippe Charron 681 Alcatel Space Industries 682 100, Bd du Midi 683 06156 Cannes la Bocca Cedex 684 France 685 Phone: (+33) 4 92 92 79 89 686 Email: philippe.charron@space.alcatel.fr 688 Yann Guinamand 689 166 rue du President Wilson 690 92 300 Levallois Perret 691 France 692 Phone: (+33) 6 73 48 23 26 693 Email : yann@guinamand.com 695 8. Full copyright statement 697 Copyright (C) The Internet Society (1999). All Rights Reserved. 699 This document and translations of it may be copied and furnished to 700 others, and derivative works that comment on or otherwise explain 701 it or assist its implementation may be prepared, copied, published and 702 distributed, in whole or in part, without restriction of any kind, 703 provided that the above copyright notice and this paragraph are 704 included on all such copies and derivative works. 706 However, this document itself may not be modified in any way, such 707 as by removing the copyright notice or references to the Internet 708 Society or other Internet organizations, except as needed for the 709 purpose of developing Internet standards in which case the 710 procedures for copyrights defined in the Internet Standards process must be 711 followed, or as required to translate it into languages other than 712 English. 714 The limited permissions granted above are perpetual and will not be 716 Informational - Expires December 2002 13 718 Configuration of DVMRP over a UDL June 2002 720 revoked by the Internet Society or its successors or assigns. 722 This document and the information contained herein is provided on 723 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 724 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 725 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 726 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 727 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 729 Informational - Expires December 2002 14