One document matched: draft-waehlisch-sam-common-api-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-waehlisch-sam-common-api-01"
ipr="trust200811">
<front>
<title abbrev="Common Mcast API">A Common API for Transparent Hybrid
Multicast</title>
<author fullname="Matthias Waehlisch" initials="M." surname="Waehlisch">
<organization>link-lab & FU Berlin</organization>
<address>
<postal>
<street>Hoenower Str. 35</street>
<city>Berlin</city>
<code>10318</code>
<country>Germany</country>
</postal>
<email>mw@link-lab.net</email>
<uri>http://www.inf.fu-berlin.de/~waehl</uri>
</address>
</author>
<author fullname="Thomas C. Schmidt" initials="T C." surname="Schmidt">
<organization>HAW Hamburg</organization>
<address>
<postal>
<street>Berliner Tor 7</street>
<city>Hamburg</city>
<code>20099</code>
<country>Germany</country>
</postal>
<email>schmidt@informatik.haw-hamburg.de</email>
<uri>http://inet.cpt.haw-hamburg.de/members/schmidt</uri>
</address>
</author>
<author fullname="Stig Venaas" initials="S." surname="Venaas">
<organization>cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email>
</address>
</author>
<date day="26" month="October" year="2009" />
<workgroup>SAM Research Group</workgroup>
<abstract>
<t>Group communication services are most efficiently implemented on the
lowest layer available. However, as the deployment status of multicast
distribution largely varies throughout the Intenet, globally operational
group solutions are frequently restricted to using a stable, upper layer
protocol controlled by the application itself. This document describes a
common multicast API that serves the requirements of data distribution
and maintenance for multicast and broadcast on a middleware abstraction
layer, suitable for transparent underlay and overlay communication. It
proposes and discusses mapping mechanisms between different namespaces
and forwarding technologies. Additionally, it describes the application
of this API at gateways operating between current multicast instances
throughout the Internet.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Group communication is implemented on different layers (e.g., IP vs.
application layer multicast) as well as based on different technologies
on the same tier (e.g. IPv4 vs. IPv6). To allow for a reliable
deployment of applications and group services, a common API is required
that offers calls to transmit and receive multicast data independent of
the underlying technology, and also provides a consistent view on
multicast states. This document describes an abstract group
communication API and core functions required for transparent
operations. Specific implementation guidelines with respect to operating
systems or programming languages are out-of-scope of this document.</t>
<t>The aim of this common API is twofold: <list style="symbols">
<t>Enable any application programmer to implement group-oriented
data communication independent of the underlying delivery
mechanisms. In particular, make applications efficient, but robust
with respect to deployment aspects.</t>
<t>Allow for a flexible namespace support in group addressing, and
thereby separate addressing and routing schemes from application
design. This abstraction not only reduces the dependency on specific
apects of underlying protocols, but may open application design to
extend to specifically flavored group services.</t>
</list></t>
<t>Multicast technologies may be various P2P-based, IPv4 or IPv6 network
layer multicast, or implemented by some other application service.
Corresponding namespaces may be IP addresses, overlay hashes, other
application layer group identifiers, e.g., <sip:*@peanuts.org>, or
names defined by the applications.</t>
<t>This document also proposes and discusses mapping mechanisms between
different namespaces and forwarding technologies. Additionally, the
multicast API provides internal interfaces to access current multicast
states at the host. Multiple multicast protocols may run in parallel on
a single host. These protocols may interact to provide a gateway
function that bridges data between different domains. The application of
this API at gateways operating between current multicast instances
throughout the Internet is described, as well.</t>
</section>
<section title="Terminology">
<t>This document uses the terminology as defined for the multicast
protocols <xref target="RFC2710"></xref>,<xref
target="RFC3376"></xref>,<xref target="RFC3810"></xref>,<xref
target="RFC4601"></xref>,<xref target="RFC4604"></xref>. In addition,
the following terms will be used.</t>
<t><list style="hanging">
<t hangText="Multicast Namespace:">A Multicast Namespace is a
collection of designators for groups that share a common syntax.
Typical instances of namespaces are IPv4 or IPv6 multicast
addresses, overlay group ids, group names defined on the application
layer, or some human readable</t>
<t hangText="Multicast Context:">A Multicast Context is a domain
that accommodates nodes and routers of a common, single mutlicast
forwarding technology and is bound to a single namespace.</t>
<t hangText="Inter-domain Multicast Gateway:">An Inter-domain
Multicast Gateway (IMG) is an entity that interconnects domains of
different mutlicast contexts. Its objective is to transparently
forward data between contexts, e.g., between IP layer and overlay
multicast.</t>
</list></t>
<t></t>
</section>
<section title="Objectives and Reference Scenarios">
<t>The default use case addressed in this memo targets at applications
that jointly communicate in a group by using a common identifier taken
from some common namespace. Programmers shall be entitled to
transparently use this identifier in their program without the need to
consider a deployment status in target domains. Aided by gateways and,
where available, by a node-specific multicast middleware, applications
shall be enabled to establish group communication, even if resident in
domains that are not connected by a common multicast service
technology.</t>
<t>This draft covers the following two general scenarios:</t>
<t><list style="numbers">
<t>Multicast domains running the same multicast technology but
remaining isolated, possibly only connected by network layer
unicast.</t>
<t>Multicast domains running different multicast technologies, but
hosting nodes that are members of the same multicast group.</t>
</list></t>
<figure>
<artwork><![CDATA[
+-------+ +-------+
| Member| | Member|
| Foo | | G |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
* *
* MCast Tec A *
* *
* ** ** ** *
*** *** *** ***
+-------+ +-------+ |
| Member| | Member| +-------+
| G | | Foo | | IMG |
+-------+ +-------+ +-------+
| | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * +-------+ * *
* MCast Tec A * --| IMG |-- * MCast Tec B * +-------+
* * +-------+ * * - | Member|
* ** ** ** * * ** ** ** * | G |
*** *** *** *** *** *** *** *** +-------+
]]></artwork>
<postamble>Reference scenarios for hybrid multicast, interconnecting
group members from isolated homogeneous and heterogeneous
domains.</postamble>
</figure>
<t>It is assumed throughout the document that the domain composition, as
well as the node attachement to a specific technology remain unchanged
during a multicast session.</t>
</section>
<section title="Overview">
<t>The extended multicast functions should be implemented by a
middleware. This middleware exhibits two tasks, it</t>
<t><list style="symbols">
<t>provides an extended API that supports a common multicast
interface with namespace support</t>
<t>bridges data between different multicast technologies.</t>
</list></t>
<figure anchor="fig:middleware"
title="The middleware covers underlay and overlay for the application">
<preamble></preamble>
<artwork><![CDATA[*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------*
| Middleware |
*---------------------*
| |
*---------* |
| Overlay | |
*---------* |
| |
| |
*---------------------*
| Underlay |
*---------------------*]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>The general procedure to initiate multicast communication is the
following:</t>
<t><list style="numbers">
<t>An Application subscribes/leaves/sends to a logical group
identifier.</t>
<t>A middleware maps the logical group ID to a technical group
ID.</t>
<t>The technical group ID is allocated or revised if already in
use.</t>
</list>The application communicates via the logical ID and data
distribution is based on the technical ID. A mapping is required between
the IDs, especially if both identifiers belong to different namespaces.
This mapping can be realized by embedding smaller in larger namespaces
or selecting an arbitrary, unused ID in the target space. The relation
between logical and technical ID is stored based on a mapping service
(e.g. DHT). The middleware, thus queries the mapping service first, and
creates an new technical group ID only if there is no identifier
available for the namespace in use. Depending on the scope of the
mapping service, it ensures a consistent use of the technical ID in a
local or global domain.</t>
<t>Hosts may support several multicast protocols. In this case, they
will be enabled to forward data between the different technologies using
the service calls of the API. Such a proxy function can be implemented
on each host or on dedicated gateways. These gateways also assist
multicast members that have no middleware support to be integrated in
additional namespaces.</t>
</section>
<section title="Hybrid Multicast API">
<t></t>
<section title="Abstract Data Types">
<t><list style="hanging">
<t hangText="Namespace">describes the domain-specific context in
which the applications operate.</t>
<t hangText="Address">is any kind of address in underlay (e.g.
IPv4, IPv6) or overlay (e.g. SIP, hash-based ID).</t>
<t hangText="Mode">denotes the layer on which the corresponding
call will be effective. This may be unspecified to leave the
decicision at the group communication stack.</t>
</list></t>
</section>
<section title="Send/Receive Calls">
<t><list style="hanging">
<t hangText="init(in Namespace n)">This call is implemented</t>
<t hangText="join(in Address a, in Mode m)">This operation
initiates a group subscription. Depending on the mode, this may
result in an IGMP/MLD report.</t>
<t hangText="leave(in Address a, in Mode m)">This operation
results in an unsubscription for the given address.</t>
<t hangText="send(in Address a, in Mode m, out Message msg)"></t>
<t
hangText="receive(in Address a, in Mode m, out Message msg)"></t>
</list></t>
</section>
<section title="Service Calls">
<t><list style="hanging">
<t hangText="groupSet(out Address[] g, in Mode m)">This operation
returns all registered multicast groups. The information can be
provided by group management or routing protocols. The return
values distinguish between sender and listener states.</t>
<t hangText="neighborSet(out Address[] a, in Mode m)">This
function can be invoked to get the set of multicast routing
neighbors.</t>
<t hangText="designatedHost(out Bool b, in Address a)">This
function returns true, if the host has the role of a designated
forwarder or querier. Such an information is provided by almost
all multicast protocols to handle packet duplication, if multiple
multicast instances serve on the same subnet.</t>
<t hangText="updateListener(out Address g, in Mode m)">This upcall
is invoked to inform a group service about a change of listener
states for a group. This is the result of receiver new
subscriptions or leaves. The group service may call groupSet to
get updated information.</t>
<t hangText="updateSender(out Address g, in Mode m)">This upcall
should be implemented to inform the application about source state
changes. Analog to the updateListener case, the group service may
call thereupon groupSet.</t>
</list></t>
</section>
</section>
<section title="Deployment Use Cases">
<t>This section describes the application of the defined API to
implement an IMG.</t>
<section title="DVMRP">
<t>The following procedure describes a transparent mapping of a
DVMRP-based any source multicast service to another many-to-many
multicast technology.</t>
<t>An arbitrary DVMRP <xref target="RFC1075"></xref> router will not
be informed about new receivers, but will learn about new sources
immediately. The concept of DVMRP does not provide any central
multicast instance. Thus, the IMG can be placed anywhere inside the
multicast region, but requires a DVMRP neighbor connectivity. The
group communication stack used by the IMG is enhanced by a DVMRP
implementation. New sources in the underlay will be advertised based
on the DVMRP flooding mechanism and received by the IMG. Based on this
the updateSender() call is triggered. The relay agent initiates a
corresponding join in the native network and forwards the received
source data towards the overlay routing protocol. Depending on the
group states, the data will be distributed to overlay peers.</t>
<t>DVMRP establishes source specific multicast trees. Therefore, a
graft message is only visible for DVMRP routers on the path from the
new receiver subnet to the source, but in general not for an IMG. To
overcome this problem, data of multicast senders will be flooded in
the overlay as well as in the underlay. Hence, an IMG has to initiate
an all-group join to the overlay using the namespace extension of the
API. Each IMG is initially required to forward the received overlay
data to the underlay, independent of native multicast receivers.
Subsequent prunes may limit unwanted data distribution thereafter.</t>
</section>
<section title="PIM-SM">
<t>The following procedure describes a transparent mapping of a
PIM-SM-based any source multicast service to another many-to-many
multicast technology.</t>
<t>The Protocol Independent Multicast Sparse Mode (PIM-SM) <xref
target="RFC4601"></xref> establishes rendezvous points (RP). These
entities receive listener and source subscriptions of a domain. To be
continuously updated, an IMG has to be co-located with a RP. Whenever
PIM register messages are received, the IMG must signal internally a
new multicast source using updateSender(). Subsequently, the IMG joins
the group and a shared tree between the RP and the sources will be
established, which may change to a source specific tree after a
sufficient number of data has been delivered. Source traffic will be
forwarded to the RP based on the IMG join, even if there are no
further receivers in the native multicast domain. Designated routers
of a PIM-domain send receiver subscriptions towards the PIM-SM RP. The
reception of such messages invokes the updateListener() call at the
IMG, which initiates a join towards the overlay routing protocol.
Overlay multicast data arriving at the IMG will then transparently be
forwarded in the underlay network and distributed through the RP
instance.</t>
</section>
<section title="PIM-SSM">
<t>The following procedure describes a transparent mapping of a
PIM-SSM-based source specific multicast service to another one-to-many
multicast technology.</t>
<t>PIM Source Specific Multicast (PIM-SSM) is defined as part of
PIM-SM and admits source specific joins (S,G) according to the source
specific host group model <xref target="RFC4604"></xref>. A multicast
distribution tree can be established without the assistance of a
rendezvous point.</t>
<t>Sources are not advertised within a PIM-SSM domain. Consequently,
an IMG cannot anticipate the local join inside a sender domain and
deliver a priori the multicast data to the overlay instance. If an IMG
of a receiver domain initiates a group subscription via the overlay
routing protocol, relaying multicast data fails, as data are not
available at the overlay instance. The IMG instance of the receiver
domain, thus, has to locate the IMG instance of the source domain to
trigger the corresponding join. In the sense of PIM-SSM, the signaling
should not be flooded in underlay and overlay.</t>
<t>One solution could be to intercept the subscription at both, source
and receiver sites: To monitor multicast receiver subscriptions
(updateListener()) in the underlay, the IMG is placed on path towards
the source, e.g., at a domain border router. This router intercepts
join messages and extracts the unicast source address S, initializing
an IMG specific join to S via regular unicast. Multicast data arriving
at the IMG of the sender domain can be distributed via the overlay.
Discovering the IMG of a multicast sender domain may be implemented
analogously to AMT <xref
target="I-D.ietf-mboned-auto-multicast"></xref> by anycast.
Consequently, the source address S of the group (S,G) should be built
based on an anycast prefix. The corresponding IMG anycast address for
a source domain is then derived from the prefix of S.</t>
</section>
<section title="BIDIR-PIM">
<t>The following procedure describes a transparent mapping of a
BIDIR-PIM-based any source multicast service to another many-to-many
multicast technology.</t>
<t>Bidirectional PIM <xref target="RFC5015"></xref> is a variant of
PIM-SM. In contrast to PIM-SM, the protocol pre-establishes
bidirectional shared trees per group, connecting multicast sources and
receivers. The rendezvous points are virtualized in BIDIR-PIM as an
address to identify on-tree directions (up and down). However, routers
with the best link towards the (virtualized) rendezvous point address
are selected as designated forwarders for a link-local domain and
represent the actual distribution tree. The IMG is to be placed at the
RP-link, where the rendezvous point address is located. As source data
in either cases will be transmitted to the rendezvous point address,
the BIDIR-PIM instance of the IMG receives the data and can internally
signal new senders towards the stack via updateSender(). The first
receiver subscription for a new group within a BIDIR-PIM domain needs
to be transmitted to the RP to establish the first branching point.
Using the updateListener() invocation, an IMG will thereby be informed
about group requests from its domain, which are then delegated to the
overlay.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft does neither introduce additional messages nor novel
protocol operations. TODO</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TODO</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1075"?>
<?rfc include="reference.RFC.5015"?>
<?rfc include="reference.RFC.3810"?>
<?rfc include="reference.RFC.4604"?>
<?rfc include="reference.RFC.2710"?>
<?rfc include="reference.RFC.4601"?>
<?rfc include="reference.RFC.3376"?>
<?rfc include="reference.I-D.ietf-mboned-auto-multicast"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:19:40 |