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]