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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Terminology
3.  Overview
4.  Hybrid Multicast API
    4.1.  Abstract Data Types
    4.2.  Send/Receive Calls
    4.3.  Service Calls
5.  Deployment Use Cases
    5.1.  DVMRP
    5.2.  PIM-SM
    5.3.  PIM-SSM
    5.4.  BIDIR-PIM
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

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:

*-------*     *-------*
| 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)

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] (Waitzman, D., Partridge, C., and S. Deering, “Distance Vector Multicast Routing Protocol,” November 1988.) 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.

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] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) 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] (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,” August 2006.). 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, 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] (Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Pusateri, “Automatic IP Multicast Without Explicit Tunnels (AMT),” March 2010.) 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] (Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, “Bidirectional Protocol Independent Multicast (BIDIR-PIM),” October 2007.) 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

8.  Acknowledgements

TODO

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses