idnits 2.17.1 draft-ietf-udlr-experiments-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance 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: ---------------------------------------------------------------------------- == Line 689 has weird spacing: '...dically sends...' == Line 725 has weird spacing: '...he time to de...' == Line 760 has weird spacing: '...sponses from ...' == Line 831 has weird spacing: '...Querier for t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2003) is 7682 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: 'RFC 3077' is mentioned on line 152, but not defined == Missing Reference: 'RFC1122' is mentioned on line 312, but not defined == Missing Reference: 'RFC 1112' is mentioned on line 94, but not defined == Missing Reference: 'RFC 3171' is mentioned on line 306, but not defined ** Obsolete undefined reference: RFC 3171 (Obsoleted by RFC 5771) == Missing Reference: 'RFC 2131' is mentioned on line 539, but not defined == Missing Reference: 'RFC2131' is mentioned on line 568, but not defined == Missing Reference: 'RFC2132' is mentioned on line 570, but not defined == Unused Reference: 'RFC2119' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'DRAFT-MAGMA-PROXY' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC1889' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC3171' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC3228' is defined on line 1058, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-IGMPv3' -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2933 (Obsoleted by RFC 5519) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Emmanuel Duros et al. 3 Internet-Draft 4 October 2002 Expires April 2003 6 Experiments with RFC 3077 8 10 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 groupsmay also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 In March 2001, [RFC 3077] was published and describes a protocol 33 which allows to integrate unidirectional links in the Internet. Since 34 then, a number of experimentations and deployements using this 35 protocol have been led. This document presents various protocols, 36 e.g. layer 2 and layer 3 protocols, which have been commonly used 37 over [RFC 3077] in a satellite environment. This document raises 38 issues for each of these protocols. 40 Table of Contents 42 1. Characteristics of Uni-Directional Links .................... X 43 1.1. Characteristics of UDLR networks ............................ X 44 1.1.1. Asymmetric routing paths .................................. X 45 1.1.3. Forward link capacity ..................................... X 46 1.1.3. Asymmetric link capacity .................................. X 47 1.1.4. Asymmetric loss environment ............................... X 48 1.1.5. Flat networks ............................................. X 49 1.1.6. Subnetwork round trip delay ............................... X 50 2. Description of Network Architecture ......................... X 51 2.1. Topology .................................................... X 52 2.2. Multicast Forwarding over UDLR .............................. X 53 3.0. Layer 2 Protocols ........................................... X 54 3.1. Hardware Address Resolution ................................. X 55 3.1.1 Hardware Address Resolution protocol over UDLR ............. X 56 3.1.2 Issues using a hardware resolution protocol over UDLR ...... X 57 3.1.2.1 Long round trip delays ................................... X 58 3.1.2.2 Large number of receivers ................................ X 59 3.2. PPPoE ....................................................... X 60 4.0. Layer 3 Protocols ........................................... X 61 4.1. Dynamic Host Configuration Protocol ......................... X 62 4.1.1. DHCP Overview ............................................. X 63 4.1.2. DHCP over UDLR ............................................ X 64 4.1.2.1. Configuration and tuning guidelines ..................... X 65 4.1.2.2. Security issues ......................................... X 66 4.2. Issues using IGMP over UDLR ................................. X 67 4.2.1. Basic IGMP Operation ...................................... X 68 4.2.2. IGMPv2 Leave Processing ................................... X 69 4.2.3. IGMPv3 Operation .......................................... X 70 4.2.4. Forwarding Groups at the Receiver based on IGMP ........... X 71 4.3. IGMP-Proxy .................................................. X 72 4.4. Dense Mode Multicast Routing ................................ X 73 4.4.1. DVMRP ..................................................... X 74 4.4.2. Dense Mode PIM (PIM-DM) ................................... X 75 4.5. Sparse Mode Multicast Routing ............................... X 76 4.5.1. Sparse Mode PIM (PIM-SM) .................................. X 77 4.5.2. PIM-SM RPs and MSDP ....................................... X 78 5. Security Considerations ..................................... X 79 6. Conclusions ................................................. X 80 7. Acknowledgements ............................................ X 81 8. References .................................................. X 82 8.1. Normative References ........................................ X 83 8.2. Informative References ...................................... X 84 9. Authors' Addresses .......................................... X 85 10. Full Copyright Statement .................................... X 86 11. IANA Considerations ......................................... X 88 1. Characteristics of Uni-Directional Links 90 This document describes issues that concern use of UDLR networks 91 [RFC3077] to support the IP multicast service. In this document it is 92 assumed that the feed router is a multicast router [RFC1122]. 94 The format of an IPv4 multicast packet [RFC 1112] is identical to 95 that of an IPv4 unicast packet and is distinguished only by a special 96 class of destination address (class D, i.e., addresses in the range 97 from 224.0.0.0 to 239.255.255.255). 99 There are five distinct multicast scenarios. The issues that arise 100 and the approaches to be recommended will be a function of these 101 scenarios. The list of scenarios to be addresses is: 103 Scenario A. An edge-network, where end hosts receive a multicast 104 service from an upstream router via the Feed Router. Multicast 105 forwarding is controlled via a group memberhip protocol (e.g. IGMP 106 [RFC2236]). Each end host is directly via a UDLR feed link. 108 Scenario B. A bridged edge-network, where one or more end hosts 109 receive a multicast service via a common LAN connection to a UDLR 110 Receiver. Multicast forwarding is controlled via a group memberhip 111 protocol (e.g. IGMP [RFC2236]). The UDLR Receiver is connected to the 112 upstream Feed Router via a UDLR tunnel. 114 Scenario C. A bridged-network supporting multicast routers, where 115 one or more multicast routers receive a multicast service provided 116 via a common LAN connection to a UDLR Receiver. Multicast forewarding 117 is controlled by a Layer 3 Multicast Routing Protocol (e.g. PIM-SM 118 [DRAFT-PIM-SM-NEW]). The UDLR Receiver is connected to an upstream 119 router via a UDLR tunnel. 121 Scenario D. A multicast routed-network, where the UDLR Receiver acts 122 as a multicast router. This receives a multicast service provided 123 from the upstream Feed Router. Multicast forewarding is controlled by 124 a Layer 3 Multicast Routing Protocol, (e.g. PIM-SM [DRAFT-PIM-SM- 125 NEW]). 127 Scenario E. An inter-domain multicast network, in which two or more 128 separate multicast domains are connected using the UDLR network. The 129 complexity of this scenario increases with the need to support other 130 protocols (e.g. MBGP, MSDP). 132 A simple network may have only one of these scenarios, but more 133 complex networks may have a combination. 135 1.1 Characteristics of UDLR networks 137 UDLR subnetworks present characteristics which differ significantly 138 from those experienced in the general Internet. These characteristics 139 lead to specific problems and raise specific issues that need to be 140 addressed to deploy an IP multicast service. This section identifies 141 specific characteristics that impact multicast performance resulting 142 from the asymmetry and the types of network over which the UDLR is 143 commonly implemented. These are: 145 1.1.1 Asymmetric routing paths 147 Unidirectional links give rise to differing forward (feed) and return 148 (tunnel) paths. Multicast routing protocols that use the "reverse 149 shortest path tree" towards the source as a part of their forwarding 150 decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not 151 work correctly over asymmetric routing paths. Solutions include the 152 use of UDLR [RFC 3077] and the use incongruent MBGP routing. 154 1.1.2 Asymmetric multicast capability 156 Asymmetric multicast capability is not a fundamental feature of UDLR. 157 In some UDLR networks both forward (feed) and return paths may 158 support native IP multicast. In other UDLR networks, a case may 159 arise where the forward link supports native multicast, whereas 160 return link may supports only unicast. UDLR routing allows a non- 161 broadcast/multicast link to be used for the return path by employing 162 a tunnel in the return direction [RFC2784]. 164 1.1.3 Forward link capacity 166 Since many UDLR networks employ wireless technology for the forward 167 (feed) link (e.g., [EN00]), there may be an appreciable cost for 168 forwarding traffic on the feed link. This leads to a desire to 169 prevent forwarding unnecessary multicast traffic, this implies the 170 need to control which groups are forwarded. However, other factors, 171 (e.g., asymmetric links, and asymmetric loss environment), may 172 suggest a desire to minimise the volume and frequency of control 173 messages in the return direction. 175 1.1.3 Asymmetric link capacity 177 The capacity of the forward (feed) and return (tunnel) paths may 178 differ significantly (e.g., forward link using DVB-S [EN00], return 179 using a GRE tunnel over a dial-up modem or ISDN interface for the 180 return path). The high normalised bandwidth ratio can lead to a 181 performance bottleneck, in addition the "cost" of setting up and 182 maintaining capacity in the reverse direction may be significantly 183 greater than in the forward direction [DRAFT-PILC-ASYM]. Although a 184 class of multicast applications do not require a return path for 185 their transport protocol (e.g. unidirectional transmission of 186 multimedia using RTP [DRAFT-AVT-RTP-NEW]), a path may still be 187 required for other supporting protocols (e.g. DNS, IGMP , Multicast 188 Routing). The cost of establishing and maintaining a return path for 189 these applications may be appreciable, especially considering its 190 minimal use. 192 1.1.4 Asymmetric loss environment 194 UDLR does not by itself introduce an imbalance in the packet loss 195 rate between the transmit and receive paths, however different link 196 technologies are often used to implement the forward (feed) and 197 return (tunnel) links of UDLR networks. In some important cases this 198 can lead to a significantly higher probability of packet loss in the 199 return direction [DRAFT-PILC-ASYM]. 201 1.1.5 Flat networks 203 The link technologies that are often used to implement the UDLR 204 feed link may support a multicast/broadcast capability that permits a 205 very large number of directly connected downstream receivers. For 206 example, a single satellite down-link may support 1tens of thousands 207 of UDLR Receivers. The numbers of Receivers connected via the same 208 physical link may be much larger than found in other common LAN 209 technologies, (e.g. Ethernet). Current routing protocols, and some 210 multicast application protocols do not scale to arbitrary large 211 numbers of participants. 213 1.1.6 Subnetwork round trip delay 215 UDLR does not by itself introduce an appreciable subnetwork round 216 trip delay, however many practical UDLR networks are built using 217 links that may introduce significant path delay (e.g. satellite 218 links). Since the subnetwork round trip delay impacts the performance 219 of the protocols that support the multicast service, the impact of 220 this delay needs to be considered. 222 2. Description of the Network Architecture 224 2.1 Topology 226 The UDLR protocol can be used over various types of unidirectional 227 links. Among these links we can list the DVB-S [EN00], DVB-T [], DAB 228 [] links and some cable modems technologies which are 229 unidirectionals. So far, the UDLR protocol has been mainly used in a 230 satellite environment (DVB-S) whose technology seems speader than the 231 others. 233 In this document we focus on the use of UDLR in a satellite 234 environment since most experiments have been performed with this 235 technology. A send-only feed is connected to the global Internet with 236 a bidirectional interface (e.g. Ethernet). It is also connected to 237 the unidirectional link with a send-only interface. There is no 238 receive-capable feed in the architecture. 240 A set of receivers is connected to the unidirectional link with a 241 receive-only interface. They all have a bidirectional interface (e.g. 242 Ethernet or ppp) connected to the Internet. The receivers can reach 243 the feed bidirectional interface through the Internet. 245 All the nodes connected to the unidirectional link, i.e. the feed and 246 the receivers, implement UDLR. As a result, every node can send a 247 unicast, a multicast or a broadcast layer-two frame over the 248 unidirectional link. A node can reach any other node as if they were 249 connected to a bidirectional broadcast network. In other words, nodes 250 are connected in a similar way to an Ethernet local area network. 252 Figure 1 depicts this architecture with a single feed and several 253 receivers: 255 Satellite 257 ~~~~ ---- ~~~~ 258 / /-| OO |-/ / 259 ~~~ ---- ~~~ 260 _/ \ \ 261 _/ \ \ 262 _/ \ \ Unidirectional 263 _/ \ \ Link 264 _/ \ \ 265 _/ \ \ 266 / \ \ 267 | | | 268 -------- -------- -------- ---------- 269 | Feed | |Recv 1| |Recv 2|---|subnet A| 270 -------- -------- -------- ---------- 271 | | | | 272 | | | | 273 ---------------------------------------------------- 274 | Internet | 275 ---------------------------------------------------- 277 Figure 1: Typical UDLR topology 279 Recv 1 is host, e.g., the end-user work station integrating a 280 satellite reception card. The host may have an ISDN or RTC connection 281 for a terrestrial Internet provided by a local ISP. 283 Recv 2 is a routeur connected to a local area network (Subnet A). 284 Other routeurs may be connected to the subnet and exchange routing 285 informations with Recv 2. Recv 2 may have an ISDN or RTC connection 286 for a terrestrial Internet provided by a local ISP. 288 The examples of terrestrial connecvities for a host or a router are 289 non-exhaustives, they may also use other technologies such as 290 Ethernet or GSM, etc. 292 The UDLR protocol supports the case where several feeds are connected 293 to a satellite. This case is not described in the document because 294 not as many experiments as with a single feed, have been performed. 296 2.2 Multicast Forwarding over UDLR 298 A UDLR Feed Router connected to an upstream multicast router MAY 299 choose to forward all received IP multicast packets on all forward 300 feeds, or MAY alternatively use a group management or routing 301 protocol to determine the set of multicast groups that must be 302 forwarded for each forward feed. 304 MUST forward all IPv4 packets with an address 224.0.0.0/24 [RFC 305 1122]. It MAY also forward all other packets with other multicast 306 addresses (224.0.0.0/4) [RFC 3171], but SHOULD use group membership 307 information to avoid forwarding packets belonging to groups for which 308 there are no downstream members connected via UDLR receiver(s) (see 309 section 4.2). In some cases, this forwarding will be controlled using 310 MAC address filters. Since a number of IPv4 multicast addresses are 311 often mapped to a common MAC address, address overlap may occur (e.g. 312 [RFC1122]). In this cases a Feed Router may determine the set of IP 313 multicast addresses in use, and hence the corresponding set of MAC 314 address and then choose to forward all IP groups that map to this set 315 of MAC addresses. 317 This is normal IP multicast routing behaviour. 319 The rules for forwarding those multicast packets received by the Feed 320 Router differ when the packets are received via the feed tunnel end- 321 point [RFC3077]. In this case, the Feed Router MUST forward all 322 multicast packets to the interfaces associated with: 324 (i) the list of send-only feed tunnel end-points 325 (ii) the forward feeds 326 (iii) the upper layer protocols of a multicast enabled Feed 327 Router (i.e., for possible forwarding to upstream multicast 328 router(s)). 330 In cases (ii) and (iii) the multicast forwarding does not include the 331 normal Reverse Path Forwarding (RPF) check, the normal processing of 332 the Time To Live (TTL) field, or the normal processing of 333 administratively scoped multicast addresses. 335 In addition, a UDLR Receiver MUST must perform normal multicast 336 forwarding of IP multicast packets received on the forward feed 337 interface, but MUST NOT forward any packets that were originated by 338 the same Receiver (i.e., were previously sent via the return 339 direction tunnel). This later requirement is equivalent to an RPF 340 check. Multicast packets received by the node on other (i.e., non- 341 feed) interfaces MUST be forwarded to the Feed Router using the 342 return tunnel interface. 344 3.0 Layer 2 Protocols 346 3.1 Hardware Address Resolution 348 A hardware address resolution can be used over UDLR to allow a node, 349 e.g. a feed or a receiver, to discover the MAC address of another 350 node. 352 Regardless of whether the link is unidirectional or bidirectional, if 353 a nodes sends a packet over a non-point-to-point type network, it 354 requires the data link address of the destination. ARP [RFC826] is 355 used on Ethernet networks for this purpose. 357 This mechanism usually requires that the underlying transmission 358 media is bidirectional in order for a node to obtain the data link 359 address of a destination. The node sends an ARP REQUEST over the link 360 and waits for an ARP RESPONSE from the destination that contains its 361 data link address. Upon reception of the ARP response, the node can 362 then send traffic to the destination. Note that an ARP REQUEST is 363 broadcast-type frames, all nodes connected to the link receive it and 364 process it. An ARP RESPONSE is a unicast-type frame, only the 365 receiver whose hardware address is identical the MAC destination 366 address of the frame processes it. 368 3.1.1 Hardware Address Resolution protocol over UDLR 370 In a satellite environment, receivers connected to a DVB-S link use 371 reception cards which have their own unique hardware address. This 372 hardware address is 6-bytes long, like an Ethernet address. It may be 373 then sensible to use a mechanism similar to [RFC826] for a feed to 374 discover the hardware address of a receiver. Thanks to the UDLR 375 protocol which emulates a bidirectional connectivity over the 376 satellite link. It allows a receiver to send back to the feed layer 377 two packets such as ARP responses. 379 Note that, for other satellite data link formats different from DVB- 380 S, receivers still have a unique hardware address and a similar 381 address resolution protocol based on exchanging REQUEST and RESPONSE 382 messages may be used. 384 In a topology where we have a feed and a number of receivers 385 connected to the satellite link, there are 3 typical hardware address 386 resolution scenarios: 388 i) Scenario 1: A feed needs a receiver's hardware address. 390 This usually occures when a feeds has to send a unicast IPv4 391 packet to a receiver whose MAC address is unknown. 393 The feed sends an ARP REQUEST over the satellite link whose 394 payload contains the IP address of the receiver. All the 395 receivers listen to the ARP REQUEST. The receiver which 396 recognizes its IP address in the payload sends an ARP RESPONSE 397 back to the MAC address of the feed. Note, the ARP REPONSE 398 reaches the feed through the UDLR GRE tunnel. Upon reception of 399 the ARP RESPONSE, the feed obtains the receiver MAC address from 400 the payload and can send IPv4 packets to it. 402 ii) Scenario 2: A receiver needs the feed's hardware address. 404 This usually occures when a receiver has to send a unicast IPv4 405 packet to the feed whose MAC address is unknown. 407 The data link layer of the receiver creates a ARP REQUEST which 408 is sent through the UDLR GRE tunnel. The ARP REQUEST payload 409 contains the IP address of the feed. Upon reception of the ARP 410 REQUEST, the feed which recognizes its IP address in the payload 411 sends over the satellite link an ARP RESPONSE to the MAC address 412 of the receiver. Upon reception of the ARP RESPONSE, the 413 receiver obtains the feed MAC address from the payload and can 414 send IPv4 packets to it. 416 iii) Scenario 3: A receiver needs a receiver's hardware address. 418 This usually occures when a receiver has to send a unicast IPv4 419 packet to another receiver whose MAC address is unknown. 421 The receiver sends an ARP REQUEST, which contains the IP address 422 of a receiver, through the UDLR GRE tunnel. Upon reception of 423 the frame, the feed forwards it over the satellite as it is a 424 broadcast-type frame (see [RFC3077] for details). 426 All the receivers listen to the ARP REQUEST. Only the receiver 427 which recognizes its IP address in the payload sends back an ARP 428 RESPONSE to the requesting receiver. The ARP RESPONSE is sent 429 through the UDLR GRE tunnel to the feed. Upon reception of the 430 frame, the feeds figures out that the destination MAC address is 431 a receiver's one and then forwards it over the satellite link 432 (see [RFC3077] for details). The requesting receiver receives 433 the ARP RESPONSE, obtains the desired MAC address and can send 434 IPv4 packets to it. 436 These 3 scenarios allow any node connected to the satellite link to 437 obtain the MAC address of any other node. 439 3.1.2 Issues using a hardware resolution protocol over UDLR 441 The scenarios described in Section 3.1.1 raise a number of issues 442 when using a hardware resolution protocol over UDLR in a satellite 443 environment. 445 3.1.2.1 Long round trip delays 447 Regarding to scenarios 1 and 2, it requires over 250 milliseconds for 448 a node, a feed or a receiver, to obtain the MAC a destination of a 449 destination. 250 milliseconds is the fix and uncompressable satellite 450 link propagation delay. It should also be added to it the propagation 451 delay on the terrestrial link from the receiver to the feed. This 452 delay may vary from a few milliseconds up to a couple of hundred 453 milliseconds depending on the receiver's connectivity. E.g., a slow 454 GSM connectivity has a significative impact on the overal round trip 455 time whereas a fast T1 access has very little impact. 457 Because of long round trip delays, reactive address resolution 458 methods may not work well in some cases. For example, a feed may have 459 to forward UDP unicast packets at high data rates to a receiver whose 460 hardware address is unknown. The stream of packets is passed to the 461 link-layer driver of the feed send-only interface. When the first 462 packet arrives, the link-layer realizes it does not have the 463 corresponding hardware address of the next hop, and sends an ARP 464 request. While the link-layer is waiting for the response (at least 465 250 milliseconds), IP packets are buffered by the feed. If it runs 466 out of space before the ARP response arrives, IP packets will be 467 dropped. However, for TCP traffic, this should not happen since the 468 first TCP packet sent to a receiver whose MAC address is unknown, is 469 generally a TCP SYN indicating the start of a new session. This 470 packet is not followed by a stream of packet until the receiver 471 replies to it. Therefor not many packets are buffered or lost for the 472 session. Note that subsequent IP packets sent to the same receiver 473 hop are not buffered anymore as long as the ARP entry is valid. 475 Regarding to scenario 3, the round trip delay between two receivers 476 is twice the round trip delay of scenarios 1 and 2. Both, the ARP 477 REQUEST and ARP RESPONSE are sent over the terrestrial network 478 through UDLR GRE tunnel and over the satellite link. An IP packet 479 delivered to the data link whose next hop MAC address is unknown, 480 must be buffered at least 500 milliseconds before being sent. 482 In order, to make a reactive harware address resolution protocol more 483 efficient in scenario 3, i.e. to reduce the round trip delay, it 484 might be sensible to configure an ARP server at the feed. The feed 485 would learn MAC addresse from ARP RESPONSES it receives from 486 receivers and would publish them as soon as a receiver requests one 487 of them. This mechanism would reduce the round trip down to 250 488 milliseconds, the feed would answer to an ARP REQUEST instead of a 489 receive reducing the latency. 491 3.1.2.2 Large number of receivers 493 Due to the large number of receivers which may be connected to the 494 satellite link, it is necessary to be able to allocate a sufficient 495 number of ARP entries in a ARP table. A feed may need to send unicast 496 packets to thousand of different receivers. For each of the 497 receivers, a correspondance between a MAC address and the IP address 498 of a receiver must be maintained. 500 Furthermore, when the size of the ARP table is significant, the 501 search for a MAC address corresponding to the next hop IP address 502 must be performed rapidely in order to prevent IP packets from being 503 buffered too long. 505 It is also common to associate an expiration date to an ARP entry in 506 order not to keep an entry for ever. After being deleted, an ARP 507 entry associated to a receiver is renewed when an IP packet is sent 508 again to this receiver. The main reasons for aging entries are: 510 - Automatic discovery of a receiver new MAC address. One may 511 replace the reception card of a receiver for maintainance puposes. 512 The IP address of the receiver does not change but its MAC address 513 does. When deleting the ARP entry of this receiver, a new IP 514 packet destined to it triggers the request of its new MAC address. 516 - ARP table size adjustable. Receivers may not be constantly 517 connected to the satellite link. During idle periods, it is then 518 not necessary to keep an ARP entry for these receivers. The size 519 of the ARP table can then be adjusted to the number of active 520 receivers. 522 3.2 PPPoE 524 4.0 Layer 3 Protocols 526 4.1 Dynamic Host Configuration Protocol 528 The Dynamic Host Configuration Protocol (DHCP) provides a framework 529 for passing configuration information to hosts on a TCPIP network, 530 and a mechanism for automatic temporary allocation of network 531 addresses. 533 4.1.1 DHCP Overview 535 DHCP is based on Bootstrap Protocol (BOOTP). It consists of two 536 components: a protocol for delivering host-specific configuration 537 parameters from a DHCP server to a host (default gateway, DNS server) 538 and a mechanism for allocation of network addresses to hosts. DHCP 539 [RFC 2131] defines a set of transactions between a DHCP server and a 540 DHCP client to afford/request a valid network address, configuration 541 parameters or both. These transactions are constructed by DHCP 542 messages defined in RFC2131 (DHCPDISCOVER, DHCPREQUEST, DHCPOFFER) 543 that could include DHCP options defined in RFC2132. 545 DHCP runs over UDP. It uses port 67 on server's side, and port 68 on 546 client's side. A DHCP client is not supposed to know the DHCP 547 server's IP address initially. 549 When a host needs to acquire an IP address and eventually 550 configuration parameters, it broadcasts a DHCPDISCOVER message on its 551 physical subnet. Relay agents (if running on connected routers) may 552 pass the message on to DHCP servers not on the same physical subnet. 554 One or more DHCP server may respond to the client by proposing a 555 network address in a DHCPOFFER message. Server may probe the offered 556 address with an ICMP Echo Request. 558 The client may receive one or more offers. It broadcasts anyway a 559 DHCPREQUEST message that contains a server identifier option, and 560 eventually other options, to notice all DHCP servers of its 561 selection. 563 The selected server sends a DHCPACK message to confirm allocation. 564 The client may probe a last time the allocated address (e.g. ARP 565 request). This is a typical example of a successful DHCP transaction. 567 There are other DHCP transactions, messages and options. Please refer 568 to [RFC2131] for a complete description of DHCP protocol, and to 570 [RFC2132] for a complete description of DHCP options. 572 4.1.2 DHCP over UDLR 574 LLTM mechanism makes nodes connected to the UDL see themselves on the 575 same logical Local Area Network. Encapsulating layer-two frames allow 576 them to be sent in unicast and broadcast through Internet and UDL. 577 Thanks to this feature, DHCP can run on networks using UDLR 578 architecture, i.e. satellite networks. DHCP may be a solution to IP 579 addressing scalability and increasing number of nodes on such 580 networks. e.g. A node can be assigned a temporary network address 581 from a pool of public addresses . DHCP provides also a means of 582 requesting and getting local configuration parameters for clients 583 from their ISP. 585 4.1.2.1 Configuration and tuning guidelines 587 Before sending a DHCP request, a client node needs Layer-two 588 connectivity to one DHCP server at least. Actually, a common use of 589 DHCP consists of making a DHCP client send DHCPDISCOVER message at 590 boot. While using DHCP over UDLR, DHCP client messages should be sent 591 only after establishing the GRE tunnel. Therefore, use of DHCP should 592 be taken into account while dimensioning the DTCP HELLO message 593 periodicity. 595 Lease duration and address pools' width, configured on DHCP server 596 side, depend on the number of nodes to serve and the nature of 597 offered services. Lease duration should not be too short to avoid an 598 increasing DHCP traffic and the risk of inability of renewing leases. 599 And should not be too long to avoid misusing addresses and increasing 600 the blocking probability. 602 A DHCP server can reassign addresses allocated before. It may check 603 an address before reallocation by an ICMP echo request; and the 604 client may do the same, after receiving an address, by an ARP 605 request. Such messages should be allowed to avoid address conflicts. 607 A DHCP server can be located on a receiver or a feed. For security 608 and delay considerations, implementing DHCP server on feed's side 609 reduces transaction duration to a half, and prevents from allocating 610 a lease by an unauthorised DHCP server. 612 Client sends DHCPRELEASE message to notice the server that client has 613 relinquished the lease. Some implementations of DHCP client keep 614 configuration information even after sending a DHCPRELEASE message. 615 This may lead to an address conflict and reduces the available 616 address pool. 618 DHCP servers and clients should take into account network transit 619 delay while assigning timers: DHCP messages retransmission timeout, 620 maximum delay that a DHCP server waits before deciding that the 621 absence of an ICMP echo response means that the relevant address is 622 free. 624 The global delay of a successful DHCP transaction is composed of: 626 1) One or two RTTs (Round Trip Time) for DHCP transaction. I.e. 627 requesting and acquiring a lease is done by exchanging four 628 messages, renewing a lease is done by exchanging two messages. 630 2) More than one RTT, which is the time needed to check the 631 availability of a network address. E.g. ICMP echo. 633 3) Time needed to read/write configuration and database files on 634 both server and client sides. 636 DHCP clients may also retransmit DHCP messages if they do not receive 637 a response. Some client implementations timeout DHCPDISCOVER message 638 (for example) on an Ethernet delay basis. And a DHCP server may 639 respond to DHCPDISCOVER retransmission before that checking lease 640 availability (by an ICMP echo request) timeout expires, resulting on 641 an eventual address conflict. 643 4.1.2.2 Security issues 645 DHCP works over UDP/IP stack. These protocols are not inherently 646 secure. And UDLR technology is widely used over links that may be 647 easily accessed. Some DHCP messages (e.g. DHCPDISCOVER) are layer-two 648 broadcasted on the UDL, a malicious DHCP server may allocate network 649 addresses or false configuration information. An unauthorised host 650 may capture information sent to a DHCP client; Configuration 651 information can be then set manually. Link layer or IP security 652 mechanisms are of great interest. 654 Authorising DHCP server to serve unknown clients should be done with 655 special attention. DHCP permits authentication on a hardware address 656 basis through DHCP header and options, on the other hand LLTM 657 mechanism encapsulates layer-two frames. Authentication is another 658 important security feature. 660 DHCP transactions should be allowed after client authentication. 662 4.2 Issues using IGMP over UDLR 664 The Internet Group Management Protocol (IGMP) [RFC1112, RFC2236, RFC- 665 IGMPv3] is used in multicast edge networks (i.e., an Ethernet LAN or 666 the UDLR Scenarios A and B). Forwarded between multicast routers is 667 controlled by a different protocol (see section 5). The first version 668 of IGMP, IGMPv1 [RFC1112] is little used. At the time of writing, 669 most current end hosts use IGMPv2 [RFC2236]. IGMPv3 is increasingly 670 being deployed [RFC-IGMPv3]. A MIB has also been defined [RFC2933]. 672 IGMP messages are sent with an IPv4 Time To Live (TTL) of 1, 673 indicating these are link local. On a UDLR return link, these 674 messages are sent using the return link tunnel, and retransmitted 675 over the feed (see 1.1.1). 677 4.2.1 Basic IGMP Operation 679 IGMP Membership Reports are sent by end hosts to communicate their 680 desire to receive specific IP multicast groups. Multicast routers in 681 the same subnetwork use IGMP Membership Reports to help determine 682 whether IP multicast packets should be forwarded to the subnetwork. 683 Multicast routers may already be forwarding this group, if not they 684 start to forward IP multicast packets for the reported group after 685 the subnetwork RTT plus any additional delay required for the Feed 686 Router to join the requested multicast flow. 688 To validate the set of currently active groups, one multicast router 689 per subnetwork (the Querier) periodically sends a multicast packet 690 containing an IGMP Group Membership Query to all end hosts (i.e., 691 using the IPv4 address 224.0.0.1). The Query Interval must be greater 692 than the sum of the Max Response Time and the Subnetwork Round Trip 693 Time, and is typically much larger. The Query message is received by 694 all systems in the subnetwork that have multicast enabled. This 695 mechanism also acts as an opportunity for end hosts to resend a 696 Membership Report which was not received by the UDLR Feed Router. 698 Each end host sets a random timer for each group it wishes to 699 receive. When the timer expires, it responds with one IGMP Group 700 Membership Report for each group which it wishes to receive. IGMP 701 includes a technique to reduce the number of Reports received by the 702 querier. This suppression mechanism relies upon visibility of the 703 responses sent by all members of the multicast group (i.e., the UDLR 704 Feed Router must re-send received Membership Reports on the all 705 feeds). If the other group members do not receive copies of the 706 Membership Reports, they will each send one Membership Report per 707 query, Groups which contain many members therefore generate a large 708 volume of return traffic. 710 Even when suppression is used, a large subnetwork RTT, may lead to 711 many receivers sending IGMP Membership Reports for the same group(s) 712 within the Max Response Time [RFC2236]. If it is known that there 713 may be many group members, one mitigation is to increase the Max 714 Response Time. which allows suppression to occur after one 715 Subnetwork RTT. 717 A Querier that identifies a previously forwarded group that currently 718 has no group members will send several (Robustness Variable) Queries 719 each separated by the Query Interval. The Query Interval must be 720 greater than the sum of the Max Response Time and the Subnetwork 721 Round Trip Time. If no Membership Reports are received for a specific 722 group (i.e., after a total period called the Group Membership 723 Interval) the multicast routers stop forwarding multicast packets 724 with this group address. Decreasing the Robustness Variable and/or 725 the Query Interval reduces the time to detect the last memebr 726 leaving a group(s). This can reduce the volume of unnecessary 727 multicast traffic sent over a UDLR feed link. Reducing the 728 Robustness Variable also reduces tolerance to loss of Membership 729 Reports sent over the return link (see 1.1.4). 731 The number of Membership Reports is an issue for flat networks (see 732 1.1.5), particularly if they also exhibit a larger subnetwork RTT 733 (see 1.1.6). The number sent for each group is a function of the 734 number of systems that wish to receive the group, the Subnetwork RTT, 735 and the Max Response Time. Suppression requires the multicast packets 736 containing multicast Membership Reports received from UDLR Receivers 737 to be forwarded by the UDLR Feed Router. 739 A large Max Response Time, can reduce the number of redundant 740 Membership Reports, reducing return link traffic, but it also has the 741 drawback of increasing the leave latency. This may, in turn, increase 742 the volume of traffic unnecessarily forwarded on the forward link 743 when there are no remaining group members. This is an issue for UDLR 744 networks with limited forward link capacity (see 1.1.3). 746 4.2.2 IGMPv2 Leave Processing 748 In IGMPv1, it may take a considerable time for a multicast router to 749 discover there are no remaining end hosts interested in a group that 750 it is already forwarding. A refinement in IGMPv2 [RFC2236] allows end 751 hosts to send a Leave message explicitly indicating the group address 752 which the end host wishes to leave. This message is sent to an IPv4 753 address of 224.0.0.2. In some, but not all implementations, end hosts 754 will suppress sending an IGMP Leave message when they believe there 755 are other remaining group members. 757 Reception of an IGMP Leave message is not sufficient for a forwarding 758 multicast router to determine that there are no longer any end hosts 759 interested in a group. The Querier therefore responds by sending a 760 Group-Specific Query to request responses from other end hosts 761 interested in the group. If no Membership Report is received, the 762 Query is repeated each Last Member Query Interval up to Last Member 763 Query Count times, after which it will conclude there are no 764 remaining group members. This allows multicast routers to more 765 quickly stop transmission of multicast packets to groups for which 766 there are no longer any active receivers. The value for Last Member 767 Query Interval may be tuned, but MUST be greater than the Subnetwork 768 RTT. The time taken to terminate an IP multicast flow is therefore 769 the sum of the subnetwork RTT and the delay introduced by the IGMP 770 Querier. 772 4.2.3 IGMPv3 Operation 774 IGMPv3, allows an end host to report an interest in receiving not 775 only a specific group address, but also from a specific set of IP 776 source addresses (or all except a specific set of IP source 777 addresses). This allows finer control over the multicast packets 778 forwarded to the subnetwork. This may conserve link capacity, 779 especially when a system switches from receiving one multicast group 780 to another. 782 End hosts that receive an IGMPv3 Query start a random timer. The 783 maximum value is specified as a parameter in the Query, allowing an 784 appropriate scaling factor to be selected based on the anticipated 785 size of the group and the Subnetwork RTT. IGMPv3 Membership Reports 786 are sent to a specific multicast address (i.e. the IPv4 address 787 224.0.0.22). A potential modification to UDLR would allow this group 788 to be filtered by the Feed Router. 790 One significant change in IGMPv3, is that end hosts MUST send 791 Membership Reports following a Query to indicate the groups they wish 792 to receive (i.e., there is no suppression), although a single message 793 may report several groups. This may increase the number of IGMP 794 messages sent over a subnetwork. This can consume both feed and 795 tunnel capacity (see 1.1.3, 1.1.4). To mitigate this in flat 796 networks (see 1.1.5) or networks with a large subnetwork RTT (see 797 1.1.6), IGMPv3 therefore also allows the use of much larger response 798 times. 800 An advantage of IGMPv3 is that it allows routers (and connected LAN 801 switches) to provide explicit tracking of which end hosts request 802 each group. Explicit tracking allows routers to discover immediately 803 when the last group member leaves, and suspend forwarding of the 804 group within a Subnetwork RTT. 806 4.2.4 Forwarding Groups at the Receiver based on IGMP 808 Note that in IGMPv1 and IGMPv2, Leave and Membership Report messages 809 are sent to the same group destination address as the group it is 810 notifying. A bridged (Scenario B) solution requires these messages 811 to be parsed at the UDLR receiver in order to establish an 812 appropriate filter set to forward multicast packets to the attached 813 end hosts. One scheme is called Snooping [DRAFT-MAGMA-SNOOP]. 814 Separating these Membership Reports from multicast traffic can be 815 processor intensive and may impact performance, many Ethernet LAN 816 switches employ ASICS to optimise this processing. 818 4.3 IGMP-Proxy 820 The IGMP Querier function is normally implemented in a multicast 821 Router, and the IGMP client in a multicast end host. It is also 822 possible to implement the IGMP protocol within UDLR Receiver, this is 823 called an IGMP membership Proxy [DRAFT-MAGMA-PROXY, DRAFT-MAGMA- 824 SNOOPING]. 826 Consider Scenario B. An IGMP membership proxy at the UDLR Receiver 827 behaves as if it were an end host (i.e., sends IGMP Membership 828 Reports for groups it wishes to receive) in response to IGMP Queries 829 received over the UDLR forward feed. 831 The receiver also executes an IGMP Querier for the attached LAN and 832 therefore sends IGMP Queries. The Membership Reports received by the 833 Receiver allow it to collect group membership information, which can 834 be directly used to control forwarding of multicast packets received 835 over the UDLR feed. 837 An IGMP Proxy may use different group membership protocols on the 838 UDLR and LAN networks. This could be a mixture of IGMPv2 and IGMPv3, 839 or could possibly be a modified protocol on the UDLR network. 841 An IGMP Proxy may also implement Proxy Reporting [DRAFT-MAGMA- 842 SNOOPING; DRAFT-MAGMA-PROXY], where the proxy only reports which 843 sources and groups need to be forwarded. This can significantly 844 reduce the number / frequnecy of Reports. A UDLR Receiver employing 845 an IGMP Proxy can separate the distribution of group membership 846 information into the UDLR subnetwork and any attached networks 847 connected via a UDLR client. This allows the protocol parameters 848 used within the UDLR network to be tuned. 850 4.4 Dense Mode Multicast Routing 852 4.4.1 DVMRP 854 4.4.2 Dense Mode PIM (PIM-DM) 856 4.5 Sparse Mode Multicast Routing 857 4.5.1 Sparse Mode PIM (PIM-SM) 859 The issues of PIM-SM operation on unidirectional links are: 861 1. Reverse Path Forwarding 862 2. Rendezvous Point selection 863 3. Designated Router selection 865 This section describes these issues in details. In this section, all 866 nodes are assumed to be PIM-SM routers (Scenario D) and the UDL runs 867 PIM-SM as the only multicast routing protocol. 869 Reverse Path Forwarding 871 In the case of UDLR Receivers do not use the Feed Router to forward 872 unicast traffic to multicast sources and the Rendezvous Point, the 873 receivers do not send PIM-SM Join/Prune messages to the Feed Router. 874 As the result, multicast traffic does not flow on the unidirectional 875 link. This is the PIM-SM reverse path problem on unidirectional 876 links. 878 There are two solutions, at least, for this problem: 880 1. Configure UDLR receive networks to route unicast traffics to all 881 possible multicast sources and Rendezvous Points via the Feed 882 router. 884 2. Prevent multicast listeners in UDLR receive networks from 885 switching to the shortest-path tree of multicast sources located 886 outside the receive network. In this scheme, the UDL receive 887 networks only need to route unicast traffic to all possible 888 Rendezvous Points via the Feed Router. 890 If the possible multicast sources includes all hosts in the Feed 891 network, then the first option is to route traffic to the Feed 892 network via the Feed Router. The second option simplifies the routing 893 requirement from routing to all hosts in the Feed network to routing 894 to the possible Rendezvous Points. The second option, however, 895 doesn't work on SSM destination addresses. [DRAFT-PIM-SM-NEW] 896 specifies some rules concerning the SSM destination addresses 897 overriding the normal PIM-SM behavior. This document states that a 898 router MUST NOT send a (*,G) Join/Prune message for any reason, thus 899 PIM-SM never uses the rendezvous-point tree for traffic to SSM 900 destination addreses. 902 Rendezvous Point selection 904 The Feed network can advertise routes to the possible Rendezvous 905 Points using unicast routing protocols natively such that the UDLR 906 receive networks route to them via the Feed Router. This scheme 907 causes UDLR receive networks to route all networks between the Feed 908 Router to the possible Rendezvous Points via the Feed Router. To 909 minimize the number of networks routed via the Feed Router, the 910 possible RPs should be as close as possible to the Feed Router. This 911 number reaches the minimum if the Feed Router's unidirectional link 912 interface address is the only possible Rendezvous Point. 914 In the case where no unicast routing protocol is running on the uni- 915 directional link and unicast routing advertisements are limited only 916 within each Feed network and Receive network, the UDLR receive 917 networks may use static routes. Static routes to the possible RPs via 918 the Feed router are set on the UDL receivers and they are injected to 919 the receive network's unicast routing protocol. 921 Designated Router selection 923 A PIM-SM router performs Designated Router election on each 924 interface. A DR has the task to send PIM-SM Register packets and to 925 send Join/Prune messages toward the RP or the multicast source. The 926 DR election is important for unidirectional links if multicast 927 listeners exist. If a multicast listener exists on a unidirectional 928 link, the Feed Router should be elected as the DR for the 929 unidirectional link to avoid the overhead due to the LLTM mechanism. 930 In the Scenario 5, DR election result is not important as all UDL 931 nodes are multicast routers. 933 A PIM-SM router sends Hello messages periodically every Hello_Period 934 to each active inteface. In addition, a PIM-SM router also sends a 935 Hello message when Hello message is received from a new neighbor, or 936 a Hello message with a new GenID is received from an existing 937 neighbor. a PIM-SM router will remove a neighbor if it does not 938 receive any neighbor's Hello message in the HoldTime advertised by 939 the neighbor. 941 The number of neighbors is an issue for flat networks (see 1.1.5). 942 The bandwidth consumption Periodic Hello messages can be reduced by a 943 large Hello_Period. A large HoldTime can reduce the probability of 944 removing a PIM-SM neighbor due to Hello message packet loss, thus 945 reducing the probability of a Hello message storm. However, the 946 probability of a router reboot on flat networks having many nodes may 947 be high, thus the probability of a Hello message storm due to 948 receiving a Hello message with a new GenID from a newly rebooted 949 neighbor. 951 Join/Prune messages are sent periodically toward the multicast source 952 or the RP. An overriding Join is also sent by a router having a 953 multi- cast state if it receives a Prune of that multicast state sent 954 by a neighbor to the upstream router. If a PIM-SM router receives a 955 Join with the same state, it can suppress sending a Join message of 956 the same state. 958 Join message suppression can reduce the bandwidth consumption of a 959 shared link. For flat networks with many nodes or large round trip 960 delay, a large Override interval will help. The large Override 961 interval value causes a large Prune Pending Timer, thus multicast 962 traffic will flow for a longer time on the unidirectional link even 963 though there is no more downstream routers. 965 4.5.2 PIM-SM RPs and MSDP 967 5. Security Considerations 969 The recommendations contained in this document do not impact the 970 integrity of IP multicast transport protocols, or applications using 971 IP multicast transport protocols. 973 There are known Denial of Service (DoS) attacks that can be staged 974 ... XXX 976 The broadcast nature of the forward feed... XXX 978 There are known vulnerabilities when using tunnels.... XXX 980 6. Conclusions 982 7. Acknowledgements 984 8. References 986 8.1 Normative References 988 [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 989 37, RFC 826, November 1982 991 [RFC1112] Deering, S.E., "Host extensions for IP multicasting", 992 RFC1112, 1989, (STD0003). 994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 995 Requirement Levels", BCP 14, RFC 2119, March 1997. 997 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 998 2", 1997, RFC 2236, (Proposed Std). 1000 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P., 1001 "Generic Routing Encapsulation (GRE)", RFC2784, (Proposed 1002 Std). 1004 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 1005 Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional 1006 Links', RFC 3077, March 2001 1008 [RFC-IGMPv3] "Internet Group Management Protocol, Version 3", 1009 (Author's note, with IESG - this reference needs to be 1010 solved when issued as an RFC). 1012 8.2 Informative References 1014 [DRAFT-AVT-RTP-NEW] Schulzrinne/Casner/Frederick/Jacobson, "RTP: A 1015 Transport Protocol for Real-Time Applications, , Work in Progress. 1018 [DRAFT-MAGMA-SNOOP] M. Christensen, F. Solensky "IGMP and MLD 1019 snooping switches", , Work 1020 in Progress. 1022 [DRAFT-MAGMA-PROXY] Fenner, B. et al, "IGMP-based Multicast 1023 Forwarding (IGMP Proxying)", , (Author's note: not in ID archive), Work in 1025 Progress. 1027 [DRAFT-PILC-ASYM] Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst, 1028 M. Sooriyabandara, "TCP Performance Implications of 1029 Network Path Asymmetry", , 1030 Work in Progress. 1032 [DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, 1033 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1034 Protocol Specification (Revised)", , Work in Progress. 1037 [EN00] "Digital Video Broadcasting (DVB); Interaction Channel for 1038 Satellite Distribution Systems", Draft European Standard 1039 (Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1 1041 [RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson, 1042 "RTP: A Transport Protocol for Real-Time Applications", 1043 1996, (Proposed Std). 1045 [RFC2933] K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group 1046 Management Protocol MIB", RFC2933, 2000, (Proposed Std). 1048 [RFC2402] Kent, S., Atkinson., R., "IP Authentication Header", 1049 RFC2402, 1998, (Proposed Std). 1051 [RFC2406] Kent, S., Atkinson., R., "IP Encapsulating Security Payload 1052 (ESP)", RFC 2406, 1998, (Proposed Std). 1054 [RFC3171] Albanna, Z., K. Almeroth, D. Meyer, M. Schipper. "IANA 1055 Guidelines for IPv4 Multicast Address Assignments", 2001, ( 1056 BCP0051) 1058 [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group 1059 Management Protocol (IGMP)", RFC3228, 2002, (BCP0057). 1061 9. Authors' Addresses 1063 In alphabetic order: 1065 Emmanuel Duros 1066 UDcast 1067 2455 Route des Dolines BP355 1068 06906 Sophia Antipolis France 1069 France 1070 EMail : Emmanuel.Duros@UDcast.com 1072 Godred Fairhurst 1073 Department of Engineering 1074 Fraser Noble Building 1075 University of Aberdeen 1076 Aberdeen AB24 3UE 1077 UK 1078 Email: gorry@erg.abdn.ac.uk 1079 Web: http://www.erg.abdn.ac.uk/users/gorry 1081 Achmad Husni Thamrin 1082 Graduate School of Media and Governance 1083 Keio University 1084 5322 Endo, Fujisawa 1085 Kanagawa 252-8520 1086 Japan 1087 Email: husni@ai3.net 1089 Amine Lamani 1090 France Telecom Research and Development 1091 Satellite Networks Architecture 1092 38-40, rue du General Leclerc, 92794 1093 ISSY-LES-MOULINEAUX cedex 9 1094 FRANCE 1096 10. Full Copyright Statement 1098 "Copyright (C) The Internet Society (date). All Rights Reserved. This 1099 document and translations of it may be copied and furnished to 1100 others, and derivative works that comment on or otherwise explain it 1101 or assist in its implementation may be prepared, copied, published 1102 and distributed, in whole or in part, without restriction of any 1103 kind, provided that the above copyright notice and this paragraph are 1104 included on all such copies and derivative works. However, this 1105 document itself may not be modified in any way, such as by removing 1106 the copyright notice or references to the Internet Society or other 1107 Internet organizations, except as needed for the purpose of 1108 developing Internet standards in which case the procedures for 1109 copyrights defined in the Internet Standards process must be 1110 followed, or as required to translate it into languages other than 1111 English. 1113 The limited permissions granted above are perpetual and will not be 1114 revoked by the Internet Society or its successors or assigns. 1116 11. IANA Considerations 1118 There are no IANA considerations associated with this draft.