Network Working Group M. Waehlisch
Internet-Draft link-lab & FU Berlin
Intended status: Informational TC. Schmidt
Expires: April 22, 2010 HAW Hamburg
October 19, 2009
A Common API for Transparent Hybrid Multicast
draft-waehlisch-sam-common-api-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Group communication services are most efficiently implemented on the
lowest layer available. This document describes a common multicast
Waehlisch & Schmidt Expires April 22, 2010 [Page 1]
Internet-Draft Common Mcast API October 2009
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.
Additionally, it describes the application of this API in current
Internet multicast routing protocols.
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Hybrid Multicast API . . . . . . . . . . . . . . . . . . . . . 4
4.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . . 4
4.2. Send/Receive Calls . . . . . . . . . . . . . . . . . . . . 4
4.3. Service Calls . . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Use Cases . . . . . . . . . . . . . . . . . . . . . 5
5.1. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. PIM-SSM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Waehlisch & Schmidt Expires April 22, 2010 [Page 2]
Internet-Draft Common Mcast API October 2009
1. Introduction
Group communication is implemented on different layers. To allow for
a comprehensive development of applications and group services a
common API is required, which provides calls to transmit and receive
multicast data as well as a consistent view on multicast states.
This document describes an abstract group communication API. A
specific implementation description with respect to operating systems
or programming languages is out-of-scope of this document.
The aim of this API is twofold: An application programmer should be
able to implement group-oriented data distribution independent of the
underlying delivery mechanisms (e.g. native IP multicast or
application layer multicast). Receivers require an interface to
subscribe and leave a multicast group. Multicast sources send data
to a group address. This group address relies on a specific
namespace. The API should reflect the flexiblity in choosing an
appropriate namespace.
Additionally, the multicast API should provide internal interfaces to
request current multicast states at the host. Multiple multicast
protocols may run in parallel on a single host. These protocols may
interact together.
2. Terminology
Inter-domain Multicast Gateway: An Inter-domain Multicast Gateway
(IMG) transparently forwards data between IP layer and overlay
multicast.
3. Overview
The API consists of up and down calls. The down calls can be
implemented in a middleware that delegates those to overlay or
underlay:
Waehlisch & Schmidt Expires April 22, 2010 [Page 3]
Internet-Draft Common Mcast API October 2009
*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------*
| Middleware |
*---------------------*
| |
*---------* |
| Overlay | |
*---------* |
| |
| |
*---------------------*
| Underlay |
*---------------------*
4. Hybrid Multicast API
4.1. Abstract Data Types
Namespace describes the domain-specific context in which the
applications operate.
Address is any kind of address in underlay (e.g. IPv4, IPv6) or
overlay (e.g. SIP, hash-based ID).
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.
4.2. Send/Receive Calls
init(in Namespace n) This call is implemented
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.
leave(in Address a, in Mode m) This operation results in an
unsubscription for the given address.
send(in Address a, in Mode m, out Message msg)
Waehlisch & Schmidt Expires April 22, 2010 [Page 4]
Internet-Draft Common Mcast API October 2009
receive(in Address a, in Mode m, out Message msg)
4.3. Service Calls
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.
neighborSet(out Address[] a, in Mode m) This function can be invoked
to get the set of multicast routing neighbors.
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.
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.
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.
5. Deployment Use Cases
This section describes the application of the defined API to
implement an IMG.
5.1. DVMRP
An arbitrary DVMRP [RFC1075] 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
Waehlisch & Schmidt Expires April 22, 2010 [Page 5]
Internet-Draft Common Mcast API October 2009
will be distributed to overlay peers.
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.
5.2. PIM-SM
The Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601]
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.
5.3. PIM-SSM
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 [RFC4604]. A multicast distribution tree
can be established without the assistance of a rendezvous point.
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,
Waehlisch & Schmidt Expires April 22, 2010 [Page 6]
Internet-Draft Common Mcast API October 2009
the signaling should not be flooded in underlay and overlay.
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 [I-D.ietf-mboned-auto-multicast] 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.
5.4. BIDIR-PIM
Bidirectional PIM [RFC5015] 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.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
This draft does neither introduce additional messages nor novel
protocol operations. TODO
Waehlisch & Schmidt Expires April 22, 2010 [Page 7]
Internet-Draft Common Mcast API October 2009
8. Acknowledgements
TODO
9. References
9.1. Normative References
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075,
November 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
9.2. Informative References
[I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-09 (work in
progress), June 2008.
Waehlisch & Schmidt Expires April 22, 2010 [Page 8]
Internet-Draft Common Mcast API October 2009
Authors' Addresses
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
Email: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Waehlisch & Schmidt Expires April 22, 2010 [Page 9]