Application Layer Multicast Extensions to RELOAD
draft-kolberg-sam-baseline-protocol-01

Abstract

We describe protocol and API extensions to P2P-SIP for constructing Scalable Adaptive Multicast (SAM) sessions using hybrid combinations of Application Layer Multicast (ALM), native multicast, and multicast tunnels. We use the AMT relay and gateway elements for interoperation between native regions and ALM regions. The baseline architecture allows different overlay algorithms and different ALM control algorithms to be used.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on January 13, 2011.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Definitions
    2.1.  Overlay Network
    2.2.  Overlay Multicast
    2.3.  Peer
    2.4.  Multi-Destination Routing
3.  Assumptions
    3.1.  Overlay
    3.2.  Overlay Multicast
    3.3.  RELOAD
    3.4.  NAT
    3.5.  Regions
    3.6.  AMT
4.  Hybrid ALM Tree Operations
    4.1.  ALM-Only Tree - Algorithm 1
    4.2.  ALM tree with peer at AMT site (AMT-GW)
    4.3.  ALM tree with NM peer using AMT-R
    4.4.  ALM tree with NM peer with P-AMT-R
    4.5.  ALM tree with peer P-AMT-GW
    4.6.  Mixed Region Scenarios
5.  Group Management API
    5.1.  Data Types
    5.2.  Send and Receive Calls
6.  Protocol
    6.1.  Introduction
    6.2.  Tree Lifecylce Messages
        6.2.1.  Create Tree
        6.2.2.  Join
        6.2.3.  Join Accept
        6.2.4.  Join Confirm
        6.2.5.  Join Decline
        6.2.6.  Join Via AMT Gateway
        6.2.7.  Join Via Native Link
        6.2.8.  Leave
        6.2.9.  Leave via AMT Gateway
        6.2.10.  Re-Form or Optimize Tree
        6.2.11.  Heartbeat
    6.3.  AMT Gateway Advertisement and Discovery
    6.4.  Peer Region and Multicast Properties Messages
7.  RELOAD Usages
    7.1.  ALM Usage for RELOAD
    7.2.  Hybrid ALM Usage for RELOAD
8.  Examples
9.  IANA Considerations
10.  Security Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  Additional Stuff
§  Authors' Addresses

1.  Introduction

The concept of scalable adaptive multicast includes both scaling properties and adaptability properties. Scalability is intended to cover:

• large group size
• large numbers of small groups
• rate of group membership change
• admission control for QoS
• use with network layer QoS mechanisms
• varying degrees of reliability
• trees connect nodes over global internet

Adaptability includes

• use of different control mechanisms for different multicast trees depending on initial application parameters or application class
• changing multicast tree structure depending on changes in application requirements, network conditions, and membership
• use of different control mechanisms and tree structure in different regions of network depending on native multicast support, network characteristics, and node behavior

In this document we describe a protocol and API extension to RELOAD [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.) for constructing SAM sessions using hybrid combinations of Application Layer Multicast, native multicast, and multicast tunnels.

1.1.  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].

2.  Definitions

2.1.  Overlay Network

                    P    P    P   P     P
                  ..+....+....+...+.....+...
                 .                          +P
               P+                            .
                 .                          +P
                  ..+....+....+...+.....+...
                    P    P    P   P     P

Overlay network - An application layer virtual or logical network in which end points are addressable and that provides connectivity, routing, and messaging between end points. Overlay networks are frequently used as a substrate for deploying new network services, or for providing a routing topology not available from the underlying physical network. Many peer-to-peer systems are overlay networks that run on top of the Internet. In the above figure, "P" indicates overlay peers, and peers are connected in a logical address space. The links shown in the figure represent predecessor/successor links. Depending on the overlay routing model, additional or different links may be present.

2.2.  Overlay Multicast

Overlay Multicast (OM): Hosts participating in a multicast session form an overlay network and utilize unicast connections among pairs of hosts for data dissemination. The hosts in overlay multicast exclusively handle group management, routing, and tree construction, without any support from Internet routers. This is also commonly known as Application Layer Multicast (ALM) or End System Multicast (ESM). We call systems which use proxies connected in an overlay multicast backbone "proxied overlay multicast" or POM.

2.3.  Peer

Peer: an autonomous end system that is connected to the physical network and participates in and contributes resources to overlay construction, routing and maintenance. Some peers may also perform additional roles such as connection relays, super nodes, NAT traversal, and data storage.

2.4.  Multi-Destination Routing

Multi-Destination Routing (MDR): A type of multicast routing in which group member's addresses are explicitly listed in each packet transmitted from the sender [AGU1984] (Aguilar, L., “Datagram Routing for Internet Multicasting,” March 1984.). XCAST [RFC5058] (Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, “Explicit Multicast (Xcast) Concepts and Options,” November 2007.) is an experimental MDR protocol. A hybrid host group and MDR design is described in [HE2005] (He, Q. and M. Ammar, “Dynamic Host-Group/Multi-Destination Routing for Multicast Sessions,” .).

3.  Assumptions

3.1.  Overlay

Peers connect in a large-scale overlay, which may be used for a variety of peer-to-peer applications in addition to multicast sessions. Peers may assume additional roles in the overlay beyond participation in the overlay and in multicast trees. We assume a single structured overlay routing algorithm is used. Any of a variety of multi-hop, one-hop, or variable-hop overlay algorithms could be used.

Castro et al. [CASTRO2003] (Castro, M., Jones, M., Kermarrec, A., Rowstron, A., Theimer, M., Wang, H., and A. Wolman, “An Evaluation of Scalable Application-level Multicast Built Using Peer-to-peer overlays,” April 2003.)compared multi-hop overlays and found that tree-based construction in a single overlay out-performed using separate overlays for each multicast session. We use a single overlay rather than separate overlays per multicast sessions. We defer federated and hierarchical multi-overlay designs to later versions of this document.

Peers may be distributed throughout the network, in regions where native multicast (NM) is available as well as regions where it is not available.

An overlay multicast algorithm may leverage the overlay's mechanism for maintaining overlay state in the face of churn. For example, a peer may hold a number of DHT (Distributed Hash Table) entries. When the peer gracefully leaves the overlay, it transfers those entries to the nearest peer. When another peers joins which is closer to some of the entries than the current peer which holds those entries, than those entries are migrated. Overlay churn affects multicast trees as well; remedies include automatic migration of the tree state and automatic re-join operations for dislocated children nodes.

3.2.  Overlay Multicast

The overlay supports concurrent multiple multicast trees. The limit on number of concurrent trees depends on peer and network resources and is not an intrinsic property of the overlay. Some multicast trees will contain peers use ALM only, i.e., the peers do not have NM connectivity. Some multicast trees will contain peers with a combination of ALM and NM. Although the overlay could be used to form trees of NM-only peers, if such peers are all in the same region we expect native mechanisms to be used for such tree construction, and if such peers are in different regions we expect AMT to handle most cases of interest.

Peers are able to determine, through configuration or discovery:

• Can they connect to a NM router
• Is an AMT gateway accessible
• Can the peer support the AMT-GW functionality locally
• Is MDR supported in the region

3.3.  RELOAD

We use RELOAD [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.) as the distibuted hash table (DHT) for data storage and overlay by which the peers interconnect and route messages. RELOAD is a generic P2P overlay, and application support is defined by profiles called Usages. In this document we present an Application Layer Multicast (ALM) Usage and a Hybrid ALM Usage.

We also follow the RELOAD terminology for overlay specific terms, such as the distinction between peer, node, and client.

3.4.  NAT

Some nodes in the overlay may be in a private address space and behind firewalls. We use the RELOAD mechanisms for NAT traversal. We permit clients to be leaf nodes in an ALM or HALM tree. The specific capabilities of clients in terms of tree creation and being parents of other nodes will be described in subsequent versions.

3.5.  Regions

A region is a contiguous internetwork such that if native multicast is available, all routers and end systems can connect to native multicast groups available in that region. A region may include end systems.

3.6.  AMT

We use 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.) to connect nodes in ALM region with nodes in NM region. AMT permits AMT-R and AMT-GW functionality to be embedded in hosts or specially configured routers. We assume AMT-R and AMT-GW can be implemented in nodes. AMT has certain restrictions: 1) isolated sites/hosts can receive SSM, 2) isolated non-NAT sites/hosts can send SSM, 3) isolated sites/hosts can receive general multicast. AMT does not permit isolated sites/hosts to send general multicast.

4.  Hybrid ALM Tree Operations

Peers use the overlay to support ALM operations such as:

• Create tree
• Join
• Leave
• Re-Form or optimize tree

There are a variety of algorithms for peers to form multicast trees in the overlay. We permit multiple such algorithms to be supported in the overlay, since different algorithms may be more suitable for certain application requirements, and since we wish to support experimentation. Therefore, overlay messaging corresponding to the set of overlay multicast operations must carry algorithm identification information.

For example, for small groups, the join point might be directly assigned by the rendezvous point, while for large trees the join request might be propagated down the tree with candidate parents forwarding their position directly to the new node.

In addition to these overlay level tree operations, some peers may implement additional operations to map tree operations to native multicast and/or 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.) connections

In the response to join requests, NM peers indicate further details, such as their AMT-Relay, their public IP address (if they are in a private network), and NM peers in AMT regions indicate their AMT gateway etc. This information allows joining peers to establish features of existing tree peers. For NM peers this information enables them to establish if the tree NM peers belong to the same or a different NM region in the network, and ways to connect to it.

It is up to the joining peer to then decide to join the tree via ALM or AMT. Joining peers will select the most suitable peer to connect to based on criteria such as lowest latency, throughput or highest capacity.

As this decision might be application dependent, this draft does not attempt to prescribe any of these criteria, it is up to the joining peer to select the most suitable candidate.

+---------------+                            +---------------+
| AMT Site      |   P1   P2   P3  P4    P5   | Native MCast  |
|     ..........+...+....+....+...+.....+....+.......        |
|     .     +---++                          ++---+  +P6      |
|  P21+     |AMT |                          |AMT |  .        |
|     .     |GW  |                          |RLY |  +P7      |
|     .     +---++                          ++---+  .        |
+-----+---------+                            +------+--------+
      .                                             .
      .                                      +------+--------+
      .                                      |      . Native |
      .                                      |      .  MDR   |
   P20+....+P19                         .....+...+..+P8      |
         .                              .    |   P9          |
+--------+------+                       .    +---------------+
| Native . MCast|                       .
|        ...    |                       .    +---------------+
| P-AMT-R18+    |                    P10+    |Native Mcast   |
|          .    |                       .   ++---+           |
| P-AMT-R17+    |             P-AMT-GW11+===|AMT |           |
|          .+...+..                     .   |RLY |           |
|           P16 |  .+....+........+.....+   ++---+           |
+---------------+   P15  P14      P13   P12  +---------------+

In the above figure we show the hybrid architecture in six regions of the network. All peers are connected in an overlay, and the figure shows the predecessor/successor links between peers. AMT gateways (AMT-GW) do not have native multicast connectivity to the multicast backbone. AMT-Relays (AMT-R) do have native multicast connectivity to the multicast backbone. AMT Gateways provide a connection to the native mulicast backbone via AMT Relays. The peers may have other connections in the overlay.

• No native multicast: Peers (P19 and P20) in this region connect to the overlay
• Native multicast (NM) in an AMT region with a local AMT gateway (AMT GW). There are one or more peers (P21) connected to the overlay in this region.
• Native multicast with a local AMT relay (AMT RLY). There are one or more peers (P6 and P7) connected to the overlay in this region.
• Native multicast with one or more peers which emulate the AMT relay behavior (P-AMT-R17 and P-AMT-R18) which also connect to the overlay. There may be other peers (P16) which also connect to the overlay.
• Native MDR is a native multicast region using multi-destination routing, in which one or more peers (P8 and P9) reside in the region.
• Native multicast with no peers that connect to the overlay, but for which there is at least one peer in the unicast-only part of the network which can behave as an AMT-GW (P21 and P-AMT-GW11) to connect to multicast sources through an AMT-R for that region. It may be feasible to also allow non-peer hosts in such a region to participate as receivers of overlay multicast; for this version, we prefer to require all hosts to join the overlay as peers.

4.1.  ALM-Only Tree - Algorithm 1

Here is a simplistic algorithm for forming a multicast tree in the overlay. Its main advantage is use of the overlay routing mechanism for routing both control and data messages. The group creator doesn't have to be the root of the tree or even in the tree. It doesn't consider per node load, admission control, or alternative paths.

As stated earlier, multiple algorithms will co-exist in the overlay.

1. Peer which initiates multicast group:
   
   
   

   ---

   groupID = create();  // allocate a unique groupId
                        // the root is the nearest peer in the overlay
                        // out of band advertisement or
                        // distribution of groupID,
                        // perhaps by publishing in DHT
   

   Figure 3

   ---

2. Any joining peer:
   
   
   

   ---

   // out of band discovery of groupID, perhaps by lookup in DHT
   joinTree(groupID); // sends "join groupID" message
   

   Figure 4

   ---

   
   
   The overlay routes the join request using the overlay routing mechanism toward the peer with the nearest id to the groupID. This peer is the root. Peers on the path to the root join the tree as forwarding points.
3. Leave Tree:
   
   leaveTree(groupID) // removes this node from the tree
   
   Propagates a leave message to each child node and to the parent node. If the parent node is a forwarding node and this is its last child, then it propagates a leave message to its parent. A child node receiving a leave message from a parent sends a join message to the groupID.
4. Message forwarding:
   
   multicastMsg(groupID, msg);
5. For the message forwarding there are two approaches:
   • SSM tree: The creator of the tree is the source. It sends data messages to the tree root which are forwarded down the tree.
   • ASM tree: A node sending a data message sends the message to its parent and its children. Each node receiving a data message from one edge forwards it to remaining tree edges it is connected to.

4.2.  ALM tree with peer at AMT site (AMT-GW)

In this case, the joining peer is within an AMT region (such as P21 in Figure 2) and attempts to connect to the tree using the ALM protocol. A number of peers which are already member of the tree may respond to this request.

There are the following cases:

• There is at least one NM peer in the tree which is in the same NM region as the joining peer. The joining peer uses ALM routing or connects directly to the NM peer.
• The tree includes at least one NM peer which is in another NM region which supports an AMT-R (such as P6 and P7 in Figure 2) or another peer which can function as a P-AMT-R (P-AMT-R17 in Figure 2), the joining peer can use its AMT-GW to connect to one of the NM peers.
• There is no NM peer in the tree. The NM peer uses ALM routing.

If the peer is not a joining peer and is on the overlay path of a join request:

• If its next hop is a peer in an NM region with AMT-R, then it can select either overlay routed multicast messages or AMT delivered multicast messages.
• If its next hop is a peer outside of an NM region, then it could use either ALM only or use AMT delivery as an alternate path

4.3.  ALM tree with NM peer using AMT-R

In this case, the joining peer is within a NM region (such as P6 in Figure 2)and initially attempts to connect to the tree using the ALM protocol. Again, a number of peers which are members of the tree respond to the request.

There are the following cases:

• There is at least one NM peer in the tree which is in the same NM region as the joining peer (such as P7 in Figure 2). The joining peer uses ALM routing or connects directly to the NM peer.
• There is at least one NM peer in the tree which is in a different NM region as the joining peer (such as P16 in Figure 2).
• There is at least one peer in the tree which can function as P-AMT-GW (P-AMT-GW11 in Figure 2). The NM peer can join the tree using ALM routing and/or connecting to the P-AMT-GW via its local AMT-R.
• There is at least one peer in the tree which is in an AMT-GW region (P21 in Figure 2). The NM peer can join the tree using ALM routing and/or connecting to the peer via the AMT-GW and its local AMT-R.
• There is no NM peer in the tree. The NM peer uses ALM routing.

4.4.  ALM tree with NM peer with P-AMT-R

Either the NM peer supports P-AMT-R (P-AMT-R18 in Figure 2) or another peer in the multicast tree in the same region is P-AMT-R (P16 via P-AMT-R17 in Figure 2) capable. The last three cases above apply here, replacing AMT-R with P-AMT-R.

4.5.  ALM tree with peer P-AMT-GW

Here the joining peer supports P-AMT-GW (P-AMT-GW11 in Figure 2). If the tree includes peers which are in a NM region which supports a AMT-R (P6 and P7 in Figure 2), or a peer featuring P-AMT-R (P-AMT-R17 in Figure 2) the joining peer can connect to these using its AMT-GW functionality.

4.6.  Mixed Region Scenarios

In version 2 of this document we elaborate on:

• ALM tree topology vs NM topology and NM-ALM edges
• Single NM-ALM edge nodes vs multi NM peers from same region in the tree
• Initial tree membership is ALM vs initial tree membership is NM

For ALM tree topology vs NM topology, all peers belong to the overlay, but only P-ALM peers use overlay routing for multicast data transmission. As a default behavior, a P-NM peer should generally prefer to join the tree via an AMT-GW node. But there may be special cases (small trees, short multicast sessions, trees where most of the members are known to be P-ALM) in which the peer can override this to specify an ALM-only join. A P-NM peer may also accept P-ALM children which don't use the AMT tunnel path to participate in the multicast tree.

Consider 3 types of tree links: P-ALM to P-ALM, P-NM to P-NM and P-ALM to/from P-NM:

• P-ALM to P-ALM This is a normal ALM tree path with management strictly in the overlay
• P-NM to P-NM If the peers are in the same region, then the data path use native multicast capability in that region, and control occurs in ALM layer for ALM tree coordination and NM layer for native multicast purposes. If the peers are in different NM regions, then, if AMT gateways are available and configured to support an AMT tunnel between the regions, a tunnel is created using the AMT protocol (or already exists for this multicast group). The peers connect to their respective AMT gateways using the AMT procedure.
• P-ALM to/from P-NM The connection can be either ALM or AMT tunnel depending on the context.

We expect two new functions are needed to build hybrid trees:

• joinViaAMTGateway(peer, AMT-GW, group_id) where 'Peer' is the peer requesting to join the ALM group identified by group_id, and AMT-GW is the ip address of the AMT gateway that the peer uses in its native multicast region. Request is transmitted to one or more parent peer candiates and/or rendezvous peers for the specified group id, according to the usual join protocol in this overlay. If the parent peer is a P-AMT-GW, then a tunnel is formed using the AMT protocol from the P-AMT-GW to the specified AMT-GW. If parent peer is a peer P-NM in native multicast region, then the tunnel is created between P-NM's AMT-GW and the specified AMT-GW, using the AMT protocol. If parent peer is a P-ALM, then the requested is propagated to other peers in the tree according to the join rules.
• leaveViaAMTGateway(peer, AMT-GW, group_id)where 'Peer' is the peer requesting to leave the ALM group identified by group_id, and AMT-GW is the ip address of the AMT gateway that the peer uses in its native multicast region. Request is transmitted the parent peer which is associated with the AMT-GW or provides that role. If the parent peer is a P-AMT-GW, then it removes the child from its AMT children list and may tear down the AMT tunnel P-AMT-GW to the specified AMT-GW if no other children are using it. If parent peer is a peer P-NM in native multicast region, then the tunnel is created between P-NM's AMT-GW and the specified AMT-GW, using the AMT protocol.

Regarding initial tree membership being either P-NM or P-ALM node(s), we expect the general case should be that hybrid tree formation is supported transparently regardless.

5.  Group Management API

The group management API describes interfaces for application programmers to initiate a group, register or deregister multicast listeners, and to send and receive multicast data. It is the aim to provide a stable programming environment that facilitates a late service binding and remains robust with respect to deployment aspects. Following this objective, an application programmer should be enabled to implement a group communication access that will become operational by any group service available, e.g., native multicast, different kinds of overlays, or hybrid services as described in this document. The subsequent calls are part of a universal group service access concept and aligned with the more general API specification presented in [I‑D.waehlisch‑sam‑common‑api] (Waehlisch, M., Schmidt, T., and S. Venaas, “A Common API for Transparent Hybrid Multicast,” March 2010.).

An important issue of group access lies in naming and addressing. While applications sharing access to the same group should use a common name, different underlying technologies deploy different addressing schemes. For example, native multicast is bound to IP addresses (IPv4/IPv6), whereas ALM uses arbitrary strings as multicast names, which will be mapped to the overlay identifier space. Name and address support thus needs to account for variable namespaces, but still provide abstract data types that keep code independent of particular selections. We achieve this by introducing Multicast URIs (cf., [I‑D.waehlisch‑sam‑common‑api] (Waehlisch, M., Schmidt, T., and S. Venaas, “A Common API for Transparent Hybrid Multicast,” March 2010.)).

In this way, the API provides access to implementing group-oriented data communication independent of the underlying distribution technologies. In particular, applications can be designed to meet efficiency requirements independent of deployment aspects in the target domain. The API is located between applications and the group stack at the current host. Here we do not consider the interface between hosts, which is outlined in Section 6 (Protocol).

5.1.  Data Types

Multicast URI

is any kind of multicast address or multicast name that follows the syntax: <scheme>://<groupID>@<authority>:<port>/<credentials>. Examples are ip://224.1.2.3:5000/F06E34 or sip://news@cnn.com.

Handle

gives a reference to a specific instance of a communication object.

5.2.  Send and Receive Calls

init(out Handle s)

This call creates a multicast socket that is bound to some virtual multicast interface and provides a corresponding handle to the application programmer, which will be used for subsequent communication.

join(in Handle s, in URI g)

This operation initiates a group subscription for the name g, including the corresponding tree access.

leave(in Handle s, in URI g)

This operation results in an unsubscription for the given name g, including the corresponding disconnect of the tree.

send(in Handle s, in URI g,in Message m)

This call sends data m to the multicast group name g. It simultaneously initiates creation of the group state, if not already present.

receive(in Handle s, out URI g, out Message m)

This call delivers data m to the application along with an indicator of the group membership.

6.  Protocol

6.1.  Introduction

In this document we define messages for hybrid overlay multicast tree creation, using an existing proposal (RELOAD) in the P2P-SIP WG [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.) for a universal structured peer-to-peer overlay protocol. RELOAD provides the mechanism to support a number of overlay topologies. Hence the hybrid overlay multicast framework [I‑D.irtf‑sam‑hybrid‑overlay‑framework] (Buford, J., “Hybrid Overlay Multicast Framework,” February 2008.) (hereafter SAM framework) can be used with P2P-SIP, and that the SAM framework is overlay agnostic.

We are not proposing that these SAM-specific messages be incorporated into RELOAD since constructing the SAM framework is still a research activity. However, we do propose that RELOAD add an extension mechanism.

As discussed in the SAM requirements draft, there are a variety of ALM tree formation and tree maintenance algorithms. The intent of this specification is to be algorithm agnostic, similar to how RELOAD is overlay algorithm agnostic. We assume that all control messages are propagated using overlay routed messages.

The message types needed for ALM behavior are divided into the following categories:

• Tree life-cycle (create, join, leave, re-form, heartbeat)
• AMT gateway advertisement and discovery
• Peer region and multicast properties

6.2.  Tree Lifecylce Messages

Peers use the overlay to transmit ALM (application layer multicast) operations and hybrid ALM operations defined in this section.

6.2.1.  Create Tree

A new ALM tree is created in the overlay with the identity specified by GroupId. The usual interpretation of GroupId is that the peer with peer id closest to and less than the GroupId is the root of the tree. The tree has no children at the time it is created.

The GroupId is generated from a well-known session key to be used by other Peers to address the multicast tree in the overlay. The generation of the GroupId from the SessionKey MUST be done using the overlay's id generation mechanism.

      struct {
        NodeID PeerId;
        opaque SessionKey<0..2^32-1>;
        NodeID GroupId;
        Dictionary Options;
      } CreateALMTree;

PeerId: the overlay address of the peer that creates the multicast tree.

SessionKey: a well-known string when hashed using the overlay's id generation algorithm produces the GroupId.

GroupId: the overlay address of the root of the tree

Options: name-value list of properties to be associated with the tree, such as the maximum size of the tree, restrictions on peers joining the tree, latency constraints, preference for distributed or centralized tree formation and maintenance, heartbeat interval.

6.2.2.  Join

Causes the distributed algorithm for peer join of a specific ALM group to be invoked. If successful, the PeerId is notified of one or more candidate parent peers in one or more JoinAccept messages. The particular ALM join algorithm is not specified in this protocol.

      struct {
        NodeID PeerId;
        NodeID GroupId;
        Dictionary Options;
      } Join;

PeerId: overlay address of joining/leaving peer

GroupId: the overlay address of the root of the tree

Options: name-value list of options proposed by joining peer

6.2.3.  Join Accept

Tells the requesting joining peer that the indicated peer is available to act as its parent in the ALM tree specified by GroupId, with the corresponding Options specified. A peer MAY receive more than one JoinAccept from diffent candidate parent peers in the GroupId tree. The peer accepts a peer as parent using a JoinConfirm message. A JoinAccept which receives neither a JoinConfirm or JoinDecline response MUST expire.

      struct {
        NodeID ParentPeerId;
        NodeID ChildPeerId;
        NodeID GroupId;
        Dictionary Options;
      } JoinAccept;

ParentPeerId: overlay address of a peer which accepts the joining peer

ChildPeerId: overlay address of joining peer

GroupId: the overlay address of the root of the tree

Options: name-value list of options accepted by parent peer

6.2.4.  Join Confirm

A peer receiving a JoinAccept message which it wishes to accept MUST explicitly accept it before the expiration of the JoinAccept using a JoinConfirm message. The joining peer MUST include only those options from the JoinAccept which it also accepts, completing the negotiation of options between the two peers.

      struct {
        NodeID ChildPeerId;
        NodeID ParentPeerId;
        NodeID GroupId;
        Dictionary Options;
      } JoinConfirm;

ChildPeerId: overlay address of joining peer which is a child of the parent peer

ParentPeerId: overlay address of the peer which is the parent of the joining peer

GroupId: the overlay address of the root of the tree

Options: name-value list of options accepted by both peers

6.2.5.  Join Decline

A peer receiving a JoinAccept message which does not wish to accept it MAY explicitly decline it using a JoinDecline message.

      struct {
        NodeID PeerId;
        NodeID ParentPeerId;
        NodeID GroupId;
      } JoinDecline;

PeerId: overlay address of joining peer which declines the JoinAccept

ParentPeerId: overlay address of the peer which issued a JoinAccept to this peer

GroupId: the overlay address of the root of the tree

6.2.6.  Join Via AMT Gateway

A request to create a hybrid native multicast connection for the specified PeerId peer to join the tree identified by the GroupId. The request is transmitted to one or more parent peer candidates and/or rendezvous peers for the specified group id, according to the usual join protocol in this overlay.

If the parent peer is a P-AMT-GW (a peer which supports the AMT-GW interface), then after JoinAccept and JoinConfirm steps, instead of an overlay parent-child link, an AMT tunnel is formed using the AMT protocol from the P-AMT-GW to the specified AMT-GW to which the Peer is associated.

If parent peer is a peer P-NM in native multicast region, then after JoinAccept and JoinConfirm steps, the tunnel is created between P- NM's AMT-GW and the specified AMT-GW, using the AMT protocol. If parent peer is a P-ALM, then the requested is propagated to other peers in the tree according to the join processing rules.

      struct {
        NodeID PeerId;
        IpAddressPort AMT-GW;
        NodeID GroupId;
        Dictionary Options;
      } JoinViaAMTGateway;

PeerID: the peer requesting to join the ALM group identified by group_id

AMT-GW: ip address of the AMT gateway that the peer uses in its native multicast region.

Options: name-value list of options proposed by joining peer

6.2.7.  Join Via Native Link

This allows child to select specific parent peer, overriding selection based on the basic join method. Typical use is for a peer in NM region to join the multicast group using the local native multicast path for this GroupId. Joining peer determines:

• It is in an NM region, determined for example using MRD (Multicast Router Discovery) [RFC4286] (Haberman, B. and J. Martin, “Multicast Router Discovery,” December 2005.) or configuration
• It knows the native multicast address (NMA) in its region, if it exists, which corresponds to the GroupId
• It can connect to the NMA using IGMP
• Either 1) there is at least one peer that is in the same NM region that is already part of the GroupId, or 2) the region has an AMT- GW which can connect to some P-AMT-GW or P-NM in another NM region which is part of the GroupId. It uses a separate discovery step such as LookupPeerNMInfo described later.
• If there is no such peer in the GroupId, then this joining peer is the first peer to be added which is in an NM region. It CANNOT join using this message type.

ParentPeer and ChildPeer are either in same NM region or in two different NM regions with capability for AMT. Since media is passed via NM path, the parent-child relationship established by this join is for control and membership management

      struct {
        NodeID ChildPeerId;
        NodeID ParentPeerId;
        NodeID GroupId;
        Dictionary Options;
      } JoinWithNativeLink;

ChildPeerId: overlay address of joining peer which is a child of the parent peer

ParentPeerId: overlay address of the peer which is the parent of the joining peer

GroupId: the overlay address of the root of the tree

Options: name-value list of options accepted by both peers

6.2.8.  Leave

A peer which is part of an ALM tree idenfied by GroupId which intends to detach from either a child or parent peer SHOULD send a Leave message to the peer it wishes to detach from. A peer receiving a Leave message from a peer which is neither in its parent or child lists SHOULD ignore the message.

      struct {
        NodeID PeerId;
        NodeID GroupId;
        Dictionary Options;
      } Leave;

PeerId: overlay address of leaving peer

GroupId: the overlay address of the root of the tree

Options: name-value list of options

6.2.9.  Leave via AMT Gateway

A peer which is part of an ALM tree identified by GroupId which intends to detach from either a child or parent peer and which uses an AMT tunnel to connect to the peer SHOULD send a LeaveViaAMTGateway message to the peer it wishes to detach from. A peer receiving a LeaveViaAMTGateway message from a peer which is neither in its parent or child lists SHOULD ignore the message.

The request is transmitted the AdjacentPeerId. AdjacentPeerId MUST remove the specified PeerId from its children or parent lists if present.

If AdjacentPeerId is a P-AMT-GW, then it MAY tear down the AMT tunnel from P-AMT-GW to the specified AMT-GW if no other children are using it. If AdjacentPeerId is a peer P-NM (peer in a native multicast region), then the tunnel between P-NM's AMT-GW and the specified AMT- GW MAY be removed according to the policy and configuration of the AMT-GW.

      struct {
        NodeID PeerId;
        NodeID AdjacentPeerId;
        IpAddressPort AMT-GW;
        NodeID GroupId;
        Dictionary Options;
      } LeaveViaAMTGateway;

PeerId: overlay address of leaving peer

AdjacentPeerId: overlay address of an adjacent (parent or child) peer

AMT-GW: ip address of the AMT gateway that the peer uses in its native multicast region.

GroupId: the overlay address of the root of the tree

Options: name-value list of options

6.2.10.  Re-Form or Optimize Tree

This triggers a reorganization of either the entire tree or only a sub-tree. It MAY include hints to specific peers of recommended parent or child peers to reconnect to. A peer receiving this message MAY ignore it, MAY propagate it to other peers in its subtree, and MAY invoke local algorithms for selecting preferred parent and/or child peers.

      struct {
        NodeID GroupId;
        NodeID PeerId;
        Dictionary Options;
      } Reform;

GroupId: the overlay address of the root of the tree

PeerId: if omitted, then the tree is reorganized starting from the root, otherwise it is reorganized only at the sub-tree identified by PeerId.

Options: name-value list of options

6.2.11.  Heartbeat

A node signals to its adjacent nodes in the tree that it is alive. If a peer does not receive a Heartbeat message within N heartbeat time intervals, it MUST treat this as an explicit Leave message from the unresponsive peer. N is configurable.

      struct {
        NodeID PeerId1;
        NodeID PeerId2;
        NodeID GroupId;
      } Heartbeat;

PeerId1: source of heartbeat

PeerId2: destination of heartbeat

GroupId: overlay address of the root of the tree

6.3.  AMT Gateway Advertisement and Discovery

Allows peer to disclose to other peers in the overlay their ability to act as a native-multicast gateway (as in AMT) for peers in a given region. We expect to use the P2P Publish and Lookup messages for this purpose. But to avoid collision with the semantics of those operations, we temporarily define shadow versions within the SAM extension. Publish stores an advertisement object for a peer with is an AMT gateway in the DHT for the overlay, under a given key.

      struct {
        NodeID PeerId;
        ResourceID Key;
        opaque Region<0..2^32-1>;
        Dictionary Options;
      } PublishAMTGateway;

      struct {
        NodeID PeerId;
        ResourceID Key;
      } LookupAMTGateway;

PeerId: the peer which is the AMT gateway

Key: the key by which other peers lookup the advertisement, details TBD. There can be more than one key.

Region: an id for a region, using some region identification scheme TBD. For example, the Autonomous System Number (ASN) could be used. [RFC1930] (Hawkinson, J. and T. Bates, “Guidelines for creation, selection, and registration of an Autonomous System (AS),” March 1996.)

Options: Name-value list of options

6.4.  Peer Region and Multicast Properties Messages

Peers can advertise the network region that they belong to and its native multicast properties if any. Similar to AMT Gateway advertisement and discovery, uses the DHT for lookup and publish.

      struct {
        NodeID PeerId;
        ResourceID Key;
        opaque Region<0..2^32-1>;
        Dictionary Options;
      } PublishPeerNMInfo;

      struct {
        NodeID PeerId;
        ResourceID Key;
      } LookupPeerNMInfo;

PeerId: the peer which is the AMT gateway

Key: the key by which other peers lookup the advertisement, details TBD. There can be more than one key.

Options: Name-value list of options.

7.  RELOAD Usages

Applications of RELOAD are restricted in the data types that be can stored in the DHT. The profile of accepted data types for an application is referred to as a Usage. RELOAD is designed so that new applications can easily define new Usages. New RELOAD Usages are needed for hybrid multicast applications since the data types in base RELOAD and existing usages are not sufficient.

We define an ALM Usage and a Hybrid ALM Usage in RELOAD. The ALM Usage is sufficient for applications which only require ALM functionality in the overlay. The Hybrid ALM (HALM) Usage extends the ALM Usage so that hybrid native multicast and ALM trees can be used by applications.

The ALM Usage involves the functions:

• ALM applications use the RELOAD data storage functionality to store a groupID when a new ALM tree is created in the overlay, and to retrieve groupIDs for existing ALM trees.
• ALM applications use the RELOAD data storage functionality to store a set of attributes for an ALM tree, such as owner, tree size, tree height, tree formation algorithm, and join criteria.
• ALM applications and management tools use the RELOAD data storage functionality to store diagnostic information about the operation of tree, including average number of tree, delay from source to leaf nodes, bandwidth use, lost packet rate. In addition, diagnostic information may include statistics specific to the tree root, or to any node in the tree.

The Hybrid ALM Usage involves the following additional functions:

• HALM applications use the RELOAD data storage functionality to store a set of attributes for a AMT Gateway that can connect to at least one node in the overlay.
• HALM applications use the RELOAD data storage functionality to store a set of attributes about a native multicast region associated with an AMT Gateway.
• HALM applications and management tools use the RELOAD data storage functionality to store diagnostic information about the operation of AMT and ALM interconnections.

A RELOAD Usage is required [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.) to define the following:

• Register Kind-Id points
• Define data structures for each kind
• Defines access control rules for each kind
• Defines the Resource Name used to hash to the Resource ID where the kind is stored
• Addresses restoration of values after recovery from a network partition
• Defines the types of connections that can be initiated using AppConnect

The following sections are preliminary steps towards formalizing the for ALM and HALM Uages.

7.1.  ALM Usage for RELOAD

A ALM GroupID is a RELOAD Node-ID. The owner of a ALM group creates a RELOAD Node-ID as specified in [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.). This means that a GroupID is used as a RELOAD Destination for overlay routing purposes.

7.2.  Hybrid ALM Usage for RELOAD

8.  Examples

TBD.

9.  IANA Considerations

This memo includes no request to IANA.

10.  Security Considerations

Overlays are vulnerable to DOS and collusion attacks. We are not solving overlay security issues. We assume the centralized node authentication model as defined in [I‑D.ietf‑p2psip‑base] (Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” March 2010.).

11.  References

11.1. Normative References

11.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Authors' Addresses