idnits 2.17.1 draft-ietf-udlr-multicast-issues-00.txt: 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: ---------------------------------------------------------------------------- == 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 6) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC3077]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2002) is 7897 days in the past. Is this intentional? 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 section? 'RFC3077' on line 286 looks like a reference -- Missing reference section? '3077' on line 76 looks like a reference -- Missing reference section? 'RFC2119' on line 280 looks like a reference -- Missing reference section? 'RFC2236' on line 283 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.Takei 2 Internet-Draft H.Izumiyama 3 February 2002 JSAT 4 Expires August 2002 6 Identifying Multicast Implications in 7 a Link-Layer Tunneling Mechanism for Unidirectional Links 9 11 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 32 This document describes operational information for deploying 33 multicast network with link layer tunneling mechanism which 34 defined in [RFC3077]. RFC3077 defines the mechanism which allows a 35 operator to integrate unidirectional link(e.g. satellite link 36 etc..) into the network transparently. In some multicast network 37 configuration, a certain configuration for unidirectional link 38 are necessary. This document clarifies the problem that exist when 39 a operator use a multicast routing protocol with link layer 40 tunneling mechanism. It also describes how to solve those problem 41 with short term solutions and also long term solutions. 43 This document does not define any new protocol. 45 1. Terminology 47 Unidirectional link (UDL): A one-way transmission link, e.g. a 48 broadcast satellite link. 50 Receiver: A router or a host that has receive-only connectivity 51 to a UDL. 53 Feed: A router that has send-only connectivity to a UDL. 55 Node: A receiver or a feed. 57 Bidirectional interface: a typical communication interface that can 58 send or receive packets, such as an Ethernet card, a modem, etc. 60 Listener: a host that receive multicast packet. 62 Sender: a host that transmit multicast packet to the Internet. 64 Multicast Router: a router that has a capability to route and 65 forward IP multicast packet. 67 2. General Overview 69 Figure 1 depicts the architecture with a single feed and several 70 receivers. This is a basic network configuration for UDLR[RFC3077]. 72 fuip is the feed unidirectional IP address as defined in Section 7 73 of RFC[3077]. Also called the feed tunnel end-point. 75 fbip is the feed bidirectional IP address as defined in Section 7 of 76 RFC[3077]. 78 r1u (resp. r2u) is the IP address of the 'Receiver 1' 79 (resp. Receiver receive-only interface. 81 r1b (resp. r2b) is the IP address of the 'Receiver 1' 82 (resp. Receiver bidirectional interface connected to the 83 Internet. Subnet A is a local area network connected to recv 2. 85 Unidirectional Link 87 ---->------------------------------>------ 88 | | | 89 |fuip |r1u |r2u 90 -------- -------- -------- ---------- 91 | Feed | |Recv 1| |Recv 2|---|subnet A| 92 -------- -------- -------- ---------- 93 |fbip |r1b |r2b | 94 | | | | 95 ---------------------------------------------------- 96 | Internet | 97 ---------------------------------------------------- 98 Figure 1: Typical topology using LLTM 100 Figure 2 shows simplified sample multicast network topology. A 101 Listener will receive multicast packet from the sender via UDL 102 link(right route). In this draft, we assume following 103 model. Multicast traffic mainly flows from the Sender to a 104 Receiver. Few multicast traffic may flow to a Receiver to the 105 Sender. A number of UDL_Receivers can be a big number when a feed 106 will distribute a data via broadcast type media(e.g. satellite). 108 +------+ 109 |Sender| 110 +--+---+ 111 | 112 +--+--+ 113 |MC-R1 | 114 +-----+ 115 / \ 116 / \ 117 / \ 118 +-----+ +-----+ 119 |MC-R2| |MC-R4| Sender: Source of multicast 120 +-----+ +-----+ Listener: Multicast Receiver 121 | | MC-Rx: Multicast router 122 BDL UDL BDL: Bidirectional link 123 | | UDL: Unidirectional link 124 +-----+ +-----+ Metric_BDL > Metric_UDL 125 |MC-R3| |MC-R5| 126 +-----+ +-----+ 127 | | 128 \ / 129 \ / 130 \ / ^ controlled by RPF 131 +-----+ | (WAN) 132 |MC-R6| ------------------------- 133 +-----+ | (LAN) 134 | v controlled by IGMP 135 ----+----+------+-------- 136 | | 137 +---+----+ +---+----+ 138 |Listener| |Listener| ......... 139 +--------+ +--------+ 141 Figure 2: Typical Multicast Network Topology 143 A traffic from the sender to a receiver will flow under controlled 144 by multicast routing protocols(e.g. IGMP, DVMRP, etc.). A 145 multicast routing control can be divided in to two category. One 146 is membership control mechanism like IGMP. It will handle who are 147 receiving multicast packet. The other one is RPF based forwarding 148 control mechanism which will be used between routers in wide area 149 network(e.g. DVMRP, PIM, etc.). This document will describe 150 problems with both mechanism. 152 3 Problem related to membership control mechanism with IGMPv2 154 In the LLTM environment, A receiver may be a listener or a 155 multicast router. If the number of receivers will be large or the 156 network delay between listeners when they exchange multicast 157 control packet, a certain configuration for unidirectional link 158 with large receiver environment are necessary by following 159 reasons. 161 Multicast routers use IGMP to learn which groups have listeners on 162 each of their attached physical networks. A multicast router keeps 163 a list of multicast group memberships for each attached network, 164 and a timer for each membership. To keep update above information, a 165 multicast router periodically send a query on each 166 attached network. 168 When a host receives a query, it sets delay timers for each group 169 of which it is a member on the interface from which it received 170 the query. Each timer is set to a different random value, using 171 the highest clock granularity available on the host, selected from 172 the range (0,Max Response Time) with Max Response Time as 173 specified in the Query packet. 175 When a group's timer expires, the listener multicast Membership 176 report to the group. If the listener receives another listener's 177 report while it has a timer running, it stops its timer for the 178 specified group and does not send a report, in order to suppress 179 duplicate reports. 181 But in the LLTM environment, a report from a listener to another 182 listener will be forwarded to a feed via tunnel and then forwarded 183 to the listener via UDL. If the network delay in UDL is not small 184 like local area network, the network delay between listeners is also 185 big. For example if the UDL link is satellite link, the delay of 186 the UDL is over 250msec. Thus total delay is sum of 250msec and 187 the delay of BDL. 189 RFC2236 defines Max Response Time and its range is 0 to 25.5sec 190 and default value is 10sec. Varying this setting allows routers to 191 tune the burstiness of IGMP traffic on a subnet. If the number of 192 a listener is bigger than 2.5 times of the number of listener 193 expected in RFC2236, IGMP traffic density may be a cause of a 194 network trouble. 196 And if the network delay between listeners are relatively larger 197 than local area network environment, many listener may send query 198 report to the group before receiving a query report from another 199 listener. This is also a cause of useless IGMP traffic in subnet. 201 Two short term solution can be listed to solve above issue. 202 1. By configuring routers with static routing, there are no need 203 to send query to the subnet. This solution can be applied to 204 simple network. 205 2. By putting a listener at the segment of feed UDL interface 206 connected, the listener always send report to a querier without 207 using UDL. This solution need to connect a host directory to 208 the feed UDL interface and it can communicate with 209 bidirectional. 211 In the long term solution, some modification of IGMP is required 212 like expanding the range of Max Response Time. 214 Same kind of problems occur with multicast routing protocol which 215 have membership control function similar to IGMP. 217 4 Problem related to Reverse Path Forwarding(RPF) mechanism 219 In figure2, a multicast packet from the sender to a listener is 220 forward following path. 222 Sender -> MC-R4 -> MC-R5 -> MC-R6 -> Listener 224 To forward multicast packets from MC-R5 to MC-R6, the reverse path 225 from MC-R6 to the sender must be toward to MC-R5. If the reverse 226 path direction is not toward to MC-R5, the multicast packet from 227 MC-R5 will be discard at MC-R6. 229 The link between MC-R5 and MC-R4 is unidirectional link. So the 230 metric or the cost of the link from MC-R5 to MC-R4 should be higher 231 than other link or infinity. Therefore if MC-R6 calculate the 232 reverse path using unicast routing table, the direction of the path 233 will toward MC-R3. Some multicast routing protocol use revers path 234 forwarding(RPF) mechanism and if the protocol calculate using 235 unicast routing table, UDL will not be used. 237 Short term solutions for this problem, there are some solutions. One 238 is setting up the unicast routing to use the tunnel between the feed 239 and a receiver and make a static route for unicast 240 communications. Therefore unicast routing matches PRF and a 241 multicast packet from UDL will not be discarded. This is not optimal 242 route in terms of unicast routing and needs to configure all 243 receiver. 245 The other way is to use multicast routing protocol which build 246 multicast routing table(RPF) independent from unicast routing 247 table. DVMRP build multicast routing table independent from unicast 248 routing table but it has already know that DVMRP has a scale problem. 250 The third one is using broadcast type media to connect MC-Rs. By 251 connecting MC-R3, MC-R5 and MC-R6 with broadcast type media as show in 252 figure3, RPF at MC-R6 toward to MC-R3. This means MC-R6 receives a 253 multicast packet from the network interface which connect MC-R3 and 254 MC-R5(if_a). Multicast routing protocol maintain routing table with 255 their connected interface not next hop IP address. As a result 256 multicast packet from UDL will be accepted at MC-R6 and UDL will be 257 used efficiently. 259 BDL UDL 260 | | 261 +-----+ +-----+ 262 |MC-R3| |MC-R5| 263 +-----+ +-----+ 264 | | 265 | | 266 ---+----+-----+---- broadcast type media network 267 |if_a 268 +-----+ 269 |MC-R6| 270 +-----+ 271 :if_b 273 Fig 3. connect MC-Rs with broadcast type media 275 As a long term solution, a implementation which build multicast 276 routing table independent from unicast routing table can be listed. 278 References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 284 2", RFC2236, November 1997 286 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 287 Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional 288 Links', RFC 3077, March 2001 290 Author's address 292 Jun Takei, Hidetaka Izumiyama 293 JSAT Co. Ltd. 294 PCPM 17F 295 1-11-1 Marunouchi Chiyoda-ku 296 Tokyo 100-6218 297 Japan 298 Phone: +81 3 5129 7638 299 Fax: +81 3 5219 7871 300 Email: takei@csm.jcsat.co.jp