Network Working Group For list of authors Internet-Draft See Authors' section July 2003 Expires december 2003 Experiments with RFC 3077 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groupsmay also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract In March 2001, [RFC 3077] was published and describes a protocol which allows to integrate unidirectional links in the Internet. Since then, a number of experimentations and deployements using this protocol have been led. This document presents various protocols, e.g. layer 2 and layer 3 protocols, which have been commonly used over [RFC 3077] in a satellite environment. This document raises issues for each of these protocols. Table of Contents 1. Characteristics of Uni-Directional Links .................... X 1.1. Characteristics of UDLR networks ............................ X 1.1.1. Asymmetric routing paths .................................. X 1.1.3. Forward link capacity ..................................... X Authors [Page 1] Internet Draft Experiments with RFC 3077 July 2003 1.1.3. Asymmetric link capacity .................................. X 1.1.4. Asymmetric loss environment ............................... X 1.1.5. Flat networks ............................................. X 1.1.6. Subnetwork round trip delay ............................... X 2. Description of Network Architecture ......................... X 2.1. Topology .................................................... X 2.2. Multicast Forwarding over UDLR .............................. X 3.0. Layer 2 Protocols ........................................... X 3.1. Hardware Address Resolution ................................. X 3.1.1 Hardware Address Resolution protocol over UDLR ............. X 3.1.2 Issues using a hardware resolution protocol over UDLR ...... X 3.1.2.1 Long round trip delays ................................... X 3.1.2.2 Large number of receivers ................................ X 3.2. PPPoE ....................................................... X 3.2.1 Introduction ............................................... X 3.2.2 Architecture ............................................... X 3.2.2.1 Specificities ............................................ X 3.2.2.2 Description of a connection .............................. X 3.2.3 Advantages ................................................. X 3.2.4 Limitations ................................................ X 3.2.5 Security Issues ............................................ X 4.0. Layer 3 Protocols ........................................... X 4.1. Dynamic Host Configuration Protocol ......................... X 4.1.1. DHCP Overview ............................................. X 4.1.2. DHCP over UDLR ............................................ X 4.1.2.1. Configuration and tuning guidelines ..................... X 4.1.2.2. Security issues ......................................... X 4.2. Issues using IGMP over UDLR ................................. X 4.2.1. Basic IGMP Operation ...................................... X 4.2.2. IGMPv2 Leave Processing ................................... X 4.2.3. IGMPv3 Operation .......................................... X 4.2.4. Forwarding Groups at the Receiver based on IGMP ........... X 4.3. IGMP-Proxy .................................................. X 4.4. Dense Mode Multicast Routing ................................ X 4.4.1. DVMRP ..................................................... X 4.4.2. Dense Mode PIM (PIM-DM) ................................... X 4.5. Sparse Mode Multicast Routing ............................... X 4.5.1. Sparse Mode PIM (PIM-SM) .................................. X 4.5.2. PIM-SM RPs and MSDP ....................................... X 5. Security Considerations ..................................... X 6. Conclusions ................................................. X 7. Acknowledgements ............................................ X 8. References .................................................. X 8.1. Normative References ........................................ X 8.2. Informative References ...................................... X 9. Authors' Addresses .......................................... X 10. Full Copyright Statement .................................... X 11. IANA Considerations ......................................... X Authors [Page 2] Internet Draft Experiments with RFC 3077 July 2003 1. Characteristics of Uni-Directional Links This document describes issues that concern use of UDLR networks [RFC3077] to support the IP multicast service. In this document it is assumed that the feed router is a multicast router [RFC1122]. The format of an IPv4 multicast packet [RFC 1112] is identical to that of an IPv4 unicast packet and is distinguished only by a special class of destination address (class D, i.e., addresses in the range from 224.0.0.0 to 239.255.255.255). There are five distinct multicast scenarios. The issues that arise and the approaches to be recommended will be a function of these scenarios. The list of scenarios to be addresses is: Scenario A. An edge-network, where end hosts receive a multicast service from an upstream router via the Feed Router. Multicast forwarding is controlled via a group memberhip protocol (e.g. IGMP [RFC2236]). Each end host is directly via a UDLR feed link. Scenario B. A bridged edge-network, where one or more end hosts receive a multicast service via a common LAN connection to a UDLR Receiver. Multicast forwarding is controlled via a group memberhip protocol (e.g. IGMP [RFC2236]). The UDLR Receiver is connected to the upstream Feed Router via a UDLR tunnel. Scenario C. A bridged-network supporting multicast routers, where one or more multicast routers receive a multicast service provided via a common LAN connection to a UDLR Receiver. Multicast forewarding is controlled by a Layer 3 Multicast Routing Protocol (e.g. PIM-SM [DRAFT-PIM-SM-NEW]). The UDLR Receiver is connected to an upstream router via a UDLR tunnel. Scenario D. A multicast routed-network, where the UDLR Receiver acts as a multicast router. This receives a multicast service provided from the upstream Feed Router. Multicast forewarding is controlled by a Layer 3 Multicast Routing Protocol, (e.g. PIM-SM [DRAFT-PIM-SM- NEW]). Scenario E. An inter-domain multicast network, in which two or more separate multicast domains are connected using the UDLR network. The complexity of this scenario increases with the need to support other protocols (e.g. MBGP, MSDP). A simple network may have only one of these scenarios, but more complex networks may have a combination. 1.1 Characteristics of UDLR networks Authors [Page 3] Internet Draft Experiments with RFC 3077 July 2003 UDLR subnetworks present characteristics which differ significantly from those experienced in the general Internet. These characteristics lead to specific problems and raise specific issues that need to be addressed to deploy an IP multicast service. This section identifies specific characteristics that impact multicast performance resulting from the asymmetry and the types of network over which the UDLR is commonly implemented. These are: 1.1.1 Asymmetric routing paths Unidirectional links give rise to differing forward (feed) and return (tunnel) paths. Multicast routing protocols that use the "reverse shortest path tree" towards the source as a part of their forwarding decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not work correctly over asymmetric routing paths. Solutions include the use of UDLR [RFC 3077] and the use incongruent MBGP routing. 1.1.2 Asymmetric multicast capability Asymmetric multicast capability is not a fundamental feature of UDLR. In some UDLR networks both forward (feed) and return paths may support native IP multicast. In other UDLR networks, a case may arise where the forward link supports native multicast, whereas return link may supports only unicast. UDLR routing allows a non- broadcast/multicast link to be used for the return path by employing a tunnel in the return direction [RFC2784]. 1.1.3 Forward link capacity Since many UDLR networks employ wireless technology for the forward (feed) link (e.g., [EN00]), there may be an appreciable cost for forwarding traffic on the feed link. This leads to a desire to prevent forwarding unnecessary multicast traffic, this implies the need to control which groups are forwarded. However, other factors, (e.g., asymmetric links, and asymmetric loss environment), may suggest a desire to minimise the volume and frequency of control messages in the return direction. 1.1.3 Asymmetric link capacity The capacity of the forward (feed) and return (tunnel) paths may differ significantly (e.g., forward link using DVB-S [EN00], return using a GRE tunnel over a dial-up modem or ISDN interface for the return path). The high normalised bandwidth ratio can lead to a performance bottleneck, in addition the "cost" of setting up and maintaining capacity in the reverse direction may be significantly greater than in the forward direction [DRAFT-PILC-ASYM]. Although a Authors [Page 4] Internet Draft Experiments with RFC 3077 July 2003 class of multicast applications do not require a return path for their transport protocol (e.g. unidirectional transmission of multimedia using RTP [DRAFT-AVT-RTP-NEW]), a path may still be required for other supporting protocols (e.g. DNS, IGMP , Multicast Routing). The cost of establishing and maintaining a return path for these applications may be appreciable, especially considering its minimal use. 1.1.4 Asymmetric loss environment UDLR does not by itself introduce an imbalance in the packet loss rate between the transmit and receive paths, however different link technologies are often used to implement the forward (feed) and return (tunnel) links of UDLR networks. In some important cases this can lead to a significantly higher probability of packet loss in the return direction [DRAFT-PILC-ASYM]. 1.1.5 Flat networks The link technologies that are often used to implement the UDLR feed link may support a multicast/broadcast capability that permits a very large number of directly connected downstream receivers. For example, a single satellite down-link may support 1tens of thousands of UDLR Receivers. The numbers of Receivers connected via the same physical link may be much larger than found in other common LAN technologies, (e.g. Ethernet). Current routing protocols, and some multicast application protocols do not scale to arbitrary large numbers of participants. 1.1.6 Subnetwork round trip delay UDLR does not by itself introduce an appreciable subnetwork round trip delay, however many practical UDLR networks are built using links that may introduce significant path delay (e.g. satellite links). Since the subnetwork round trip delay impacts the performance of the protocols that support the multicast service, the impact of this delay needs to be considered. 2. Description of the Network Architecture 2.1 Topology The UDLR protocol can be used over various types of unidirectional links. Among these links we can list the DVB-S [EN00], DVB-T [], DAB [] links and some cable modems technologies which are unidirectionals. So far, the UDLR protocol has been mainly used in a satellite environment (DVB-S) whose technology seems speader than the Authors [Page 5] Internet Draft Experiments with RFC 3077 July 2003 others. In this document we focus on the use of UDLR in a satellite environment since most experiments have been performed with this technology. A send-only feed is connected to the global Internet with a bidirectional interface (e.g. Ethernet). It is also connected to the unidirectional link with a send-only interface. There is no receive-capable feed in the architecture. A set of receivers is connected to the unidirectional link with a receive-only interface. They all have a bidirectional interface (e.g. Ethernet or ppp) connected to the Internet. The receivers can reach the feed bidirectional interface through the Internet. All the nodes connected to the unidirectional link, i.e. the feed and the receivers, implement UDLR. As a result, every node can send a unicast, a multicast or a broadcast layer-two frame over the unidirectional link. A node can reach any other node as if they were connected to a bidirectional broadcast network. In other words, nodes are connected in a similar way to an Ethernet local area network. Figure 1 depicts this architecture with a single feed and several receivers: Satellite ~~~~ ---- ~~~~ / /-| OO |-/ / ~~~ ---- ~~~ _/ \ \ _/ \ \ _/ \ \ Unidirectional _/ \ \ Link _/ \ \ _/ \ \ / \ \ | | | -------- -------- -------- ---------- | Feed | |Recv 1| |Recv 2|---|subnet A| -------- -------- -------- ---------- | | | | | | | | ---------------------------------------------------- | Internet | ---------------------------------------------------- Figure 1: Typical UDLR topology Authors [Page 6] Internet Draft Experiments with RFC 3077 July 2003 Recv 1 is host, e.g., the end-user work station integrating a satellite reception card. The host may have an ISDN or RTC connection for a terrestrial Internet provided by a local ISP. Recv 2 is a routeur connected to a local area network (Subnet A). Other routeurs may be connected to the subnet and exchange routing informations with Recv 2. Recv 2 may have an ISDN or RTC connection for a terrestrial Internet provided by a local ISP. The examples of terrestrial connecvities for a host or a router are non-exhaustives, they may also use other technologies such as Ethernet or GSM, etc. The UDLR protocol supports the case where several feeds are connected to a satellite. This case is not described in the document because not as many experiments as with a single feed, have been performed. 2.2 Multicast Forwarding over UDLR A UDLR Feed Router connected to an upstream multicast router MAY choose to forward all received IP multicast packets on all forward feeds, or MAY alternatively use a group management or routing protocol to determine the set of multicast groups that must be forwarded for each forward feed. MUST forward all IPv4 packets with an address 224.0.0.0/24 [RFC 1122]. It MAY also forward all other packets with other multicast addresses (224.0.0.0/4) [RFC 3171], but SHOULD use group membership information to avoid forwarding packets belonging to groups for which there are no downstream members connected via UDLR receiver(s) (see section 4.2). In some cases, this forwarding will be controlled using MAC address filters. Since a number of IPv4 multicast addresses are often mapped to a common MAC address, address overlap may occur (e.g. [RFC1122]). In this cases a Feed Router may determine the set of IP multicast addresses in use, and hence the corresponding set of MAC address and then choose to forward all IP groups that map to this set of MAC addresses. This is normal IP multicast routing behaviour. The rules for forwarding those multicast packets received by the Feed Router differ when the packets are received via the feed tunnel end- point [RFC3077]. In this case, the Feed Router MUST forward all multicast packets to the interfaces associated with: (i) the list of send-only feed tunnel end-points (ii) the forward feeds (iii) the upper layer protocols of a multicast enabled Feed Authors [Page 7] Internet Draft Experiments with RFC 3077 July 2003 Router (i.e., for possible forwarding to upstream multicast router(s)). In cases (ii) and (iii) the multicast forwarding does not include the normal Reverse Path Forwarding (RPF) check, the normal processing of the Time To Live (TTL) field, or the normal processing of administratively scoped multicast addresses. In addition, a UDLR Receiver MUST must perform normal multicast forwarding of IP multicast packets received on the forward feed interface, but MUST NOT forward any packets that were originated by the same Receiver (i.e., were previously sent via the return direction tunnel). This later requirement is equivalent to an RPF check. Multicast packets received by the node on other (i.e., non- feed) interfaces MUST be forwarded to the Feed Router using the return tunnel interface. 3.0 Layer 2 Protocols 3.1 Hardware Address Resolution A hardware address resolution can be used over UDLR to allow a node, e.g. a feed or a receiver, to discover the MAC address of another node. Regardless of whether the link is unidirectional or bidirectional, if a nodes sends a packet over a non-point-to-point type network, it requires the data link address of the destination. ARP [RFC826] is used on Ethernet networks for this purpose. This mechanism usually requires that the underlying transmission media is bidirectional in order for a node to obtain the data link address of a destination. The node sends an ARP REQUEST over the link and waits for an ARP RESPONSE from the destination that contains its data link address. Upon reception of the ARP response, the node can then send traffic to the destination. Note that an ARP REQUEST is broadcast-type frames, all nodes connected to the link receive it and process it. An ARP RESPONSE is a unicast-type frame, only the receiver whose hardware address is identical the MAC destination address of the frame processes it. 3.1.1 Hardware Address Resolution protocol over UDLR In a satellite environment, receivers connected to a DVB-S link use reception cards which have their own unique hardware address. This hardware address is 6-bytes long, like an Ethernet address. It may be then sensible to use a mechanism similar to [RFC826] for a feed to Authors [Page 8] Internet Draft Experiments with RFC 3077 July 2003 discover the hardware address of a receiver. Thanks to the UDLR protocol which emulates a bidirectional connectivity over the satellite link. It allows a receiver to send back to the feed layer two packets such as ARP responses. Note that, for other satellite data link formats different from DVB- S, receivers still have a unique hardware address and a similar address resolution protocol based on exchanging REQUEST and RESPONSE messages may be used. In a topology where we have a feed and a number of receivers connected to the satellite link, there are 3 typical hardware address resolution scenarios: i) Scenario 1: A feed needs a receiver's hardware address. This usually occures when a feeds has to send a unicast IPv4 packet to a receiver whose MAC address is unknown. The feed sends an ARP REQUEST over the satellite link whose payload contains the IP address of the receiver. All the receivers listen to the ARP REQUEST. The receiver which recognizes its IP address in the payload sends an ARP RESPONSE back to the MAC address of the feed. Note, the ARP REPONSE reaches the feed through the UDLR GRE tunnel. Upon reception of the ARP RESPONSE, the feed obtains the receiver MAC address from the payload and can send IPv4 packets to it. ii) Scenario 2: A receiver needs the feed's hardware address. This usually occures when a receiver has to send a unicast IPv4 packet to the feed whose MAC address is unknown. The data link layer of the receiver creates a ARP REQUEST which is sent through the UDLR GRE tunnel. The ARP REQUEST payload contains the IP address of the feed. Upon reception of the ARP REQUEST, the feed which recognizes its IP address in the payload sends over the satellite link an ARP RESPONSE to the MAC address of the receiver. Upon reception of the ARP RESPONSE, the receiver obtains the feed MAC address from the payload and can send IPv4 packets to it. iii) Scenario 3: A receiver needs a receiver's hardware address. This usually occures when a receiver has to send a unicast IPv4 packet to another receiver whose MAC address is unknown. The receiver sends an ARP REQUEST, which contains the IP address Authors [Page 9] Internet Draft Experiments with RFC 3077 July 2003 of a receiver, through the UDLR GRE tunnel. Upon reception of the frame, the feed forwards it over the satellite as it is a broadcast-type frame (see [RFC3077] for details). All the receivers listen to the ARP REQUEST. Only the receiver which recognizes its IP address in the payload sends back an ARP RESPONSE to the requesting receiver. The ARP RESPONSE is sent through the UDLR GRE tunnel to the feed. Upon reception of the frame, the feeds figures out that the destination MAC address is a receiver's one and then forwards it over the satellite link (see [RFC3077] for details). The requesting receiver receives the ARP RESPONSE, obtains the desired MAC address and can send IPv4 packets to it. These 3 scenarios allow any node connected to the satellite link to obtain the MAC address of any other node. 3.1.2 Issues using a hardware resolution protocol over UDLR The scenarios described in Section 3.1.1 raise a number of issues when using a hardware resolution protocol over UDLR in a satellite environment. 3.1.2.1 Long round trip delays Regarding to scenarios 1 and 2, it requires over 250 milliseconds for a node, a feed or a receiver, to obtain the MAC a destination of a destination. 250 milliseconds is the fix and uncompressable satellite link propagation delay. It should also be added to it the propagation delay on the terrestrial link from the receiver to the feed. This delay may vary from a few milliseconds up to a couple of hundred milliseconds depending on the receiver's connectivity. E.g., a slow GSM connectivity has a significative impact on the overal round trip time whereas a fast T1 access has very little impact. Because of long round trip delays, reactive address resolution methods may not work well in some cases. For example, a feed may have to forward UDP unicast packets at high data rates to a receiver whose hardware address is unknown. The stream of packets is passed to the link-layer driver of the feed send-only interface. When the first packet arrives, the link-layer realizes it does not have the corresponding hardware address of the next hop, and sends an ARP request. While the link-layer is waiting for the response (at least 250 milliseconds), IP packets are buffered by the feed. If it runs out of space before the ARP response arrives, IP packets will be dropped. However, for TCP traffic, this should not happen since the first TCP packet sent to a receiver whose MAC address is unknown, is generally a TCP SYN indicating the start of a new session. This Authors [Page 10] Internet Draft Experiments with RFC 3077 July 2003 packet is not followed by a stream of packet until the receiver replies to it. Therefor not many packets are buffered or lost for the session. Note that subsequent IP packets sent to the same receiver hop are not buffered anymore as long as the ARP entry is valid. Regarding to scenario 3, the round trip delay between two receivers is twice the round trip delay of scenarios 1 and 2. Both, the ARP REQUEST and ARP RESPONSE are sent over the terrestrial network through UDLR GRE tunnel and over the satellite link. An IP packet delivered to the data link whose next hop MAC address is unknown, must be buffered at least 500 milliseconds before being sent. In order, to make a reactive harware address resolution protocol more efficient in scenario 3, i.e. to reduce the round trip delay, it might be sensible to configure an ARP server at the feed. The feed would learn MAC addresse from ARP RESPONSES it receives from receivers and would publish them as soon as a receiver requests one of them. This mechanism would reduce the round trip down to 250 milliseconds, the feed would answer to an ARP REQUEST instead of a receive reducing the latency. 3.1.2.2 Large number of receivers Due to the large number of receivers which may be connected to the satellite link, it is necessary to be able to allocate a sufficient number of ARP entries in a ARP table. A feed may need to send unicast packets to thousand of different receivers. For each of the receivers, a correspondance between a MAC address and the IP address of a receiver must be maintained. Furthermore, when the size of the ARP table is significant, the search for a MAC address corresponding to the next hop IP address must be performed rapidely in order to prevent IP packets from being buffered too long. It is also common to associate an expiration date to an ARP entry in order not to keep an entry for ever. After being deleted, an ARP entry associated to a receiver is renewed when an IP packet is sent again to this receiver. The main reasons for aging entries are: - Automatic discovery of a receiver new MAC address. One may replace the reception card of a receiver for maintainance puposes. The IP address of the receiver does not change but its MAC address does. When deleting the ARP entry of this receiver, a new IP packet destined to it triggers the request of its new MAC address. - ARP table size adjustable. Receivers may not be constantly connected to the satellite link. During idle periods, it is then Authors [Page 11] Internet Draft Experiments with RFC 3077 July 2003 not necessary to keep an ARP entry for these receivers. The size of the ARP table can then be adjusted to the number of active receivers. 3.2 PPPoE 3.2.1 Introduction The use of PPPoE with UDLR enables to offer a real satellite local loop. It represents a good alternative for non covered by ADSL areas. As PPPoE is a level 2 (OSI model) protocol, it matches well with the LLTM mechanisms of the UDLR that make all the equipments directly linked in Ethernet to the UDLR client and server see each other on the same logical LAN (Local Area Network). The only needed routing is the one between the UDLR client and the UDLR server for establishing the GRE tunnel. 3.2.2 Architecture Unidirectional Link -------------<----------- | | | | | | | | | | \|/ . . /|\ | | --------- --------- -------- Ethernet | PPPoE/| IP Networks | LLTM | PPPoE | BAS | -------| LLTM |-------->------|Server |---------| | | Router| | | | | | --------- --------- -------- | ____ | |--|PC| | | ---- -------- | ____ LAN | ISP | |--|PC| -------- | ---- Figure 1 : Connectivity to a BAS via UDLR/PPPoE In the Figure 1, the connections with arrow are unidirectionnal, others are bidirectionnal. 3.2.2.1 Specificities Authors [Page 12] Internet Draft Experiments with RFC 3077 July 2003 The specificities of this architecture are : - the use of a UDLR client (implementing the RFC 3077) on a satellite terminal. - the use of a UDLR server (implementing the RFC 3077) on a DVB (Digital Video Broadcasting) Gateway acting as an Ethernet Bridge (so you need a routeur co-located with the DVB gateway) - a connection to a BAS (Broadband Access Server). The BAS is directly connected to the DVB gateway in Ethernet. The BAS manages the PPPoE connection. The PPPoE can end into the BAS (open model) or continue and end into the RADIUS server of an ISP (Internet Service Provider) (closed model). The PPPoE authentication is done where the PPPoE tunnel ends (PPPoE server). - the use of a PPPoE client; there are two possible scenarii : > the PPPoE client is implemented on the satellite terminal that acts as a routeur for the PCs in LAN behind. The PPPoE session is initiated between the satellite terminal and the BAS or the Radius server. > the PPPoE client is implemented on the PC, the satellite terminal is now acting as an Ethernet Bridge : each client is using its own PPPoE connection. All the PPPoE tunnels are encapsulated in the same GRE tunnel. 3.2.2.2 Description of a connection Here are the different steps of a connection to Internet : - a user on a PC is trying to connect to a distant server of the Internet - the satellite terminal detects IP traffic - after an authentication on the satellite platform, a GRE tunnel is initiated between the DVB interface of the satellite terminal and the DVB gateway. Now a LAN has been emulated and all the Ethernet frames coming from the satellite terminal can be directed to the gateway DVB and therefore to the BAS. - after an authentication on the BAS (or the Radius server of an ISP), a PPPoE tunnel is initiated between the satellite terminal or the PC and the BAS (the specificities of a PPPoE connection is described in the RFC 2516). - the BAS redirect the PPP connection to the right ISP through a L2TP tunnel. 3.2.3 Advantages The bidirectionnal connectivity through PPPoE offers the following advantages : - a complete layer 2 (OSI model) satellite connectivity is offered with a total transparency at an IP level between the terminal satellite (UDLR client) and the IP network. Authors [Page 13] Internet Draft Experiments with RFC 3077 July 2003 - UDLR supports natively the PPPoE so no hardware development is needed. The PPPoE client has to be integrated in the satellite terminal or in the PC. - PPPoE enables an interconnection with a Broadband Access Server and besides the use of its functionalities (such as traffic shaping). - A satellite access based on UDLR/PPPoE can be complementary with the ADSL network : > same performances as the ADSL network > reduction of the access costs due to the equipments' convergence point in the return channel and a unique management system for both satellite and terrestrial access (accounting, billing, etc.) - a multi-ISP configuration for the Internet access. - a difference can be made between the IAP (Internet Access Provider) and the ISP 3.2.4 Limitations It is important to notice that PPPoE supports only PPP connection for unicast flows. The multicast is provided directly by the IAP at the DVB gateway level or coming from the Mbone through the BAS without using PPPoE. 3.2.5 Security issues The security issues are the same as the UDLR ones. So you need a first authentication for the establishment of the GRE tunnel. Afterwards, you need a second authentication of the client done by the BAS or the Radius server of the ISP. This authentication is done within the PPPoE mechanism (PAP or CHAP). It's also possible to use cryptography¿with the IPSec protocol (e.g. RFC 3457) 4.0 Layer 3 Protocols 4.1 Dynamic Host Configuration Protocol The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network, and a mechanism for automatic temporary allocation of network addresses. 4.1.1 DHCP Overview DHCP is based on Bootstrap Protocol (BOOTP). It consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host (default gateway, DNS server) and a mechanism for allocation of network addresses to hosts. DHCP Authors [Page 14] Internet Draft Experiments with RFC 3077 July 2003 [RFC 2131] defines a set of transactions between a DHCP server and a DHCP client to afford/request a valid network address, configuration parameters or both. These transactions are constructed by DHCP messages defined in RFC2131 (DHCPDISCOVER, DHCPREQUEST, DHCPOFFER) that could include DHCP options defined in RFC2132. DHCP runs over UDP. It uses port 67 on server's side, and port 68 on client's side. A DHCP client is not supposed to know the DHCP server's IP address initially. When a host needs to acquire an IP address and eventually configuration parameters, it broadcasts a DHCPDISCOVER message on its physical subnet. Relay agents (if running on connected routers) may pass the message on to DHCP servers not on the same physical subnet. One or more DHCP server may respond to the client by proposing a network address in a DHCPOFFER message. Server may probe the offered address with an ICMP Echo Request. The client may receive one or more offers. It broadcasts anyway a DHCPREQUEST message that contains a server identifier option, and eventually other options, to notice all DHCP servers of its selection. The selected server sends a DHCPACK message to confirm allocation. The client may probe a last time the allocated address (e.g. ARP request). This is a typical example of a successful DHCP transaction. There are other DHCP transactions, messages and options. Please refer to [RFC2131] for a complete description of DHCP protocol, and to [RFC2132] for a complete description of DHCP options. 4.1.2 DHCP over UDLR LLTM mechanism makes nodes connected to the UDL see themselves on the same logical Local Area Network. Encapsulating layer-two frames allow them to be sent in unicast and broadcast through Internet and UDL. Thanks to this feature, DHCP can run on networks using UDLR architecture, i.e. satellite networks. DHCP may be a solution to IP addressing scalability and increasing number of nodes on such networks. e.g. A node can be assigned a temporary network address from a pool of public addresses . DHCP provides also a means of requesting and getting local configuration parameters for clients from their ISP. 4.1.2.1 Configuration and tuning guidelines Before sending a DHCP request, a client node needs Layer-two Authors [Page 15] Internet Draft Experiments with RFC 3077 July 2003 connectivity to one DHCP server at least. Actually, a common use of DHCP consists of making a DHCP client send DHCPDISCOVER message at boot. While using DHCP over UDLR, DHCP client messages should be sent only after establishing the GRE tunnel. Therefore, use of DHCP should be taken into account while dimensioning the DTCP HELLO message periodicity. Lease duration and address pools' width, configured on DHCP server side, depend on the number of nodes to serve and the nature of offered services. Lease duration should not be too short to avoid an increasing DHCP traffic and the risk of inability of renewing leases. And should not be too long to avoid misusing addresses and increasing the blocking probability. A DHCP server can reassign addresses allocated before. It may check an address before reallocation by an ICMP echo request; and the client may do the same, after receiving an address, by an ARP request. Such messages should be allowed to avoid address conflicts. A DHCP server can be located on a receiver or a feed. For security and delay considerations, implementing DHCP server on feed's side reduces transaction duration to a half, and prevents from allocating a lease by an unauthorised DHCP server. Client sends DHCPRELEASE message to notice the server that client has relinquished the lease. Some implementations of DHCP client keep configuration information even after sending a DHCPRELEASE message. This may lead to an address conflict and reduces the available address pool. DHCP servers and clients should take into account network transit delay while assigning timers: DHCP messages retransmission timeout, maximum delay that a DHCP server waits before deciding that the absence of an ICMP echo response means that the relevant address is free. The global delay of a successful DHCP transaction is composed of: 1) One or two RTTs (Round Trip Time) for DHCP transaction. I.e. requesting and acquiring a lease is done by exchanging four messages, renewing a lease is done by exchanging two messages. 2) More than one RTT, which is the time needed to check the availability of a network address. E.g. ICMP echo. 3) Time needed to read/write configuration and database files on both server and client sides. Authors [Page 16] Internet Draft Experiments with RFC 3077 July 2003 DHCP clients may also retransmit DHCP messages if they do not receive a response. Some client implementations timeout DHCPDISCOVER message (for example) on an Ethernet delay basis. And a DHCP server may respond to DHCPDISCOVER retransmission before that checking lease availability (by an ICMP echo request) timeout expires, resulting on an eventual address conflict. 4.1.2.2 Security issues DHCP works over UDP/IP stack. These protocols are not inherently secure. And UDLR technology is widely used over links that may be easily accessed. Some DHCP messages (e.g. DHCPDISCOVER) are layer-two broadcasted on the UDL, a malicious DHCP server may allocate network addresses or false configuration information. An unauthorised host may capture information sent to a DHCP client; Configuration information can be then set manually. Link layer or IP security mechanisms are of great interest. Authorising DHCP server to serve unknown clients should be done with special attention. DHCP permits authentication on a hardware address basis through DHCP header and options, on the other hand LLTM mechanism encapsulates layer-two frames. Authentication is another important security feature. DHCP transactions should be allowed after client authentication. 4.2 Issues using IGMP over UDLR The Internet Group Management Protocol (IGMP) [RFC1112, RFC2236, RFC- IGMPv3] is used in multicast edge networks (i.e., an Ethernet LAN or the UDLR Scenarios A and B). Forwarded between multicast routers is controlled by a different protocol (see section 5). The first version of IGMP, IGMPv1 [RFC1112] is little used. At the time of writing, most current end hosts use IGMPv2 [RFC2236]. IGMPv3 is increasingly being deployed [RFC-IGMPv3]. A MIB has also been defined [RFC2933]. IGMP messages are sent with an IPv4 Time To Live (TTL) of 1, indicating these are link local. On a UDLR return link, these messages are sent using the return link tunnel, and retransmitted over the feed (see 1.1.1). 4.2.1 Basic IGMP Operation IGMP Membership Reports are sent by end hosts to communicate their desire to receive specific IP multicast groups. Multicast routers in the same subnetwork use IGMP Membership Reports to help determine whether IP multicast packets should be forwarded to the subnetwork. Multicast routers may already be forwarding this group, if not they Authors [Page 17] Internet Draft Experiments with RFC 3077 July 2003 start to forward IP multicast packets for the reported group after the subnetwork RTT plus any additional delay required for the Feed Router to join the requested multicast flow. To validate the set of currently active groups, one multicast router per subnetwork (the Querier) periodically sends a multicast packet containing an IGMP Group Membership Query to all end hosts (i.e., using the IPv4 address 224.0.0.1). The Query Interval must be greater than the sum of the Max Response Time and the Subnetwork Round Trip Time, and is typically much larger. The Query message is received by all systems in the subnetwork that have multicast enabled. This mechanism also acts as an opportunity for end hosts to resend a Membership Report which was not received by the UDLR Feed Router. Each end host sets a random timer for each group it wishes to receive. When the timer expires, it responds with one IGMP Group Membership Report for each group which it wishes to receive. IGMP includes a technique to reduce the number of Reports received by the querier. This suppression mechanism relies upon visibility of the responses sent by all members of the multicast group (i.e., the UDLR Feed Router must re-send received Membership Reports on the all feeds). If the other group members do not receive copies of the Membership Reports, they will each send one Membership Report per query, Groups which contain many members therefore generate a large volume of return traffic. Even when suppression is used, a large subnetwork RTT, may lead to many receivers sending IGMP Membership Reports for the same group(s) within the Max Response Time [RFC2236]. If it is known that there may be many group members, one mitigation is to increase the Max Response Time. which allows suppression to occur after one Subnetwork RTT. A Querier that identifies a previously forwarded group that currently has no group members will send several (Robustness Variable) Queries each separated by the Query Interval. The Query Interval must be greater than the sum of the Max Response Time and the Subnetwork Round Trip Time. If no Membership Reports are received for a specific group (i.e., after a total period called the Group Membership Interval) the multicast routers stop forwarding multicast packets with this group address. Decreasing the Robustness Variable and/or the Query Interval reduces the time to detect the last memebr leaving a group(s). This can reduce the volume of unnecessary multicast traffic sent over a UDLR feed link. Reducing the Robustness Variable also reduces tolerance to loss of Membership Reports sent over the return link (see 1.1.4). The number of Membership Reports is an issue for flat networks (see Authors [Page 18] Internet Draft Experiments with RFC 3077 July 2003 1.1.5), particularly if they also exhibit a larger subnetwork RTT (see 1.1.6). The number sent for each group is a function of the number of systems that wish to receive the group, the Subnetwork RTT, and the Max Response Time. Suppression requires the multicast packets containing multicast Membership Reports received from UDLR Receivers to be forwarded by the UDLR Feed Router. A large Max Response Time, can reduce the number of redundant Membership Reports, reducing return link traffic, but it also has the drawback of increasing the leave latency. This may, in turn, increase the volume of traffic unnecessarily forwarded on the forward link when there are no remaining group members. This is an issue for UDLR networks with limited forward link capacity (see 1.1.3). 4.2.2 IGMPv2 Leave Processing In IGMPv1, it may take a considerable time for a multicast router to discover there are no remaining end hosts interested in a group that it is already forwarding. A refinement in IGMPv2 [RFC2236] allows end hosts to send a Leave message explicitly indicating the group address which the end host wishes to leave. This message is sent to an IPv4 address of 224.0.0.2. In some, but not all implementations, end hosts will suppress sending an IGMP Leave message when they believe there are other remaining group members. Reception of an IGMP Leave message is not sufficient for a forwarding multicast router to determine that there are no longer any end hosts interested in a group. The Querier therefore responds by sending a Group-Specific Query to request responses from other end hosts interested in the group. If no Membership Report is received, the Query is repeated each Last Member Query Interval up to Last Member Query Count times, after which it will conclude there are no remaining group members. This allows multicast routers to more quickly stop transmission of multicast packets to groups for which there are no longer any active receivers. The value for Last Member Query Interval may be tuned, but MUST be greater than the Subnetwork RTT. The time taken to terminate an IP multicast flow is therefore the sum of the subnetwork RTT and the delay introduced by the IGMP Querier. 4.2.3 IGMPv3 Operation IGMPv3, allows an end host to report an interest in receiving not only a specific group address, but also from a specific set of IP source addresses (or all except a specific set of IP source addresses). This allows finer control over the multicast packets forwarded to the subnetwork. This may conserve link capacity, especially when a system switches from receiving one multicast group Authors [Page 19] Internet Draft Experiments with RFC 3077 July 2003 to another. End hosts that receive an IGMPv3 Query start a random timer. The maximum value is specified as a parameter in the Query, allowing an appropriate scaling factor to be selected based on the anticipated size of the group and the Subnetwork RTT. IGMPv3 Membership Reports are sent to a specific multicast address (i.e. the IPv4 address 224.0.0.22). A potential modification to UDLR would allow this group to be filtered by the Feed Router. One significant change in IGMPv3, is that end hosts MUST send Membership Reports following a Query to indicate the groups they wish to receive (i.e., there is no suppression), although a single message may report several groups. This may increase the number of IGMP messages sent over a subnetwork. This can consume both feed and tunnel capacity (see 1.1.3, 1.1.4). To mitigate this in flat networks (see 1.1.5) or networks with a large subnetwork RTT (see 1.1.6), IGMPv3 therefore also allows the use of much larger response times. An advantage of IGMPv3 is that it allows routers (and connected LAN switches) to provide explicit tracking of which end hosts request each group. Explicit tracking allows routers to discover immediately when the last group member leaves, and suspend forwarding of the group within a Subnetwork RTT. 4.2.4 Forwarding Groups at the Receiver based on IGMP Note that in IGMPv1 and IGMPv2, Leave and Membership Report messages are sent to the same group destination address as the group it is notifying. A bridged (Scenario B) solution requires these messages to be parsed at the UDLR receiver in order to establish an appropriate filter set to forward multicast packets to the attached end hosts. One scheme is called Snooping [DRAFT-MAGMA-SNOOP]. Separating these Membership Reports from multicast traffic can be processor intensive and may impact performance, many Ethernet LAN switches employ ASICS to optimise this processing. 4.3 IGMP-Proxy The IGMP Querier function is normally implemented in a multicast Router, and the IGMP client in a multicast end host. It is also possible to implement the IGMP protocol within UDLR Receiver, this is called an IGMP membership Proxy [DRAFT-MAGMA-PROXY, DRAFT-MAGMA- SNOOPING]. Consider Scenario B. An IGMP membership proxy at the UDLR Receiver behaves as if it were an end host (i.e., sends IGMP Membership Authors [Page 20] Internet Draft Experiments with RFC 3077 July 2003 Reports for groups it wishes to receive) in response to IGMP Queries received over the UDLR forward feed. The receiver also executes an IGMP Querier for the attached LAN and therefore sends IGMP Queries. The Membership Reports received by the Receiver allow it to collect group membership information, which can be directly used to control forwarding of multicast packets received over the UDLR feed. An IGMP Proxy may use different group membership protocols on the UDLR and LAN networks. This could be a mixture of IGMPv2 and IGMPv3, or could possibly be a modified protocol on the UDLR network. An IGMP Proxy may also implement Proxy Reporting [DRAFT-MAGMA- SNOOPING; DRAFT-MAGMA-PROXY], where the proxy only reports which sources and groups need to be forwarded. This can significantly reduce the number / frequnecy of Reports. A UDLR Receiver employing an IGMP Proxy can separate the distribution of group membership information into the UDLR subnetwork and any attached networks connected via a UDLR client. This allows the protocol parameters used within the UDLR network to be tuned. 4.4 Dense Mode Multicast Routing 4.4.1 DVMRP 4.4.2 Dense Mode PIM (PIM-DM) 4.5 Sparse Mode Multicast Routing 4.5.1 Sparse Mode PIM (PIM-SM) The issues of PIM-SM operation on unidirectional links are: 1. Reverse Path Forwarding 2. Rendezvous Point selection 3. Designated Router selection This section describes these issues in details. In this section, all nodes are assumed to be PIM-SM routers (Scenario D) and the UDL runs PIM-SM as the only multicast routing protocol. Reverse Path Forwarding In the case of Receive networks do not use the Feed Router to forward unicast traffic to multicast sources and the Rendezvous Point, the receivers do not send PIM-SM Join/Prune messages to the Feed Router. As the result, multicast traffic does not flow on the unidirectional Authors [Page 21] Internet Draft Experiments with RFC 3077 July 2003 link. This is the PIM-SM reverse path problem on unidirectional links. There are two solutions, at least, for this problem: 1. Configure UDLR Receive networks to route unicast traffics to all possible multicast sources and Rendezvous Points via the Feed router. 2. Prevent PIM-SM routers in UDLR receive networks from switching to the shortest-path tree of multicast sources located outside the receive network. In this scheme, the UDL receive networks only need to route unicast traffic to all possible Rendezvous Points via the Feed Router. If the possible multicast sources includes all hosts in the Feed network, then the first option is to route traffic to the Feed network via the Feed Router. The second option simplifies the routing requirement from routing to all hosts in the Feed network to routing to the possible Rendezvous Points. The second option, however, doesn't work on SSM destination addresses. [DRAFT-PIM-SM-NEW] specifies some rules concerning the SSM destination addresses overriding the normal PIM-SM behavior. This document states that a router MUST NOT send a (*,G) Join/Prune message for any reason, thus PIM-SM never uses the rendezvous-point tree for traffic to SSM destination addreses. Rendezvous Point selection The Feed network can advertise routes to the possible Rendezvous Points using unicast routing protocols natively such that the UDLR receive networks route to them via the Feed Router. This scheme causes UDLR receive networks to route all networks between the Feed Router to the possible Rendezvous Points via the Feed Router. To minimize the number of networks routed via the Feed Router, the possible RPs should be as close as possible to the Feed Router. This number reaches the minimum if the Feed Router's unidirectional link interface address is the only possible Rendezvous Point. In the case where no unicast routing protocol is running on the uni- directional link and unicast routing advertisements are limited only within each Feed network and Receive network, the UDLR receive networks may use static routes. Static routes to the possible RPs via the Feed router are set on the UDL receivers and they are injected to the receive network's unicast routing protocol. Designated Router selection Authors [Page 22] Internet Draft Experiments with RFC 3077 July 2003 A PIM-SM router performs Designated Router election on each interface. A DR has the task to send PIM-SM Register packets and to send Join/Prune messages toward the RP or the multicast source. The DR election is important for unidirectional links if multicast sources exist. If a multicast source exists on a unidirectional link, the Feed Router should be elected as the DR for the unidirectional link to avoid the overhead due to the LLTM mechanism. In the Scenario D, DR election result is not important as all UDL nodes are multicast routers. A PIM-SM router sends Hello messages periodically every Hello_Period to each active inteface. In addition, a PIM-SM router also sends a Hello message when Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor. a PIM-SM router will remove a neighbor if it does not receive any neighbor's Hello message in the HoldTime advertised by the neighbor. The number of neighbors is an issue for flat networks (see 1.1.5). The bandwidth consumption Periodic Hello messages can be reduced by a large Hello_Period. A large HoldTime can reduce the probability of removing a PIM-SM neighbor due to Hello message packet loss, thus reducing the probability of a Hello message storm. However, the probability of a router reboot on flat networks having many nodes may be high, thus the probability of a Hello message storm due to receiving a Hello message with a new GenID from a newly rebooted neighbor. Join/Prune messages are sent periodically toward the multicast source or the RP. An overriding Join is also sent by a router having a multi- cast state if it receives a Prune of that multicast state sent by a neighbor to the upstream router. If a PIM-SM router receives a Join with the same state, it can suppress sending a Join message of the same state. Join message suppression can reduce the bandwidth consumption of a shared link. For flat networks with many nodes or large round trip delay, a large Override interval will help. The large Override interval value causes a large Prune Pending Timer, thus multicast traffic will flow for a longer time on the unidirectional link even though there is no more downstream routers. 4.5.2 PIM-SM RPs and MSDP In the Scenario E, each Receive network has its own RP and MSDP is used to connect each RP. Each Receive network's RP MSDP peers with the RP of the Feed network. Authors [Page 23] Internet Draft Experiments with RFC 3077 July 2003 In the case of multicast routing using PIM-SM and MSDP, flowing multicast traffic from a source S in the Feed network to multicast listeners in Receive networks via a UDLR requires that: 1. Join(S,G) message from Receive networks to the Feed network flows via the UDLR. 2. The MSDP peer in the Feed network is the RPF peer of the MSDP peer in the Receive networks toward the originating RP of S. These requirements suggest that a separate MRIB is needed to flow the traffic via the UDLR and the MRIB has to create the RPF route to S and its originating RP via the UDLR. [DRAFT-MSDP-DEPLOY] discusses several scenarios to deploy MSDP and PIM-SM. The best current practice for inter-domain multicast is to use MBGP along with PIM-SM and MSDP. In the UDLR case, A Receive network MBP peers with the Feed network for the multicast address family only. This practice creates a different multicast topology to the unicast topology. If PIM-SM and MBGP are the only multicast routing protocols, the non- MBGP speaker routers in Receive networks do not have a separate MRIB. These routers perform RPF checks solely based on their unicast routing table; therefore they do not send Join(S,G) messages toward the Feed router. These routers should be set to not join the SPT. The RP in Receive networks should be the Receive routers unless all rou- ters from the Receive routers to the RP learn the multicast topology from MBGP. If this is not the case, the MSDP peer in the Feed network passes the peer-RPF check at the MSDP peer in the Receive networks, but when the MSDP peer in the Receive networks send Join(S,G), the Join(S,G) path fol- lows the unicast routing table. Based on these facts, Receive networks should be configured as follows: 1. PIM-SM routers should not join the SPT. 2. RP, which is also the MSDP peer, should be the Receive router. 3. Receive routers should MBGP peer with the Feed router for the multi- cast address family. The configuration no. 1 basically also states that Receive networks can only be stub PIM-SM domain, because if they MBGP peer and MSDP peer with a downstream PIM-SM domain, the Receive networks have to create MRIBs on all routers along the intended Join(S,G) path from the RP of their down- stream domain to the Receive routers. 4.6 NAT environment Network Address Translation (NAT) technology is getting popular in the Internet these days. Normally NAT box translate private IP address to global IP address on regular TCP protocols and some of UDP Authors [Page 24] Internet Draft Experiments with RFC 3077 July 2003 services. UDLR defined by RFC3077 employs GRE encapsulation technique to communicate receivers and a feed. But RFC3077 does not consider to exist NAT box between the GRE tunnel between a receiver and a feed. By this nature RFC3077 does not support NAT environment. It may work with some NAT box but it depends on the implementation of NAT function. 5. Security Considerations The recommendations contained in this document do not impact the integrity of IP multicast transport protocols, or applications using IP multicast transport protocols. There are known Denial of Service (DoS) attacks that can be staged UDLR operation. UDLR employs GRE tunnel mechanism to carry a packet from a receiver to a feed. If the intruder send a faked packet to the tunnel end point at feed, it will be a cause of the link down of the UDL. Intruders also can send flooding packet to the UDL receivers via UDL. It will be a cause of UDL flood. Third case of the intrusion is related to ARP mechanism. If the operator employs ARP mechanism to resolve MAC address to IP address, these negotiation should be authenticated and protected from faked ARP packet. Faked ARP packet may be a cause of ARP table overflow on feed or other routers. To avoid these attack, it is recommended to protect tunnel end point at feed by packet filtering, hide tunnel interface IP address from unknown users, etc.. And it is also recommended that a packet sent to the UDL should be encrypted using any kind of encryption mechanism. UDL has a nature of broadcast link. That means packets on the UDL may be received by unexpected nodes. 6. Conclusions 7. Acknowledgements 8. References 8.1 Normative References [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982 [RFC1112] Deering, S.E., "Host extensions for IP multicasting", RFC1112, 1989, (STD0003). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors [Page 25] Internet Draft Experiments with RFC 3077 July 2003 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 1997 [RFC2132] S. Alexander,R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, 1997 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", 1997, RFC 2236, (Proposed Std). [RFC2516] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)",RFC 2516, February 1999 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P., "Generic Routing Encapsulation (GRE)", RFC2784, (Proposed Std). [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional Links', RFC 3077, March 2001 [RFC-IGMPv3] "Internet Group Management Protocol, Version 3", (Author's note, with IESG - this reference needs to be solved when issued as an RFC). 8.2 Informative References [DRAFT-AVT-RTP-NEW] Schulzrinne/Casner/Frederick/Jacobson, "RTP: A Transport Protocol for Real-Time Applications, , Work in Progress. [DRAFT-MSDP-SPEC] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol (MSDP)", , Work in Progress. [DRAFT-MSDP-DEPLOY M. McBride, "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", draft-ietf-mboned-msdp- deploy-02.txt, Work in Progress. [DRAFT-MAGMA-SNOOP] M. Christensen, F. Solensky "IGMP and MLD snooping switches", , Work in Progress. [DRAFT-MAGMA-PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP Proxying)", , (Author's note: not in ID archive), Work in Progress. Authors [Page 26] Internet Draft Experiments with RFC 3077 July 2003 [DRAFT-PILC-ASYM] Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst, M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", , Work in Progress. [DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", , Work in Progress. [EN00] "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", Draft European Standard (Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1 [RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", 1996, (Proposed Std). [RFC2933] K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group Management Protocol MIB", RFC2933, 2000, (Proposed Std). [RFC2402] Kent, S., Atkinson., R., "IP Authentication Header", RFC2402, 1998, (Proposed Std). [RFC2406] Kent, S., Atkinson., R., "IP Encapsulating Security Payload (ESP)", RFC 2406, 1998, (Proposed Std). [RFC3171] Albanna, Z., K. Almeroth, D. Meyer, M. Schipper. "IANA Guidelines for IPv4 Multicast Address Assignments", 2001, ( BCP0051) [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", RFC3228, 2002, (BCP0057). 9. Authors' Addresses In alphabetic order: Gilles Chanteau France Telecom R&D 38/40 rue du General Leclerc 92131 Issy-Les-Moulineaux Cedex France Phone: (+33) 1 45 29 58 67 EMail : gilles.chanteau@rd.francetelecom.com Yann Codaccioni France Telecom R&D Authors [Page 27] Internet Draft Experiments with RFC 3077 July 2003 38/40 rue du General Leclerc 92131 Issy-Les-Moulineaux Cedex France Phone: (+33) 1 45 29 64 67 EMail : yann.codaccioni@rd.francetelecom.com Emmanuel Duros UDcast 2455 Route des Dolines BP355 06906 Sophia Antipolis France France EMail : Emmanuel.Duros@UDcast.com Virginie Faineant France Telecom R&D 38/40 rue du General Leclerc 92131 Issy-Les-Moulineaux Cedex France Phone: (+33) 1 45 29 49 77 EMail : virginie.faineant@rd.francetelecom.com Godred Fairhurst Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK Email: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry Achmad Husni Thamrin Graduate School of Media and Governance Keio University 5322 Endo, Fujisawa Kanagawa 252-8520 Japan Email: husni@ai3.net Amine Lamani France Telecom Research and Development Satellite Networks Architecture 38-40, rue du General Leclerc, 92794 ISSY-LES-MOULINEAUX cedex 9 FRANCE Jun Takei JSAT Co. 1-11-1 Marunouchi, Chiyoda-ku Authors [Page 28] Internet Draft Experiments with RFC 3077 July 2003 Tokyo 100-6218 JAPAN EMail : takei@csm.jcsat.co.jp 10. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 11. IANA Considerations There are no IANA considerations associated with this draft. Authors [Page 29]