TOC 
SAM Research GroupJ. Buford
Internet-DraftAvaya Labs Research
Intended status: InformationalM. Kolberg, Ed.
Expires: January 13, 2011University of Stirling
 T C. Schmidt
 HAW Hamburg
 M. Waehlisch
 link-lab & FU Berlin
 July 12, 2010


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




 TOC 

1.  Introduction

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

Adaptability includes

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.



 TOC 

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



 TOC 

2.  Definitions



 TOC 

2.1.  Overlay Network



                    P    P    P   P     P
                  ..+....+....+...+.....+...
                 .                          +P
               P+                            .
                 .                          +P
                  ..+....+....+...+.....+...
                    P    P    P   P     P
 Figure 1 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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



 TOC 

3.  Assumptions



 TOC 

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.



 TOC 

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:



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

4.  Hybrid ALM Tree Operations

Peers use the overlay to support ALM operations such as:

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  +---------------+
 Figure 2 

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.



 TOC 

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:


 TOC 

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:

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



 TOC 

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:



 TOC 

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.



 TOC 

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.



 TOC 

4.6.  Mixed Region Scenarios

In version 2 of this document we elaborate on:

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:

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

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.



 TOC 

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



 TOC 

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.


 TOC 

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.


 TOC 

6.  Protocol



 TOC 

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:



 TOC 

6.2.  Tree Lifecylce Messages

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



 TOC 

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.



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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:

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



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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



 TOC 

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.



 TOC 

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:

The Hybrid ALM Usage involves the following additional functions:

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:

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



 TOC 

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.



 TOC 

7.2.  Hybrid ALM Usage for RELOAD



 TOC 

8.  Examples

TBD.



 TOC 

9.  IANA Considerations

This memo includes no request to IANA.



 TOC 

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



 TOC 

11.  References



 TOC 

11.1. Normative References

[RFC0792] Postel, J., “Internet Control Message Protocol,” STD 5, RFC 792, September 1981 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” RFC 3376, October 2002 (TXT).
[RFC3810] Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, June 2004 (TXT).
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” RFC 4605, August 2006 (TXT).
[RFC4607] Holbrook, H. and B. Cain, “Source-Specific Multicast for IP,” RFC 4607, August 2006 (TXT).
[RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, “Explicit Multicast (Xcast) Concepts and Options,” RFC 5058, November 2007 (TXT).


 TOC 

11.2. Informative References

[AGU1984] Aguilar, L., “Datagram Routing for Internet Multicasting,” ACM Sigcomm 84 1984, March 1984.
[CASTRO2002] Castro, M., Druschel, P., Kermarrec, A., and A. Rowstron, “Scribe: A large-scale and decentralized application-level multicast infrastructure,” IEEE Journal on Selected Areas in Communications vol.20, No.8, October 2002.
[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,” Proceedings of IEEE INFOCOM 2003, April 2003.
[HE2005] He, Q. and M. Ammar, “Dynamic Host-Group/Multi-Destination Routing for Multicast Sessions,” J. Telecommunication Systems vol. 28, pp. 409-433.
[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-10 (work in progress), March 2010 (TXT).
[I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “REsource LOcation And Discovery (RELOAD) Base Protocol,” draft-ietf-p2psip-base-08 (work in progress), March 2010 (TXT).
[I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, “A SIP Usage for RELOAD,” draft-ietf-p2psip-sip-04 (work in progress), March 2010 (TXT).
[I-D.irtf-p2prg-rtc-security] Schulzrinne, H., Marocco, E., and E. Ivov, “Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications,” draft-irtf-p2prg-rtc-security-05 (work in progress), September 2009 (TXT).
[I-D.irtf-sam-hybrid-overlay-framework] Buford, J., “Hybrid Overlay Multicast Framework,” draft-irtf-sam-hybrid-overlay-framework-02 (work in progress), February 2008 (TXT).
[I-D.matuszewski-p2psip-security-overview] Yongchao, S., Matuszewski, M., and D. York, “P2PSIP Security Overview and Risk Analysis,” draft-matuszewski-p2psip-security-overview-01 (work in progress), October 2009 (TXT).
[I-D.waehlisch-sam-common-api] Waehlisch, M., Schmidt, T., and S. Venaas, “A Common API for Transparent Hybrid Multicast,” draft-waehlisch-sam-common-api-02 (work in progress), March 2010 (TXT).
[RFC1112] Deering, S., “Host extensions for IP multicasting,” STD 5, RFC 1112, August 1989 (TXT).
[RFC1930] Hawkinson, J. and T. Bates, “Guidelines for creation, selection, and registration of an Autonomous System (AS),” BCP 6, RFC 1930, March 1996 (TXT).
[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” BCP 72, RFC 3552, July 2003 (TXT).
[RFC4286] Haberman, B. and J. Martin, “Multicast Router Discovery,” RFC 4286, December 2005 (TXT).


 TOC 

Appendix A.  Additional Stuff

This becomes an Appendix.



 TOC 

Authors' Addresses

  John Buford
  Avaya Labs Research
  233 Mt. Airy Rd
  Basking Ridge, New Jersey 07920
  USA
Phone:  +1 908 848 5675
Email:  buford@avaya.com
  
  Mario Kolberg (editor)
  University of Stirling
  Dept. Computing Science and Mathematics
  Stirling, FK9 4LA
  UK
Phone:  +44 1786 46 7440
Email:  mkolberg@ieee.org
URI:  http://www.cs.stir.ac.uk/~mko
  
  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
  
  Matthias Waehlisch
  link-lab & FU Berlin
  Hoenower Str. 35
  Berlin 10318
  Germany
Email:  mw@link-lab.net