[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SAM Research Group                                             J. Buford
Internet-Draft                                       Avaya Labs Research
Intended status: Informational                           M. Kolberg, Ed.
Expires: January 13, 2011                         University 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



Buford, et al.          Expires January 13, 2011                [Page 1]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   (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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Overlay Network  . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Overlay Multicast  . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Peer . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Multi-Destination Routing  . . . . . . . . . . . . . . . .  5
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overlay  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Overlay Multicast  . . . . . . . . . . . . . . . . . . . .  6
     3.3.  RELOAD . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  NAT  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Regions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.6.  AMT  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Hybrid ALM Tree Operations . . . . . . . . . . . . . . . . . .  8
     4.1.  ALM-Only Tree - Algorithm 1  . . . . . . . . . . . . . . . 10
     4.2.  ALM tree with peer at AMT site (AMT-GW)  . . . . . . . . . 11
     4.3.  ALM tree with NM peer using AMT-R  . . . . . . . . . . . . 12
     4.4.  ALM tree with NM peer with P-AMT-R . . . . . . . . . . . . 12
     4.5.  ALM tree with peer P-AMT-GW  . . . . . . . . . . . . . . . 13
     4.6.  Mixed Region Scenarios . . . . . . . . . . . . . . . . . . 13
   5.  Group Management API . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Data Types . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2.  Send and Receive Calls . . . . . . . . . . . . . . . . . . 15
   6.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2.  Tree Lifecylce Messages  . . . . . . . . . . . . . . . . . 16
       6.2.1.  Create Tree  . . . . . . . . . . . . . . . . . . . . . 16
       6.2.2.  Join . . . . . . . . . . . . . . . . . . . . . . . . . 17
       6.2.3.  Join Accept  . . . . . . . . . . . . . . . . . . . . . 17
       6.2.4.  Join Confirm . . . . . . . . . . . . . . . . . . . . . 18
       6.2.5.  Join Decline . . . . . . . . . . . . . . . . . . . . . 19
       6.2.6.  Join Via AMT Gateway . . . . . . . . . . . . . . . . . 19
       6.2.7.  Join Via Native Link . . . . . . . . . . . . . . . . . 20
       6.2.8.  Leave  . . . . . . . . . . . . . . . . . . . . . . . . 21
       6.2.9.  Leave via AMT Gateway  . . . . . . . . . . . . . . . . 21
       6.2.10. Re-Form or Optimize Tree . . . . . . . . . . . . . . . 22



Buford, et al.          Expires January 13, 2011                [Page 2]


Internet-Draft          ALM Extensions to RELOAD               July 2010


       6.2.11. Heartbeat  . . . . . . . . . . . . . . . . . . . . . . 22
     6.3.  AMT Gateway Advertisement and Discovery  . . . . . . . . . 23
     6.4.  Peer Region and Multicast Properties Messages  . . . . . . 24
   7.  RELOAD Usages  . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  ALM Usage for RELOAD . . . . . . . . . . . . . . . . . . . 26
     7.2.  Hybrid ALM Usage for RELOAD  . . . . . . . . . . . . . . . 26
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     11.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28





































Buford, et al.          Expires January 13, 2011                [Page 3]


Internet-Draft          ALM Extensions to RELOAD               July 2010


1.  Introduction

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

   o  large group size

   o  large numbers of small groups

   o  rate of group membership change

   o  admission control for QoS

   o  use with network layer QoS mechanisms

   o  varying degrees of reliability

   o  trees connect nodes over global internet

   Adaptability includes

   o  use of different control mechanisms for different multicast trees
      depending on initial application parameters or application class

   o  changing multicast tree structure depending on changes in
      application requirements, network conditions, and membership

   o  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] 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 [RFC2119].


2.  Definitions






Buford, et al.          Expires January 13, 2011                [Page 4]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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.

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].  XCAST [RFC5058] is an



Buford, et al.          Expires January 13, 2011                [Page 5]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   experimental MDR protocol.  A hybrid host group and MDR design is
   described in [HE2005].


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



Buford, et al.          Expires January 13, 2011                [Page 6]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   most cases of interest.

   Peers are able to determine, through configuration or discovery:

   o  Can they connect to a NM router

   o  Is an AMT gateway accessible

   o  Can the peer support the AMT-GW functionality locally

   o  Is MDR supported in the region

3.3.  RELOAD

   We use RELOAD [I-D.ietf-p2psip-base] 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] 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



Buford, et al.          Expires January 13, 2011                [Page 7]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   sites/hosts to send general multicast.


4.  Hybrid ALM Tree Operations

   Peers use the overlay to support ALM operations such as:

   o  Create tree

   o  Join

   o  Leave

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



Buford, et al.          Expires January 13, 2011                [Page 8]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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

   o  No native multicast: Peers (P19 and P20) in this region connect to
      the overlay

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

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

   o  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



Buford, et al.          Expires January 13, 2011                [Page 9]


Internet-Draft          ALM Extensions to RELOAD               July 2010


      overlay.

   o  Native MDR is a native multicast region using multi-destination
      routing, in which one or more peers (P8 and P9) reside in the
      region.

   o  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



Buford, et al.          Expires January 13, 2011               [Page 10]


Internet-Draft          ALM Extensions to RELOAD               July 2010


       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:

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

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

   o  There is no NM peer in the tree.  The NM peer uses ALM routing.




Buford, et al.          Expires January 13, 2011               [Page 11]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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

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

   o  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:

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

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

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

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

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







Buford, et al.          Expires January 13, 2011               [Page 12]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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:

   o  ALM tree topology vs NM topology and NM-ALM edges

   o  Single NM-ALM edge nodes vs multi NM peers from same region in the
      tree

   o  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:

   o  P-ALM to P-ALM This is a normal ALM tree path with management
      strictly in the overlay

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

   o  P-ALM to/from P-NM The connection can be either ALM or AMT tunnel
      depending on the context.




Buford, et al.          Expires January 13, 2011               [Page 13]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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

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

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




Buford, et al.          Expires January 13, 2011               [Page 14]


Internet-Draft          ALM Extensions to RELOAD               July 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]).

   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.

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.




Buford, et al.          Expires January 13, 2011               [Page 15]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   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] 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] (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:

   o  Tree life-cycle (create, join, leave, re-form, heartbeat)

   o  AMT gateway advertisement and discovery

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



Buford, et al.          Expires January 13, 2011               [Page 16]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   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,



Buford, et al.          Expires January 13, 2011               [Page 17]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   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





Buford, et al.          Expires January 13, 2011               [Page 18]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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




Buford, et al.          Expires January 13, 2011               [Page 19]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   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:

   o  It is in an NM region, determined for example using MRD (Multicast
      Router Discovery) [RFC4286] or configuration

   o  It knows the native multicast address (NMA) in its region, if it
      exists, which corresponds to the GroupId

   o  It can connect to the NMA using IGMP

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

   o  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




Buford, et al.          Expires January 13, 2011               [Page 20]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   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.








Buford, et al.          Expires January 13, 2011               [Page 21]


Internet-Draft          ALM Extensions to RELOAD               July 2010


         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.



Buford, et al.          Expires January 13, 2011               [Page 22]


Internet-Draft          ALM Extensions to RELOAD               July 2010


         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]

   Options: Name-value list of options






Buford, et al.          Expires January 13, 2011               [Page 23]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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:

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




Buford, et al.          Expires January 13, 2011               [Page 24]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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

   o  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:

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

   o  HALM applications use the RELOAD data storage functionality to
      store a set of attributes about a native multicast region
      associated with an AMT Gateway.

   o  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] to define the
   following:

   o  Register Kind-Id points

   o  Define data structures for each kind

   o  Defines access control rules for each kind

   o  Defines the Resource Name used to hash to the Resource ID where
      the kind is stored

   o  Addresses restoration of values after recovery from a network
      partition

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






Buford, et al.          Expires January 13, 2011               [Page 25]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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


11.  References

11.1.  Normative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

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



Buford, et al.          Expires January 13, 2011               [Page 26]


Internet-Draft          ALM Extensions to RELOAD               July 2010


   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5058]  Boivie, R., Feldman, N., Imai, Y., Livens, W., and D.
              Ooms, "Explicit Multicast (Xcast) Concepts and Options",
              RFC 5058, November 2007.

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, <http://
              research.microsoft.com/en-us/um/people/antr/past/
              jsac.pdf>.

   [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, <http://research.microsoft.com/en-us/um/
              people/mcastro/publications/infocom-compare.pdf>.

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

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

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



Buford, et al.          Expires January 13, 2011               [Page 27]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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

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

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

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

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
              RFC 4286, December 2005.


Appendix A.  Additional Stuff

   This becomes an Appendix.










Buford, et al.          Expires January 13, 2011               [Page 28]


Internet-Draft          ALM Extensions to RELOAD               July 2010


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











Buford, et al.          Expires January 13, 2011               [Page 29]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/