912 Matthias Wählisch and Thomas C.

Schmidt

4 Hybrid Multicast

Structured peer-to-peer systems offer multicast services in an infrastructure-agnostic

fashion. They are reasonably efficient and scale over a wide range of group sizes.
However, they neither take advantage of network layer multicast where available,
nor allow for layer 2 interactions and thus do not facilitate unrestricted scaling in
shared end system domains. Hybrid multicast schemes attempt to combine the po-
tentials of underlay and overlay multicast, targeting at a simultaneous deployment
of multicast services on the network layer wherever available, and on the overlay
otherwise.
Structured approaches to overlay multicast or broadcast can serve a variety of
needs, as has been shown in the previous section. A careful selection of a scheme
with respect to deployment objectives allows for an appropriate balancing of data
flows, facilitates a trade between state maintenance and path lengths, and may over-
come stability issues at inner nodes of the tree structure. However, they show a
performance gap between IP and application layer multicast that widens, when mo-
bility is introduced. Frequent handoffs and topological re-arrangements degrade
the stability of distribution trees and the efficiency of proximity selection. Gary-
falos and Almeroth [18] derived from fairly generic principles efficiency measures
for source specific multicast in different metrics. Overlay trees uniformly admitted
degradations up to a factor of four over native IP layer multicast in the presence of
MIPv6 [22] mobility management. These drawbacks may be mitigated by hybrid
approaches, as well, by placing overlay multicast routing among selected nodes,
which are particularly stable and form a virtual infrastructure.
Hybrid multicast schemes offer the potential to inherit major efficiency from the
IP layer, while sustaining ease in deployment and infrastructure-transparency from
selected group distribution in overlay networks. Such approaches differentiate the
end-to-end design argument [33] with respect to the inhomogeneous nature of the
global Internet: While customer-oriented end system networks, which are mainly
built on top of multicast enabled network access technologies, do significantly profit
of utilizing network layer multicast services, the flow-oriented transition networks
of the Internet core do not.
The design of interconnecting end system domains on the basis of a struc-
tured overlay can be transparently implemented by inter-domain multicast gateways
(IMGs), leading to the hybrid architecture shown in Fig. 10, and a common group
API as introduced in Section 5. It gives full multicast admission control to local
operators and may be interpreted as a globally distributed service peering. It will
enable inter-domain distribution trees to multicast group services, which remain
invisible to the Internet core, while inheriting the full potential of scalability, self-
organization, redundancy and error resilience from the overlay network protocols in
use. Such adaptive schemes of cooperative routing in underlay and overlay bear the
potential to optimise stability and performance, while sustaining ample flexibility
for deployment.
Multicast Routing in Structured Overlaysand Hybrid Networks 913

KBR Overlay
abde004 141.4.50.3
abcf432 32.4.3.1 acf43de 21.7.2.4
abde004 141.4.50.3 cadb341 154.39.8.8
IMG cadb341 154.39.8.8
abcf432 32.4.3.1
abde004 141.4.50.3 IMG
acf43de 21.7.2.4

IMG

Multicast
Internet Domain
Backbone
IMG IMG
Multicast
Domain

IMG
Multicast
Domain

Fig. 10 Inter-domain multicast gateway (IMG) architecture

4.1 Inter-Domain Multicast Tunneling and Overlays

The deployment history of multicast is tightly bound to bridging multicast-agnostic

regions of the Internet. From its beginning, the Multicast backbone (Mbone) was
built on static IP tunnels, serving as virtual point-to-point interconnects between
isolated multicast domains. This inflexible makeshift is currently converted into an
adaptive, dynamic Automatic Multicast Tunneling (AMT) scheme [35], which al-
lows for on demand creation and termination of inter-domain multicast encapsula-
tion. AMT provides full support for group receivers, but limits sender support to the
Source-specific Multicast (SSM) flavor of multicast.
AMT introduces relays and gateways, designed to cooperate in transmitting mul-
ticast traffic via unicast tunnels across multicast-unaware regions of the Internet.
Relays receive native group traffic from the domain they service, encapsulate and
forward it to corresponding gateways that have joined the relay. Gateways receive
multicast traffic as proxies of a multicast-enabled region, a domain or only a single
host, and redistribute data natively. Based on IGMPv3/MLDv2 [7, 37] signaling,
each relay keeps state in a recipient list for each gateway which has joined a partic-
ular group or source-specific channel (source, group). State management may grow
linearly in receiver numbers and raises scalability concerns. Unicast tunneling itself
remains in conflict with efficient packet distribution and may cause significant link
stress.
The lack of group-specific intelligence inherent to the tunneling layer must be
considered as the major shortcoming of traditional multicast deployment strategies.
914 Matthias Wählisch and Thomas C. Schmidt

Overlay techniques may overcome this deficit and likewise allow for encapsula-
tion. Conceptually, a structured peer-to-peer multicast overlay can distribute group
data from relays to gateways according to selective point-to-multipoint paths. It is
thereby well suited to replace the inefficient mesh of unicast tunnels commonly de-
ployed.
Combining the AMT gateway discovery mechanisms with structured P2P over-
lay multicast, Buford [5, 6] introduces such an architecture of enhanced scala-
bility while sustaining transparent interconnects between separate multicast do-
mains. This early work not only attempts to integrate inter-domain multicast tun-
neling with a variety of structured multicast overlay protocols, but in particular
provides a link to activities of the IETF. The generic peer-to-peer protocol of the
P2PSIP working group will include a mandatory support of a DHT [21]. Thus, it
may be reasonable to assume that DHT substrates will populate the future Inter-
net. These may then also be used as underlying routing infrastructure for multicast
protocols.
In the following section, we will work out an architecture which provides trans-
parent support of general multicast eliminating limitations of AMT, and describe its
interaction with IP layer group management and routing.

4.2 Hybrid Shared Tree Architecture

The Hybrid Shared Tree (HST) architecture, which is composed of a prefix-based

P2P group communication scheme and a relay agent forwarding data between native
and overlay multicast, has been introduced in [39]. The core component of the HST
is the Inter-domain Multicast Gateway. The corresponding application interacts with
native and overlay multicast (OLM) components via the API of an enhanced group
communication protocol stack, and thereby enables relaying. In this section, we
assume the existence of such a stack and its middleware, both will be described in
detail in Section 5.

4.2.1 The Inter-Domain Multicast Gateway

The Inter-domain Multicast Gateway (IMG) transparently forwards multicast data

between the overlay and the native network. This gateway will participate in mul-
ticast traffic originating from its attached network, which it will forward into the
overlay according to the multicast receiver domains of this group. It will also adver-
tise group membership and receive data according to any subscription from its IP
multicast domain. With respect to an easy deployment, the IMG should account for
current multicast techniques.
The IMG represents a transition point between overlay and underlay. In this role
it translates between the different protocols. A structured overlay multicast proto-
col does not provide any explicit group management to discover the presence of
Multicast Routing in Structured Overlaysand Hybrid Networks 915

underlay receivers, since applications use direct API calls on the host. An IMG,
which may represent a complete multicast domain consisting of multiple receivers
and sources, acts in this sense as a proxy: It aggregates and then delegates underlay
states to the overlay routing, as well as data originating from underlay sources to the
overlay routing.
In this architecture, the multicast overlay serves as the routing backbone, con-
necting multiple multicast domains. Hence, the construction and destruction of
distribution branches will be triggered by the underlay, which includes receivers,
sources, both or none of them (cf. Fig. 11). The IMG must be informed about lis-
tener and sender activities within the native network by its group communication
stack. On the arrival of new multicast parties in the underlay, this will happen as
follows:

Overlay
Multicast
Domain

Overlay Overlay
Mcast Mcast
IMG IMG Underlay
Underlay Underlay Multicast
Underlay Mcast Mcast Domain
Multicast
Domain Receiver Data
Subscription
Receiver 0,...,n Source 0,...,n

Fig. 11 Schematic view of general inter-domain multicast gateway scenarios

Multicast Source: If the IMG learns about new underlay sources, it immediately
sends a corresponding join to the underlay group management to receive its
traffic. The IMG thereby holds multicast data independent of other receivers in-
cluding those in different multicast domains. It will send this data internally to
the overlay routing instance, which distributes the message with respect to its
forwarding states. If there is no subscription in the overlay, the data will be dis-
carded by the routing protocol and not transmitted into the overlay. In contrast,
an update about new sources propagated on the overlay takes no effect, as joins
are initiated only based on underlay subscriptions.
Multicast Receiver: For each receiver subscribing to a group as the first member
in the underlay network, the IMG invokes a join, processed by the middleware
and delegated to the overlay multicast routing protocol. The OLM instance ini-
tiates an overlay subscription. Data from the source domain can be transmitted
without additional signaling in the underlay, as data is held at the corresponding
916 Matthias Wählisch and Thomas C. Schmidt

Fig. 12 Two small size multicast domains connected via an overlay

IMG. Multicast streams arriving from the overlay in the receiver domain will be
forwarded transparently by the middleware to the IMG, which distributes it into
the native network. If the IMG recognizes that the last receiver in the underlay
network left the multicast group, it has to send a leave message into the overlay
to cut multicast branches.
In the following, we describe integrations of the protocol concepts in current
multicast scenarios. We distinguish between two cases: small size multicast domains
without a routing infrastructure, and large size domains which are served by native
multicast forwarders.

4.2.2 Connecting Small Size Domains

A small size multicast domain consists of one IP network, two of which are vi-
sualized in Fig. 12. Native multicast data communication is supported by group
management and routing protocols. Group management is available in IP by IGM-
P/MLD [7, 37].5 Implementing MLD signaling represents the minimal requirement
for multicast enabled devices and can be assumed in any multicast domain. Multi-
cast receivers send MLD (un-)subscriptions to a standardized group address, such
that (potential) routers can track the presence of multicast listeners. The router part
of MLD allows to monitor domain-wide group members by a query report scheme.
The IMG operates in the MLD router part.
Packets destined to a multicast group address may be broadcasted in switched
ethernet domains or selectively forwarded based on MLD snooping operated by
domain switches. An MLD snooping-enabled device should transmit group mem-

5 In the following, we will only refer to MLDv2, omitting IGMPv3 which implements the same

scheme for IPv4.

Multicast Routing in Structured Overlaysand Hybrid Networks 917

Fig. 13 Two large size multicast domains covering multiple layer 3 networks (dashed lines)

bership messages and multicast data only to routers and subscribed receivers, i.e., it
implements multicast on layer 2 [12]. Although MLD snooping is not standardized,
its deployment is common practice [12]. However, an MLD node running the router
part sends periodically group membership queries. This allows not only for learning
about active receivers, but also for preventing the suppression of MLD signaling and
source data by layer 2 devices.
Based on the groupSet call provided by the common group API (see Sec-
tion 5), the IMG requests the MLD state table, which provides information about
active listeners. In particular, the IMG will be informed about the first and last mul-
ticast receiver. Correspondingly, the IMG initiates join and leave calls towards
the overlay.
Interconnecting multiple domains without deploying a multicast routing protocol
is specified in [17]. The IMG operates in concordance with this standard which is
solely based on IGMP/MLD. Running the IMG as MLD proxy easily allows to
connect small multicast networks which are not neighboring. On the one hand, this
approach reduces deployment complexity as the IMG can be placed all over the
multicast domain without obligation to maintain a multicast routing protocol. On
the other hand, this scheme limits its scope by the layer 3 region, because MLD
signaling is not forwarded across routers.

4.2.3 Connecting Large Size Domains

Connecting multicast islands by an IMG MLD proxy architecture requires a layer 2

access in each LAN. It does not scale to establish a separate proxy in any layer 2 do-
main of a corresponding larger network. In addition, most larger network domains
have established a local host-group routing which provides domain-wide multicast,
but fails on global multicast connectivity. In such cases, an IMG should be incor-
porated into the local routing infrastructure to interconnect larger native multicast
islands (cf. Fig. 13).
Like in MLD proxy scenarios, a hybrid multicast gateway must be aware of all
groups within a multicast domain to initiate corresponding states in the overlay. In