Internet Draft INTERNET-DRAFT Supratik Bhattacharyya Expires 10 September 2000 Christophe Diot Sprint ATL Leonard Giuliano Rob Rockell SprintLink 10 March 2000 Deployment of PIM-SO at Sprint <draft-bhattach-diot-pimso-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 1. Background and Overview This document considers the requirements for implementing PIM Source- Only (PIM-SO) which will allow the creation of source-based multicast trees across multiple domains in the Internet. PIM-SO realizes the EXPRESS [HOLB99] multicast service model in which there is a single source for every multicast group, and group membership and addressing is based on a multicast group address (G) as well as the source's Bhattacharyya/Diot [Page 1] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 unicast address (S). Our short-term goal is to implement PIM-SO with minimal changes to the current multicast routing infrastructure by August 2000, and to provide proof of concept by deploying it on Sprintlab's experimental network. By the end of the year, we envisage that PIM-SO will be ready to be incorporated in Sprint's multicast backbone as a commercial point-to-multipoint service. The current IP multicast service model is an open model where a set of hosts can be aggregated into a group with a single class-D IP address in the range of 224.0.0.0 to 239.255.255.255. Any end-host can send data to this multicast group (even without joining the group), and any end-host can receive data sent to this group by becoming a member of the group. Currently there is no mechanism to restrict a host from joining a multicast group. End-host register multicast group membership with edge-routers (i.e. routers with directly attached hosts) using the IGMP [FENN97,CAIN99] protocol. Multicast-capable routers then exchange messages with each other according to some routing protocol to construct a distribution tree connecting all the end-hosts. A number of different protocols exist for multicast routing, which differ mainly in the type of delivery tree constructed [DEER90,DEER96,PIMSM,PIMDM]. Of these, the Protocol Independent Multicast Sparse-Mode (PIM-SM) protocol is the most widely deployed in today's public networks. PIM-SM, by default, constructs a single spanning multicast tree rooted at a core (rendezvous point or RP) for all group members. However, it also allows a multicast group member to switch to a source-based shortest path tree if it so desires. In the current protocol architecture. PIM-SM is used for intra-domain routing, while the Multicast Source Discovery Protocol(MSDP) [FARI00] is used for building trees across multiple administrative domains. The deployment and use of IP multicast as an inter-domain commercial service is hindered by a number of shortcomings in the current service model and architecture. For example, global address allocation remains an open issue, and there is no support for group access control and network management. For a detailed discussion of some of these issues, refer to [DIOT00]. The recently proposed Explicit Request for Single Source (EXPRESS) multicast service model promises to address some of these deficiencies [HOLB99]. In the EXPRESS model, a multicast group is determined by specifying a source address S as well a group address G. Therefore two groups (S1,G) and (S2,G) are completely unrelated, even though they have the same multicast group address. The IANA has allocated the address range 232/8 for experimentation with a single-source multicast service. In the rest of this document, we refer to an address in this range as a PIM-SO ADDRESS. The Internet multicast community is converging towards single-source Bhattacharyya/Diot [Page 2] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 multicasting as an immediately deployable inter-domain solution. Although this model restricts each multicast group to a single source, it is sufficient for enabling large-scale point-to-multipoint applications such as Internet TV that are expected to dominate the Internet multicast application space in the near future. Hence a single-source multicast service will provide tremendous impetus to Internet multicast deployment and will pave the way for a more general multipoint-to-multipoint service in the future. Our starting point for developing a single-source multicast service is the current multicast infrastructure deployed by large network service providers such as SPRINT, which consists of IGMP version 2 for end-host memberships, PIM-SM for intra-domain routing, and MSDP for inter-domain routing. We intend to implement PIM-SO as a combination of PIM-SM and IGMP, and eliminate the need for MSDP for single source multicast sesions. A key goal of our PIM-SO deployment effort is COEXISTENCE WITH THE CURRENT WIDE-AREA MULTICAST INFRASTRUCTURE. Hence the changes that we propose will not cripple the current architecture and the applications that it supports. We believe that this will allow an incremental deployment strategy for PIM-SO which is appropriate for today's wide-area networks. Moreover we intend to carefully examine interoperability issues arising out of the coexistence of the PIM-SO infrastructure and the classic infrastructure. We feel that the changes needed for integrating PIM-SO into the PIM- SM/MSDP infrastructure are greatly simplified by a strict partition of the multicast address space between PIM-SO sessions and classic PIM-SM sessions. This would mandate that PIM-SO addresses be used ONLY for single-source multicast with source-based trees and non PIM- SO addresses are used for classic PIM-SM style multicasting. In the rest of this document we assume this strict partition for an initial deployment effort. However, in a later section, we discuss the implications of relaxing this requirement. The changes needed for deploying PIM-SO can be broadly categorized as follows : (1) Changes to PIM-SM at core routers. (2) Changes at edge-routers, i.e., routers with directly connected end-hosts. These routers use the IGMP protocol to interact with end- hosts regarding group membership, and use the PIM-SM protocol to interact with core network routers for constructing distribution trees. Hence we need to consider changes to both IGMP and PIM-SM at these edge-routers. Bhattacharyya/Diot [Page 3] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 (3) Changes at end-hosts. This involves changes to IGMP, which is used by end-hosts for joining/leaving multicast groups. Briefly, IGMP must be modifed in order to enable end-hosts to register their interest in a multicast group identified as a (source, group) pair. This is supported by the recently proposed version 3 of IGMP (IGMPv3) [CAIN99]. We anticipate that only a subset of IGMPv3 capabilities will be required to provide PIM-SO functionality. Changes are also required for applications on end-hosts so that they can participate in single-source PIM-SO sessions. In the following sections, we discuss the rationale behind deploying PIM-SO, changes needed to the current infrastructure, and the tradeoffs and open issues in deploying PIM-SO . We also outline our goals and milestones for a project that involves implementing and deploying PIM-SO on an experimental network to provide proof of concept. 2. Architectural Overview In order to deploy PIM-SO, we need to provide support for constructing source-based trees and for routing multicast data based on both a group address and a source address (we henceforth refer to this as (S,G) routing). This in itself is not a radical departure from the current standards; however, on an architectural level, PIM- SO represents a significant rethinking about the separation of functionality between the ROUTING LAYER and the APPLICATION/CONTROL LAYER for wide-area multicasting. Specifically, it aims to restrict the role of a multicast routing protocol to building a multicast tree, and forwarding data packets along that tree. The responsibility of discovering the identity of a multicast source (or equivalently, a multicast service) is left to the application/control layer. This can be achieved through a session advertisement tool such as SDR [SDR], which would have to announce a source address and a group address for a PIM-SO multicast group. The current IP multicast architecture, in its attempt to realize an open many-to-many service model, fails to provide this separation of functionality between service discovery and multicast routing [DIOT00]. This shortcoming is reflected most prominently in the design of the MSDP protocol. MSDP has been designed to connect multiple PIM-SM domains by "discovering" and announcing multicast data sources across domains. However, in practice, most MSDP source announcement (SA) messages carry data, even though this is not mandated by the specifications [FARI00]. Bhattacharyya/Diot [Page 4] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 +-------------+ +--------------+ | session | | | |advertisement| | Multicast | +-------------+ +-------| Name | | | | Server | | | +----| | +-----------+ query | | +--------------+ | End-host |------------+ | | |---------------+ +-----------+ (S,G) | |(S,G) | APPLICATION/CONTROL -------------------------------------------------------------- | ROUTING | PIM-SO = IGMPv3 + PIM-SM Figure 1 : PIM-SO-based architecture Figure 1 is a simple high-level view of a multicast architecture based on PIM-SO. An advertising tool such as SDR can be used to announce multicast services using an abstract naming scheme (a discussion of an appropriate naming scheme is beyond the scope of this document). If an end-host is interested in a specific multicast service (e.g., channel 2 of content provider XYZ), it contacts a "well-known" multicast name server to resolve this name to an (S,G) address. Then it uses the (S,G) address to join the source-based multicast tree for that service. Of course, the session advertisement tool can itself advertise the source and group address for a multicast service, in the same way as SDR. However, there are some inherent advantages to having a separate name server. For example, a content provider may choose to offer the same service from multiple locations, using the same group address G but different sources. In that case a name server, on receiving a query for a service, can map the service onto the source address "closest" to the requesting host. A multicast name server can also provide the point of control for a number of control functions that are likely to be an integral part of a commercial multicast service. For example, it may also function as an authentication server, authenticating a user and provide a decryption key for decrypting data that is sent in an encrypted form from a multicast source. The server can also support a host of other functions such as billing, access control, customer service, community management, etc. Bhattacharyya/Diot [Page 5] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 We now discuss the changes to PIM-SM, IGMP and applications for deploying and using PIM-SO. However, we do not discuss in detail the specifics of IGMPv3 [CAIN99] since this being addressed in a systematic way in [HOLB00]. deployed version of IGMP (IGMPv2) allows end-hosts to register their interest in a multicast group by specifying a class-D IP address. However in order to implement the single-source multicast model, an end-host must specify a source's unicast address as well as a group address. This capability is provided by the recently proposed IGMP version 3 (IGMPv3). IGMPv3 supports "source filtering", i.e., the ability of an end-system to express interest in receiving data packets sent only by SPECIFIC sources, or from ALL BUT some specific sources. Thus, IGMPv3 provides a superset of the capabilities required to realize the EXPRESS model. Hence an upgrade from IGMPv2 to IGMPv3 is an essential change for implementing single-source multicast. We believe that this is the MOST EXTENSIVE CHANGE FOR PIM- SO DEPLOYMENT as it involves changes to the Application Programming Interface (API) on ALL END-HOSTS that want to participate in PIM-SO sessions. Let us now discuss one important change to the API on end-hosts that will be required to support IGMPv3. IGMPv3 requires the API to provide the following operation (or its logical equivalent) [CAIN99]: IPMulticastListen (Socket, IF, G, filter-mode, source-list) "Socket" is an implementation-specific parameter used to distinguish among different requesting entities. IF is a local identifier of the network interface on which the specified multicast address is to be enabled or disabled and G is the multicast group address to which the request pertains. filter-mode may be INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to the specified multicast address is requested only from the IP addresses listed in the source-list parameter. In EXCLUDE mode, reception of packets sent to the given multicast address is requested from all IP source addresses except for those listed in the source-list parameter. As explained in the IGMPv3 specifications [CAIN99], the above IPMulticastListen() operation subsumes the group-specific join and leave operations of IGMPv2. Performing (S,G)-specific joins and leaves is also trivial. A join operation is equivalent to : IPMulticastListen (Socket,IF,G,INCLUDE,{S}) Bhattacharyya/Diot [Page 6] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 and a leave operation is equivalent to IPMulticastListen (Socket,IF,G,EXCLUDE,{S}) .sp For IGMPv3 to support PIM-SO, it may be useful to include a check to see if the group address in an IGMP IPMulticastListen() message is a PIM-SO address. If it is, then IGMPv3 should ensure that one and exactly one source address is specified on the source-list. Moreover, if a system (end-host or edge-router) supports both IGMPv2 and IGMPv3, it must ignore any IGMPv2 message for a PIM-SO address. There are a number of backward compatibility issues between IGMP versions 2 and 3 which have to be addressed. A detailed discussion of these issues is provided in [HOLB00]. One of our goals for the PIM-SO deployment effort is to implement IGMPv3 on a Linux platform; we expect to address and understand IGMP backward compatibility issues as part of that implementation. 4. PIM-SM Modifications The Protocol Independent Multicast (PIM) protocol has two distinct flavors. The first, known as PIM Sparse Mode (PIM SM), supports sparsely populated multicast groups across wide areas by constructing receiver-driven multicast trees. The second, known as PIM Dense Mode (PIM-DM), supports the construction of data-driven trees for dense groups, using a DVMRP-like [DEER90] flood and prune mechanism. PIM-SM itself supports two types of trees, a shared tree rooted at a core (RP), and a source-based shortest path tree. THUS PIM-SM ALREADY SUPPORTS SOURCE-BASED TREES; however, PIM-SM is not designed to allow a router to choose between a shared tree and a source-based tree. In fact, a receiver always joins a PIM shared tree to start with, and may later be switched to a per-source tree by its adjacent edge router. Let us now look at this issue in some more detail. We start with a brief overview of tree construction in PIM-SM. A PIM-SM router receives explicit Join/Prune messages from neighboring routers that have downstream members for a particular multicast group. The router forwards data packet received addressed to a multicast group G, only onto those outgoing interfaces on which explicit joins have been received. A Designated Router (DR) (an edge router with directly attached end-host, that talks IGMP to end-hosts, and PIM-SM to other PIM routers) sends periodic Join/Prune messages towards a group-specific Rendezvous Point (RP) for each group for which it has active members. Thus, by default, PIM-SM sets up a shared tree centered at the RP. When a data source first starts sending data to a multicast group, its DR forwards the data to the RP for that group, from where messages are multicast over the shared tree. Bhattacharyya/Diot [Page 7] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 A router with directly connected members may switch to a source's shortest-path tree if it so chooses. For this purpose, PIM-SM makes a distinction between the (*,G) state which is specific to a group (the source is a wildcard), and the (S,G) state in which both a source a group are specified. A router switches to the per-source tree by initiating a Join messages that indicates (S,G) information (the details are omitted). Join messages then propagate back towards the source establishing (S,G) state at intermediate routers that are subsequently used to forward data packet. Once the receiver starts receiving data from the source-based tree, the DR sends an (S,G) Prune message towards the RP, indicating the packets from source S on multicast group G need not be forwarded towards it along the shared tree. A key to implementing PIM-SO is eliminate the need for starting with a shared tree and then switching to a source-specific tree. This involves the following steps : -- Allow an end-host to specify the source whose group it wants to join. As discussed earlier, this ability is provided by IGMPv3. -- When a DR receives an IGMPv3 Join message for a group with a PIM- SO group address (232/8), it ALWAYS initiate a (S,G) join and NEVER a (*,G) join. Moreover, unlike PIM-SM, it need not send a (S,G) prune towards the RP. In addition, there are a number of PIM-SM protocol details that need attention. Some of these are listed below; we expect to make additions and changes to this list as we proceed with the PIM-SO implementation : -- DRs (with directly attached members) must recognize the address range 232/8 as PIM-SO addresses, designated for source-only multicast. ALL OF THE FOLLOWING POINTS PERTAIN TO ONLY PIM-SO ADDRESSES : --Join/Prune messages : -- Wildcard bit W is always set to 0 indicating that this message applies to (S,G) entry. --RPT-bit R is always set to 0 indicating that information is to be sent towards the source, and not the RP. --For end-hosts joining PIM-SO sessions, edge-routers must not initiate (*,G) joins towards the RP. Bhattacharyya/Diot [Page 8] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 --Hosts sending to a group : The source's DR never encapsulates data in PIM register messages to unicast to the RP. Instead, it forwards data according to the (S,G) entry in its routing table. --Switching from shared-tree to SPT should not be required --The SPT bit is always set to indicate that the source specific tree has been set up. --At core routers, ignore all (*,G) Join/Prune messages for the for PIM-SO group addresses. --Ignore all (*,G) packets at core and edge routers for PIM-SO addresses. --A DR does not need to send a Prune message towards the RP (to detach itself from the shared tree) when it starts receiving data over the source-based tree. --There is no need for Register and Register-Stop messages. --For data packet forwarding in the PIM-SO address range, a router needs to perform a lookup on (S,G) entries only. We also need to examine whether changes are needed to PIM routers in the core of the network. It is desirable to restrict changes to end- hosts and edge-routers, since that simplifies the deployment of PIM- SO in a network that already supports PIM-SM (such as Sprint's IP backbone network). In order to prevent RPs at the core of a network from receiving (and possibly forwarding) data from sources, it is necessary to block all Source Advertisement (SA) requests at anycast RPs. Moreover we need to pay attention to a configuration issue for certain multicast-capable core routers. Currently, every such router is configured in Sparse Mode(SM)-only or in Sparse/Dense mode (SM/DM). The difference between the two configurations lies in the action taken by the router when it does not have knowledge of the RP associated with a group address found in an incoming packet. If the router is configured as SM-only, the packet is forwarded only if there is a (*,G) entry for that group, otherwise the packet is dropped. On the other hand, if the router is configured as SM/DM, then the packet is FLOODED ON ALL OUTGOING INTERFACES. .sp Given that PIM-SO eliminates the need for having RP addresses associated with PIM-SO addresses, we have to carefully consider the implications of doing away entirely with a mapping between PIM-SO addresses and RPs. The lack of such mapping will lead to the possibility of the flooding phenomenon described above for routers Bhattacharyya/Diot [Page 9] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 configured in the SM-only mode. Such flooding does not affect the correctness of the implementation, but it definitely hurts robustness by generating large numbers of unwanted packets. The changes discussed so far can be implemented either as router configuration options or can be enforced in the PIM-SM code in the kernel. From a deployment standpoint, the latter option is preferable, since it will be easier to reconfigure the routers if the PIM-SO address range changes (or expands) in the future. 5. Dial-up Hub Modifications Figure 2 is a simple high level view of Sprint's existing dial-up hub architecture. Internet | | | +-------+ | R1 | PIM-SM +-------+ | |Ethernet | +-------+ | RAS |IGMP proxy +-------+ | | PPP | +----------+ | Dial-up | | End Host | +----------+ Figure 2 Dial-up users connect to the remote access server, RAS, through a standard PPP connection. The RAS connects to Router R1 via ethernet, and sends all default IP traffic to R1. When the end host joins a multicast group, it sends an IGMP Join message to RAS. RAS acts as a proxy and forwards this to R1. By simply proxying IGMP, RAS does not need to run any multicast routing protocol. In this way, it can support any underlying multicast routing protocol. So to enable a PIM-SO deployment, RAS simply must proxy IGMPv3 in the same manner it Bhattacharyya/Diot [Page 10] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 proxies IGMPv1 and v2 today. Since R1 supports PIM-SM today, it too needs only to add support for IGMPv3. 6. Requirements for Multicast Applications Thus far, we have discussed modifications to IGMP and PIM-SM in order to realize PIM-SO. Let us now consider how we can enable multicast applications to use the underlying PIM-SO routing infrastructure. Two important conditions have to be satisfied for this : -- For single-source multicast sessions using PIM-SO addresses, session advertisement tools must advertise a source address as well as a PIM-SO address. -- In order to join a PIM-SO based multicast tree, an application must specify a source address in addition to a PIM-SO group address. In other words, the application must be "IGMPv3-aware". The issue of application requirements has to be considered from two perspectives. First, PIM-SO is expected to enable a large class of new point-to-multipoint services from large content providers. We can expect these content providers to write their applications to be IGMPv3-aware. At the same time, we need to consider modifications for existing applications. The single-source multicast model is a natural fit for popular commercial applications such as IPTV, Real's media player, and Windows Media Player since data is streamed from a single source. The client side of these applications must be capable of specifying both a source address and a group address in order to join PIM-SO sessions. We now briefly outline our initial plans for implementing IGMPv3 on an IGMPv2-capable Linux platform, and for allowing users to participate in single-source PIM-SO sessions with minimal changes to existing applications. As shown in Figure 3, we plan to implement IGMPv3 as a separate kernel-loadable module. all incoming IGMPv3 messages to the IGMPv3-capable end-host will be handled by the IGMPv3 module while all IGMPv2 messages will be handled by IGMPv2-capable kernel as before. However, IGMPv3 messages for non PIM-SO addresses (e.g. a group-specific query) and IGMPv2 messages for PIM-SO addresses will be ignored (Figure 3). Similarly, on the outbound path, the IGMPv3 module will initiate joins and leaves for PIM-SO addresses, while all other addresses will be handled by IGMPv2 in the kernel. Bhattacharyya/Diot [Page 11] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 We plan to use popular applications such as sdr, vic and vat for initial demonstrations of our PIM-SO implementation. Since will be used to "announce" PIM-SO sessions, it has to be modified to advertise a source address for every PIM-SO session. Sdr uses an RP- based infrastructure for discovering the multicast sessions that it announces; hence it is debatable whether it is suitable for a PIM-SO infrastructure which aims to eliminate the need for RPs altogether. However, we are planning to use sdr only for demonstrations in the short term, while we wait for more current applications such as IPTV to be made IGMPv3 awareness. While we must modify sdr to support PIM-SO, we want to minimize the changes required for applications such as vic and vat. A possible way of achieving this is as follows. Suppose a single-source session (S,G) is advertised by sdr and a user wants to join the session with vat as the application tool. When vat is started up, it requests a "join" with only the group address G. However when G is found to be a PIM-SO address it is intercepted by the IGMPv3 module for processing. At the same time, sdr informs the IGMPv3 module of the source address S corresponding to that session. The IGMPv3 module then uses both the group and source addresses for initiating an IGMPv3 "join" for that session. +-------+ G +------+ | vat |<-----------------| sdr | +-------+ +------+ | | G | | S | | | +---------------+ | +-->| IGMPv3 module |<-----+ +---------------+ | | | |IGMPv3 (S,G) | Join | | | | USER ---------------+-------+----------------------- | | KERNEL +--------+ | | | IGMPv2 | | YES +----------> +--------+ | | | | NO | --------- v3? <------------------ Bhattacharyya/Diot [Page 12] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 Figure 3 : Linux implementation of IGMPv3 7. Tradeoffs and Open Issues In this section, we summarize some of the advantages and disadvantages of a PIM-SO based IP multicasting architecture, and discuss how some of the current shortcomings may be addressed in the future. Some of the advantages of PIM-SO are as follows : -- Clear separation between routing and application/control level functionality, leading to a simpler, cleaner multicast architecture. -- The architecture is much simpler to manage than the current IGMPv2/PIM-SM/MSDP architecture , making it attractive to network operators such as SPRINT who will deploy and offer multicast as a commercial service. --The service model is capable of supporting the requirements of 99% of Sprint's customers today. -- A number of functionalities such as access control, billing and authentication are expected to be a key part of a commercial multicast service offering. We discussed in Section 2 how a PIM-SO based routing architecture can support these key functionalities at the application/control level. The most serious criticism of the PIM-SO architecture is that it does not support shared trees which may be useful for supporting many-to-many applications. In the short-term this is not a serious concern since the multicast application space is likely to be dominated by one-to-many applications. Some other classes of multicast applications that are likely to emerge in the future are few-to-few (e.g. private chat rooms, whiteboards), few-to-many (e.g., video conferencing, distance learning) and many-to-many (e.g., large chat rooms, multi-user games). The first two classes can be easily handled using a few one-to-many source-based trees. The issue of many-to-many multicasting service on top of a PIM-SO architecture is an open issue at this point. However, we feel that even many-to-many applications should be handled with multiple one- to-many instead of shared trees. The rationale behind this lies in receiver interest filtering [LEVI00] - as the number of members in a multicast group increases, there is a decrease in the overlap of interest among members in a group. Hence a shared tree actually Bhattacharyya/Diot [Page 13] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 wastes bandwidth by pushing data towards receivers that have no use for the data. Multiple source-based trees achieve bandwidth efficiency at the expense of a minimal increase in router forwarding state. But we believe that router memory will be less expensive than bandwidth; hence the tradeoff will work in favor of source-based trees. 8. Address Space Overlap Moving to PIM-SO will create two kinds of problems in term of addressing. In the transition period, PIM-SO and PIM-SM need to co- exist. There will consequently be two types of multicast groups on the Internet: shared groups and single-sender groups. From an addressing standpoint, it is important that PIM-SO group use the 232/8 address range and that PIM-SM groups DO NOT use 232/8 addresses. Depending on whether a host is PIM-SO and/or PIM-SM enabled, it will need to have the following capabilities: - a PIM-SM sender MUST use a class D address outside the 232/8 range. - a PIM-SM receiver CAN issue a (*, G) join to PIM-SM group. - a PIM-SO sender MUST use a class D address within the 232/8 range. - a PIM-SO receiver CAN issue a (S, G) join to any multicast group, irrespective of whether it is a PIM-SO address or not. These requirements are very important for addressing backward compatibility issues between PIM-SO and PIM-SM/MSDP. Once PIM-SO is deployed, shared groups will be supported by PIM-SM/MSDP and single- sender groups will be supported by PIM-SO. In the future, relying on PIM-SO only might require some more constraints on the addressing scheme to support shared groups. This problem is not addressed in this draft. 9. Experimental Testbed Our near-term goal is to provide proof of concept that PIM-SO is capable of providing a robust and manageable multicast service. We propose to demonstrate this by deploying PIM-SO on the experimental network maintained by Sprintlabs. Figure 4 shows the current architecture (this architecture may change somewhat in the next few months) of this testbed. We now provide a brief description of our initial deployment plans over this network. Many of the details about the testbed are omitted for the sake of clarity. As part of this testbed, one hundred residences are provided with a connectivity of 10 Mbps to an experimental network. The experimental network is firewalled from the public Internet but connected at OC-3 Bhattacharyya/Diot [Page 14] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 speeds to Sprintlab's internal testbed. In the initial experiment with PIM-SO, we intend to have a source located at Sprintlabs multicasting data to the residences participating in the testbed. A Linux-based PC in each residence will support IGMPv3 in the kernel, and will exchange IGMPv3 messages with router R3, which will support IGMPv3. Router R3 is also expected to support PIM-SM, modified to support single-source multicast for PIM-SO addresses. Routers R1 and R2 have PIM-SM capability and, together with R3, will build a tree reaching the hundred homes from a source in Sprintlabs. For the time being, a tunnel will be created through the firewall to allow multicast packets through. +-----------+ +--------+ +--------+ +--------+ | SPRINT ATL| | Home |...| Home | | Mcast | | Lab | +--------+ +--------+ | Source |-----| Server | | | | | | | | ... | +--------+ +-----------+ +---------------------+ | | 16 Ethernet Switches| +----+ | +---------------------+ | | OC3 | | | R1 |---------+ | Gigabit | | +---------+ +----+ Ethernet| | | |OC3 +---------+ +-------+ | | | +----+ | | | | OC-12 | | | |Ether- | +-----------+ +----+ | SONET |---| R4 |--|net | | Firewall/ | OC3 | | | Ring | | | |Switch | | NAT |--------| R2 |---| | +----+ | | | | | | | | +-------+ +-----------+ +----+ +---------+ | | | | +----------------------+ INTERNET +-----| DIAL-UP Customers | +----------------------+ Figure 4 : PIM-SO Testbed We are exploring the possibility of involving a commercial content provider to participate in our experiments on the PIM-SO testbed. We also intend to examine the feasibility and security implications of allowing multicast sources from the public Internet to send data to Bhattacharyya/Diot [Page 15] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 the testbed receivers. Finally, we are actively pursuing the upgrade of 3Com's Total Control Hub (TCH) to support IGMPv3. This will allow receivers to connect to our testbed over a dial-up connection and receive multicast data sent over a PIM-SO tree. 10. Project Goals May-July 2000 : --Implement IGMPv3 for the Linux kernel on end-hosts. --Modify end-systems to provide support for "IGMPv3-aware" applications. --Work with router vendors to provide support for IGMPv3 on edge- routers. --Test modified end-hosts and modified edge routers. July-August 2000 : --Deploy and test PIM-SO on the Sprintlabs testbed. --Test dial-up multicast service using a IGMPv3-capable Total Control Hub (TCH) from 3Com. September-October 2000 : --Perform exhaustive testing on PIM-SO testbed. November-December 2000 : --Complete the implementation and testing of all components required for deploying PIM-SO on SprintLink's backbone. 11. Acknowledments We would like to thank a number of people at Sprint Labs -- Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon, Timothy Roscoe and JayCee Straley -- for participating in lengthy discussions on PIM-SO, and providing feedback on this document. Thanks are also due to Mujahid Khan and Ted Seely at SprintLink, Tom Pusateri at Juniper Networks, Isidor Kouvelas at Cisco Systems, Bill Fenner at ATT Research, Kevin Bhattacharyya/Diot [Page 16] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 Almeroth at the University of California Santa Barbara, Brian Levine at the University of Massachusetts Amherst, Brad Cain at Nortel Networks and Hugh Holbrook at Cisco Systems for their valuable insights and continuing support. 11. References: [HOLB99] H. Holbrook and D.R. Cheriton. IP Multicast Channels : EXPRESS Support for Large-scale Single-Source Applications. In Proceedings of SIGCOMM 1999. [FENN97] W. Fenner. 2236, November 1997. [CAIN99] B. Cain and S. Deering and A. Thyagarajan. Internet Group Management Protocol, Version 3. Internet Draft draft-ietf-idmr-igmp-v3-02.txt, November 1999. [HOLB00] H. Holbrook and B. Cain. Use of the 232/8 Address Space. Work in Progress. [DEER90] S. Deering and D. Cheriton. Multicast Routing in Datagram Networks and Extended LANs. ACM Transactions on Computer Systems, 8(2):85-110, May 1990. [DEER96] S. Deering et al. PIM Architecture for Wide-Area Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, April 1996. [ESTR98] D. Estrin et al. Protocol Independent Multicast - Sparse Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362, 1998. [DEER99] S. Deering et al. Protocol Independent Multicast Version 2 Dense Mode Specification. Internet Draft draft-ietf-pim-v2-dm-03.txt, June 1999. [FARI00] Farinacci et al. Multicast Source Discovery Protocol. Internet Draft draft- ietf-msdp-spec-02.txt, January 2000. [DIOT00] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen. Deployment Issues for the IP Multicast Service and Architecture. In IEEE Networks Magazine's Special Issue on Multicast, January, 2000. Bhattacharyya/Diot [Page 17] INTERNET-DRAFT Deployment of PIM-SO at Sprint 10 March 2000 [SDR] Session directory (sdr). http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr. [LEVI00] B. Levine et al. Consideration of Receiver Interest for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 2000. 12. Authors' Address: Supratik Bhattacharyya Christophe Diot Sprint Advanced Technology Labs One Adrian Court Burlingame CA 94010 {supratik,cdiot}@sprintlabs.com http://www.sprintlabs.com Leonard Giuliano Robert Rockell Sprint Internet Service Center Reston, Virginia {giuliano,rrockell}@sprintlink.net Bhattacharyya/Diot [Page 18]